在 IT 行业和开发者眼中，Kubernetes都是云原生平台的绝对领导者。Kubernetes自从开源以来，项目本身和围绕它的生态都成长的比较快。Kubernetes自身在快速成长的同时也敏锐地捕捉到了边缘计算相关的需求，并做了相应布局即成立了Kubernetes IoT Edge Working Group。
这节课我就跟大家一块聊一下Kubernetes 和Kubernetes IoT Edge Working Group。
Kubernetes
Kubernetes是一个全新的基于容器技术的分布式架构的云部署方案，是Google开源的容器集群管理系，为部署容器化的应用提供资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。 接下来，我将从三方面为大家讲解Kubernetes，即Kubernetes支持的容器运行时、Kubernetes架构和Kubernetes所需插件。
Kuberntes支持的容器运行时
容器是包含在任何环境中运行所需的所有元素的软件包。容器可以虚拟化操作系统，并在任何地方运行，不管目标环境是私有数据中心、公有云，还是开发者的个人笔记本电脑。
容器运行时是能够基于在线获取的镜像来创建和运行容器的程序。容器运行时负责管理任务在容器管理平台的整个生命周期，运行时在接受Kubernetes下发的任务之后，会从驱动、存储和网络三方面来组织、创建和启动该任务；在任务被启动之后，运行时管理管理模块会对任务的运行状态和资源使用情况进行监控。
Kubernetes通过容器运行时在pod（Pod 是一组（一个或多个） 容器，这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置的并且一同调度，在共享的上下文中运行）里以容器的形式运行应用，官方默认支持docker容器运行时。除此之外，Kubernetes支持的容器运行时还包括CRI-O、Containerd、Frakti等，具体如下表所示。 表Kubernetes支持的容器运行时
| 容器运行时 | 原理说明 | 备注 |
|---|---|---|
| docker | 基于Linux Namespace、Control Groups和Union filesystem的一种容器运行时实现方式 | 同时支持Linux和Windows操作系统，目前是Kubernetes默认的容器运行时 |
| Containerd | 与docker相比减少了dockerd这一层富功能组件，其底层实现原理与docker相同 | Containerd的可配制性比较强，可以通过插件的方式替换具体实现 |
| CRI-O | RedHat发布的容器运行时, 在同时满足 CRI 标准和 OCI 标准的前提下，将CRI和OCI的实现都进行了轻量化 | 还没有在大规模运行环境的验证，稳定性没有保障 |
| Frakti | 基于Hypervisors的容器运行时，具有独立kernel，比基于Linux Namespace的容器运行时的隔离性要好 | 还没有在大规模运行环境的验证，稳定性没有保障 |
| 从Kubernetes支持的容器运行时列表，我们可知： | ||
| 1）docker和Containerd在实现原理上是相同的，只是Containerd裁剪了docker原有的一些富功能； | ||
| 2） CRI-O为了追求轻量级和简洁，对CRI和OCI重新进行实现； | ||
| 3）Frakti的目的是实现容器运行时的强隔离性，基于Hypervisors实现容器运行时，使每个容器具有独立的kernel。 |
Kubernetes架构
边缘计算云部分Kubernetes功能架构如下图所示。
从上图中，我们可以发现以下几点。
1）Kubernetes支持的CPU架构包括X86、ARM、s390x和ppc64le。 2）Kubernetes支持的操作系统类型包括Linux、Windows和macOS。 3）Kubernetes支持的容器运行时包括docker、containerd、cri-o和frakti。 4）Kubernetes按组件功能分为控制节点组件、计算节点组件和集群存储组件。控制节点组件包括kube-apiserver、kube-controller-manager和kube-scheduler，计算节点组件包括Kubelet和kube-proxy，集群存储组件包括etcd。 5）Kubernetes的负载以pod的形式运行，pod是container组，container是基于操作系统的namespace、cgroup和filesystem的共同作用而隔离出来的系统进程独立运行的空间。
Kubernetes逻辑架构如下图所示。
由图Kubernetes逻辑架构可知，Kubernetes包含两种类型的节点，即控制节点和计算节点。
1）控制节点：负责Kubernetes集群的管理工作，在集群基础设施层面，负责对集群规模的调整，比如集群中计算节点的增、删、改、查；在集群管理的应用负载资源层面，负责对集群内应用资源的增、删、改、查和相关调度，以及集群中应用的故障自愈等；
2）计算节点：负责Kubernetes集群中应用负载的最终运行和状态监控，即接收控制节点的调度结果，并根据调度结果对集群中的应用负载进行操作；此外，还要对集群中的应用负载的运行状态和资源使用情况进行监控，并以心跳或事件的形式上报给控制节点。 对比Kubernetes的控制节点组件列表和计算节点组件列表之后，有些读者可能会疑惑，为什么本节的控制节点组件列表中既包含控制节点组件kube-apiserver、kube-controller-manager和kube-scheduler，又包含计算节点组件Kubelet和kube-proxy？
那是因为在Kubernetes集群中控制节点的所有组件也是以应用负载的形式运行的，而在Kubernetes集群中运行应用负载是通过计算节点组件Kubelet和kube-proxy完成的。
为了保证控制节点组件稳定运行，控制节点默认不接受控制节点组件以外的应用负载类型，这是通过给制节点增加taint来实现的。 Kubernetes高可用架构如下图所示。
由图Kubernetes高可用集群架构可知，在Kubernetes集群中，可以通过对控制节点的控制使集群中的控制节点从单个增加到多个（控制节点要等于2n-1,n是大于1的整数），实现集群的高可用。也可以使集群中的控制节点从多个减少到单个（但要符合1、3、5、7等规律）。在通过对控制节点的控制调整控制节点个数的过程中，集群存储组件etcd的个数也在随之调整，因为集群中控制节点之间都是无状态，且无法相互感知，需要借助etcd来保证集群状态的一致性。
Kubernetes所需插件
Kubernetes集群除了上面提到的容器运行时，和架构部分提到的核心组件（kube-apiserver、kube-controller-manager、kube-scheduler、Kubelet和kube-proxy）之外，还需要一些插件才能正常运行，具体如下：
（1） DNS插件 负责Kubernetes集群内部服务发现与域名解析，例如CoreDNS、Kube-dns等； （2） 网络插件 负责Kubernetes集群内部同一主机pod间和不同主机pod间网络通信，例如Calico、Cilium、Contiv-VPP、Flannel、Kube-router和Weave Net等； （3） Ingress控制器 作为Kubernetes集群外的应用与集群内的负载互访的桥梁，例如NGINX Ingress Controller、Kong Ingress Controller、HAProxy Ingress Contoller和Traefik等； （4） 日志、监控、弹性扩缩容等插件。
Kubernetes IoT Edge Working Group
为了应对边缘计算相关需求，Kubernetes 与2018年6月份成立了Kubernetes IoT Edge Working Group简称kubernetes-wg-iot-edge（github.com/kubernetes/… ）。Kubernetes官方对这个工作组的定位是：“一个致力于讨论、设计和记录使用 Kubernetes 开发和部署物联网和边缘特定应用程序的工作组”。
我下面将从两个方面来带大家了解kubernetes-wg-iot-edge，即kubernetes-wg-iot-edge的目标和kubernetes-wg-iot-edge的成果。
kubernetes-wg-iot-edge的目标
由于Kubernetes官方对kubernetes-wg-iot-edge的定位是：“一个致力于讨论、设计和记录使用 Kubernetes 开发和部署物联网和边缘特定应用程序的工作组”。kubernetes-wg-iot-edge的目标也都与物联网和边缘特定应用程序息息相关，具体如下：
1. 为各种物联网/边缘环境提供参考架构。 2. 创建和维护针对最流行的物联网/边缘用例的性能和可靠性要求量身定制的一致性测试。 3. 构建端到端 PoC 以验证整体设计并向系统集成商提供示例。 4. 评估并尽可能扩展 Kubernetes联邦和网络基础设施，以通过带宽受限和不可靠的 WAN 互连更好地适应物联网/边缘用例。 5. 评估并尽可能改进连接和数据采集选项，以更好地支持各种现场协议。 6. 评估和扩展现有 CLI 工具以管理在远程边缘位置运行的 Kubernetes集群。 以上6条是kubernetes-wg-iot-edge目前所有的目标，但它是一个开放且活跃的工作组，随时欢迎加入合理的新目标！
kubernetes-wg-iot-edge的成果
截止目前kubernetes-wg-iot-edge官方只正式发布了一个成果，即Edge Security Challenges，但我梳理了kubernetes-wg-iot-edge网络论坛（groups.google.com/g/kubernete… and Edge computing with Kubernetes白皮书（docs.google.com/document/d/… Security Challenges和讨论Kubernetes相关的边缘计算开源项目。
IoT and Edge computing with Kubernetes白皮书
IoT and Edge computing with Kubernetes白皮书是在kubernetes-wg-iot-edge网络论坛2018年6月18日的一封邮件（groups.google.com/g/kubernete…
在IoT and Edge computing with Kubernetes白皮书发布时，云原生计算范式已成为许多开发团队的主要关注点，Kubernetes从根本上改变了团队构建应用程序的方式。但是还有一类应用程序并不属于云原生范畴，即物联网和边缘应用程序，因为它们有许多分布式组件，且通常不会运行在同一个数据中心的基础设施之上。此外，云原生领域正在开发的概念、基础设施和工具也会使物联网和边缘应用程序的开发人员将从中受益匪浅。
IoT and Edge computing with Kubernetes白皮书的目标是将云原生领域与物联网和边缘应用程序联系在一起 ，并为未来的工作奠定基础。为了做到这一点，白皮书对于要用到的术语、定义、架构等都做了相应的描述。具体分为下面几块：
1. 什么是边缘？因为白皮书专注于如何使用 Kubernetes 改进物联网系统的部署和运行，所以边缘是与最终用户和设备更接近的计算机资源。
2. 边缘资源类别。主要包括设备边缘和基础设施边缘两类。
3. 边缘负载。 针对边缘的具体场景，从流量控制、通信协议到具体应用类型都做了相关定义。
4. 云平台。定义了针对IoT的云平台。
5. 使用 Kubernetes 的物联网和边缘架构。提供了一些物联网应用和边缘应用在使用Kubernetes时参考架构。
6. 生命周期。集群生命周期、负载生命周期和操作相关的一些事项。
Edge Security Challenges
Edge Security Challenges（github.com/kubernetes/…）是截止目前kubernetes-wg-iot-edge官方正式发布的唯一成果，其目的是描述 Kubernetes 社区认为比较确定的一组边缘安全挑战和问题。 具体问题和挑战如下所示：
1. 可信硬件。强调了边缘硬件安全的必要性，并建议将边缘硬件安全性整合到系统的软件层中，来使其发挥最大价值。
2. 信任连接的设备。强调了信任连接的设备的重要性，并指出不同的供应商协同工作才可以达到该效果。
3. 操作系统安全。指出了操作系统相关的安全问题，包括BIOS和安全引导、运行进程和二进制证明、组件固件漏洞、操作系统的安全更新和审计跟踪和日志文件。
4. 网络安全。由于分布式系统架构增加了复杂性，并且边缘网络不像数据中心 LAN 那样受到保护，可能会出现的网络安全问题。
5. 边缘微服务安全。运行在边缘的微服务可能会出现的安全问题，包括镜像安全、密钥安全传输、微服务鉴权和访问控制等。
讨论Kubernetes相关的边缘计算开源项目
kubernetes-wg-iot-edge网络论坛除了IoT and Edge computing with Kubernetes白皮书和Edge Security Challenges的相关工作，还会对基于Kubernetes实现的边缘计算项目进行讨论，相关项目列表如下：
1. 华为开源的KubeEdge (github.com/kubeedge)
2. Rancher的K3S（k3s.io/）
接下来，我们可以开始定义当今在这个领域使用的基本概念、用例和架构。请注意，我们不会尝试更深入地讨论一般物联网和边缘计算，因为已经有优秀论文详细介绍了这些主题，您可以在参考资料中找到它们。
kubernetes-wg-iot-edge的目标是使Kubernetes成为物联网和边缘计算的最佳平台。而且表示，在必要时会启动新项目，使云原生和边缘计算更紧密地结合在一起。但到目前为止也没有启动任何边缘计算相关的新项目，这样的结果我个人还是感觉有些失望的。
总结：
至此，Kuberntes和其在边缘计算领域的布局就讲完了，总结一下前面的内容：
1. Kubernetes。从Kubernetes支持的容器运行时、Kubernetes架构和Kubernetes所需的插件三方面对Kubernetes进行了一个系统介绍，让大家对其有一个感性认识。
2. Kubernetes IoT Edge Working Group。从kubernetes-wg-iot-edge的目标和kubernetes-wg-iot-edge的成果两方面对其定位和推进情况进行了全面梳理。
课后思考：
Kubernetes目前的架构不满足边缘计算的需求吗？真的有必要为边缘计算启动新的项目吗？
