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
这样就可以实现三层结构的高可用性：
- 如设备失效，设备集群代理/管理器可在另外一台设备上重建该虚机节点；
- 如虚机节点失效，设备集群代理/管理器可发现并重启该节点；
- 如Pod/容器失效，由Kubernetes重建该Pod/容器。
在以上任何情况下，保存在持久化存储路径下的数据不丢失。
安全性问题留在后篇整体介绍。
下面的讨论主要针对计算、网络、管理、维护这几方面展开。
早期探索
Target
Target是美国一家著名的大型连锁超市。在2017年初，Target就开始用Kubernetes和Spinnaker自建Unimatrix平台，进行远程集群管理。Target采用舰队管理（Fleet Management）的模式，将含主从节点设备的整个集群部署到1850个门店中，每个集群由完全主从复用的三个节点设备组成，每个门店内的集群都是互相独立的。并在Unimatrix上支持Kubernetes API，以对接云端Kubernetes社区内丰富的应用生态。Unimatrix方案将Agent部署到门店，以对接Kubernetes集群和云的通信。
Chick-Fill-A
Chick-Fill-A是美国一家非常知名的餐饮连锁商。在2018年将2000间门店从Docker迁移到Kubernetes平台上。每个门店以一组Intel NUC设备组成三节点集群，利用Kubernetes和大量开源软件集成进行舰队管理（Fleet Management）。
https://medium.com/@cfatechblog/bare-metal-k8s-clustering-at-chick-fil-a-scale-7b0607bd3541
Chick-Fill-A的方案整体上与Target是类似的，都是全集群部署到边缘设备上，并以其他方式进行舰队管理，与Kubernetes相补充，形成多层管理结构。
现有方案
上面的两例都是Kubernetes的用户为解决自身遇到的问题所自建的方案，下面介绍的是几个业内正在推广的技术方案。
KubeEdge
https://kubeedge.io/
KubeEdge于2019年成为云原生计算基金会（CNCF）旗下的沙箱项目，是专门为物联网和边缘计算场景的设备层设计的。在它的架构中CloudCore是和Kubernetes主节点一同放在云上，EdgeCore部分运行于设备上，之间的网络可只单向可见。
CloudCore内部的EdgeController与Kubernetes API服务器的交互，主要是通过在https://github.com/kubeedge/kubeedge/blob/master/cloud/pkg/edgecontroller/controller/下的downstream.go和upstream.go这两个程序里调用kubernetes.Clientset的API来完成的。比如：
// DownstreamController watch kubernetes api server and send change to edge
type DownstreamController struct {
kubeClient *kubernetes.Clientset
……
}
// UpstreamController subscribe messages from edge and sync to k8s api server
type UpstreamController struct {
kubeClient *kubernetes.Clientset
// message channel
……
}
而EdgeCore部分，除了利用现有的容器运行时（CRI）工具之外，其他与CloudCore交互的程序都是自建的，实现类似于Kubelet的功能。EdgeHub与CloudHub之间的接口不兼容于Kubelet，而是基于websocket或QUIC协议实现的。
https://github.com/kubeedge/kubeedge/blob/master/docs/proposals/quic-design.md
最特别的是在边缘上还有MQTT Broker与EdgeCore通信，将物联网协议映射进来，再通过EventBus转发到DeviceTwin里去。至今只看到ModBus和蓝牙这两种协议实现映射，而这种将边缘容器平台和边缘应用逻辑混合在一起设计的架构是非常罕见的。
因为要以自建代码支持全套的Kubelet机制，并保持与Kubernetes API服务器兼容，KubeEdge需要跟Kubernetes的逐个发布追赶实现。2020年2月发布的KubeEdge 1.2与2019年12月发布的Kubernetes 1.17兼容。
K3S
https://k3s.io/
K3S是Rancher发布的开源项目，它的主要设计思路是将Kubernetes集群小型化、轻量化之后整体放在边缘侧，通过其他管理通道与云侧协同。这很类似于上节介绍的Target或Chick-Fil-A的传统思路。
K3S利用Kubernetes的基础代码、再由自建代码封装，将所有的程序都打包进同一个二进制文件，安装非常方便。但它的命令行必须由K3S触发，比如sudo k3s kubectl get node。K3S中来自第三方的代码主要集中在k3s/pkg/generated目录下。K3S可以粗略地被看作Kubernetes一个非官方的、轻量级的、API兼容的项目。2020年5月K3S最新发布版支持Kubernetes 1.17.5。
小型化的K3S内嵌轻量级数据库SQLite，也支持外挂数据库。K3S对于非OS的外部软件依赖也减到很低。如果辅以负载均衡节点 的话，K3S就可以实现高可用性的部署模式。
Virtual Kubelet
https://virtual-kubelet.io/
Virtual Kubelet是CNCF基金会的沙箱项目，它是kubelet的API兼容实现，以允许由其他在云或边缘上的服务实现的节点可以像kubelet一样与Kubernetes主节点通信。虽然Virtual Kubelet最初的目的是支持无服务（serverless）等容器平台，但也支持其他类型的服务。Virtual Kubelet提供可插入的Provider接口，开发人员可实现Kubelet所需要的如下功能：
- 后端必要的管道性支持，管理pod、容器和Kubernetes语境下的支持性资源的生命周期
- 符合和Virtual Kubelet提供的API
- 限制到Kubernetes API服务器的所有访问，提供定义良好的回调机制以获取如Secrets和ConfigMaps的数据
例如Azure IoT Edge Connector就是一个基于Virtual Kubelet Provider接口的实现。通过封装的IoT Edge Provider与Virtual Kubelet交互，可以标准Kubernetes API的方式将边缘应用部署到设备上。当然该部署是以不同于云应用的异步方式实现。
https://github.com/Azure/iot-edge-virtual-kubelet-provider
与此类似的，技术上可以实现支持其他边缘应用部署的Provider，而主从节点其实都在云侧，通过既有边缘计算平台的通道进行管理。
MicroK8s
MicroK8s是由Ubuntu推出的开源软件，它封装成snap形式的Kubernetes各应用的一个集合体。它的特点是：
- 小：将必要的程序打包在一起方便部署；
- 简单：单一snap包安装，无外部依赖，简化管理和运维；
- 安全：来自上游的安全更新很快；
- 现时：及时更新来自于上游的代码，可选择最新或任意版本；
- 全面：包含积累的通用manifest集合。
MicroK8s里的自建代码很少，主要实现snap打包的功能，它是非常简化的Kubernetes发行版。Snap包的格式主要用于Ubuntu类系统，在其他各Linux发行版上 也有支持。
MicroK8s的命令行必须由microk8s触发，比如sudo mirok8s kubectl get node 。它的主从节点需要都部署在边缘侧，然后从云侧以其他通道进行远程管理。
选项比较
以上介绍了几种现在比较主流的将Kubernetes部署到边缘上的开源项目和技术方案。每种方案各有优缺点，列表对比如下：
从普通开发人员和用户的角度出发，最理想的将Kubernetes部署在边缘侧的方案，应当具有如下特点：
- 资源消耗少
- 完全兼容
-代码与Kubernetes上游同步
-认证发行版
- 管理简单
-主节点在云侧
-从节点在边缘
然而从上表中可以看出，任何现有方案都无法满足所有的理想化需求。这样的需求，也许只有Kubernetes项目重构之后才有可能满足。
没有银弹
在现有条件下，如果不能满足所有理想化需求，是否可以退一步看，哪些是可以放弃或妥协的需求。比如：
有必要把主节点放在云侧吗？
主节点在云侧、从节点在边缘最主要的价值是统一简化的管理。如果可以接受多层管理机制，及边缘侧较多的资源消耗，在这点可以让步。
有必要用Kubernetes吗？它对边缘计算到底意味着什么？
Kubernetes的主要价值，对很多用户来说是丰富的生态软件，边缘与云侧管理统一的API。如果用户的云环境里并未部署大量Kubernetes应用，那基于云边协同的直接价值就不明显了。
有必要部署分布式边缘应用吗？
Kubernetes是编排分布式容器应用的主流工具，但边缘应用很多并不需要分布式部署。如果是这样，Kubernetes可能用起来还不如Docker Compose顺手。
总之，在现有条件下，用户需要根据自己的实际状况和需求选择适合自己的Kubernetes部署工具，如果Kubernetes是必要的话。没有放之四海而皆准的方案，也就是“没有银弹”。
- 未完待续 -
系列文章（七）预告
本篇介绍并比较现有的将Kubernetes应用于边缘的各种技术方案。实际上Linux基金会边缘计划托管的EdgeX Foundry就是需要分布式部署的边缘计算应用框架。下篇介绍如何通过Kubernetes将EdgeX Foundry部署到设备上去。
来源：oschina
链接：https://my.oschina.net/u/4238514/blog/4304278