Kubernetes是起源于Google、在最近三五年里大热的容器编排工具。战胜了其他竞争对手之后,Kubernetes现在毋庸置疑地在云计算环境中占据垄断地位。在收购了Heptio、Bitnami等颇有影响的初创公司之后,VMware成为Kubernetes全球社区中举足轻重的贡献者。2020年3月,VMware发布了Cloud Foundation 4,内置革命性的Tanzu平台,全面支持Kubernetes在云中更高效透明的运维管理。
与此同时,相当多的用户和厂商在不断尝试将Kubernetes应用于边缘计算环境中。然而,边缘计算毕竟不同于云计算,很多云中习以为常的基本假设,在边缘上是不成立、或者成本过高以至于不现实的。
本篇将浅析其中的原委,并比较不同技术方案的优缺点。这里专注于设备层的探讨,而不是云边缘(Cloud Edge)或移动边缘计算(MEC)。对于Kubernetes来讲,后两者的技术环境与云中相比差别不大,基本可以无缝迁移。
第六篇 设备集群上的Kubernetes
原生Kubernetes的基本假设
Kubernetes原本设计是在云计算环境中运行,所以它的基本假设就是云计算资源、基础设施即服务(IaaS)的特性,包括:
- 计算是充分的、可分布式部署的
- 网络是稳定的、可双向联通的
- 存储是易失的、本地的,或持久化的、网络化的
- 管理是远程的、自动化的、自服务的
- 安全是确保的、可控的、可编程的
Kubernetes由此而来的架构设计思路充分利用了以上特性,例如:
- 主节点多实例、从节点多层次抽象、分布式部署
- 主从节点间双向联通、高频同步
- 元数据存储持久化、网络化,有状态应用可持久化
- 远程、跨云的管理方式
- 安全策略自动化
设备层的局限
然而Kubernetes的设计思路并不完全适用于设备层,因为这里一般的资源特点是:
- 计算是有限的
- 北向网络是不稳定的、窄带的、昂贵的
- 存储基本都是本地的、易失的
- 管理传统上是本地的、人工的
- 安全是不完全可控的
将Kebernetes应用于设备层的不同技术方案差异的焦点,就是如何解决以上这些问题。
超融合持久化存储
上篇介绍的超融合设备集群方案,可以较好地解决本地存储易失的问题。业界也有一些基于裸金属(Bare Metal)的开源持久化存储方案可供选择,这里不再赘述。
在虚拟化设备集群上部署Kubernetes应用的步骤如下:
- 安装开源软件govmomi和govc,按照vSphere存储Kubernetes指南配置虚机,特别是为所有虚机设置disk.EnableUUID为true,以确保VMDK的ID是恒定唯一的
- 以kubernetes.io/vsphere-volume做持久化卷(PersistentVolume)的提供者,将StorageClass声明在vsanDatastore之上
- 正常创建PersistentVolume和PersistentVolumeClaim
这样就可以实现三层结构的高可用性:
- 如设备失效,