系列文章（六）丨设备集群上的Kubernetes

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

这样就可以实现三层结构的高可用性：

• 如设备失效，