共计 4439 个字符，预计需要花费 12 分钟才能阅读完成。
导语：边缘计算模式下，云端的控制中心和边缘端的设施之间网络环境较简单，网络品质差次不齐没有保障。用户往往心愿在弱网环境下，边缘容器能提供高可用的业务能力。TKE 边缘容器团队在弱网环境下提出了边缘自治性能。本文着重介绍了边缘容器在弱网环境下为了保障业务高可用而做的工作。
问题背景
边缘计算应用的边缘设施数量宏大、散布全国各地，网络环境简单，因特网、以太网、5G、WIFI 等状态均有可能。因而，云端的控制中心和边缘端的设施之间网络环境较简单，网络品质差次不齐没有保障。
kubernetes 传统工作模式是所有组件 list-watch kube-apiserver，而后 reconcile 各种资源到冀望状态。各节点的衰弱都强依赖于其与 kube-apiserver 通信的稳固。kubernetes 在传统的集群环境上工作很完满，因为大多数集群都能保障在一个局域网内。然而，在边缘计算的业务场景下，有一个稳固的网络环境着实是一件侈靡的事件。
在这样的背景下，如何保障边缘集群的业务高可用性以及服务高可用性？始终都是一个难题。为此咱们腾讯云边缘容器团队（TKE@EDGE）设计了两个利器来专门啃下这块硬骨头，本篇将重点讲第一个利器——边缘自治。
（注：此文提到的网络环境，都是指节点与云端的网络环境，而不是业务运行所在环境。）
需要举例
咱们来以一个常见的厂房模型来介绍一下用户在弱网环境下应用传统 kubernetes 遇到的问题以及 TKE 边缘容器团队在此类场景下提出的解决方案。
如上图所示，该案例采纳的部署模式为：用户在腾讯云私有云上购买了几台 CVM 机器作为 master 节点，其上部署了 kube-apiserver、kube-controller-manager、kube-scheduler 三大组件。而后依据业务需要，为每一个厂房都创立多个边缘 worker 节点，部署 kubelet 和 kube-proxy 以及 dockerd。同厂房节点之间能够相互拜访，不同厂房节点网络不互通。比方两个散布在北京和广州的厂房的边缘节点尽管能够归属于同一个集群，然而它们之间的网络是不互通的。每个厂房内所有节点会通过公网连贯至云端管控端，然而这个网络通道都属于不牢靠的弱网环境。
厂房 A 在北京地区，厂房 B 在广州地区。二者之间是不能互通的。
用户通过 kubernetes 治理平台进行 workload 的治理，master 与 worker 节点所在的厂房之间的网络环境网络环境是不能保障的，可能弱网 A 断网，网络 B 依然失常。用户在这样的场景下，提出了几个需要：
- 节点即便和 master 失联，节点上的业务能持续运行
- 保障如果业务容器异样退出或者挂掉，kubelet 能持续拉起
- 保障节点 重启 后，业务能持续从新被拉起来
- 用户在厂房内部署的是 微服务，须要保障节点重启后，同一个厂房内的微服务能够拜访
对于用户来说，这些诉求是他们的根本需要，也是其业务上云的关键因素。用户想要既享受 kubernetes 带来不便的治理运维，同时也要具备弱网环境下的容灾能力。这对传统规范 kubernentes 解决方案提出了挑战。
规范 kubernetes 解决形式
咱们来复习一下规范的 kubernentes 下，如果节点断网失联并且产生异样重启的行为后，会呈现哪些景象呢？
- 失联的节点状态置为 NotReady 或者 Unknown 状态
- 失联的节点上的业务进场异样退出后，容器能够被拉起
- 失联的节点上的 Pod IP 从 Endpoint 列表中摘除
- 失联的节点产生点重启后，容器全副隐没不会被拉起
咱们顺次来看，首先，在传统的模式下，节点是否衰弱取决于节点上 kubelet 组件的心跳或者续租。如果网络断了，云端组件当然会认为节点是不可用状态。这个状态能够提醒用户，该节点可能有异样，须要运维染指。同时，因为 kubelet 还在接管所有本机 Pod，即便业务容器异样退出，容器也是能够持续被拉起的。失联的节点上所有的 Pod，它们的 IP 都会被从 Endpoint list 中摘除，导致微服务不能拜访到这个节点，在传统 kubernentes 集群中，这是一个高可用的措施。然而在边缘集群内，这个“节点不可用 = 服务不可用”等式是否还成立呢？这个中央是须要探讨的，其实很多业务场景下，用户心愿节点即便和云端断网，该节点上的 Pod 也要能持续对外提供服务。
因而咱们团队认为，在边缘容器的场景下，单纯与云端网络失联是不能被粗犷地认为“服务不可用”的。为此咱们特意设计了第二件利器——“分布式节点健康检查”插件，来解决这个痛点，该性能会在后续文章进行具体介绍。
上面重头戏来了，断网的节点重启一下，容器还会在吗？服务还可用吗？答复是，容器当然不在喽。而且容器不在了，服务必定不能拜访了。用户最要害的需要，显然在传统的 kubernentes 模式下，是不能满足的。
那么来看看咱们边缘计算的利器——边缘自治性能能达到的成果吧。
TKE 的边缘自治成果
TKE 的边缘自治成果
- 节点会被置为 NotReady 或者 Unknown 状态，然而服务依然可用
- 多节点断网状况下，Pod 业务失常运行，微服务能力失常提供
- 多节点断网状况下并重启后，Pod 会被从新拉起并失常运行
- 多节点断网状况下并重启后，所有的微服务能够被失常拜访
咱们为了达到最合乎用户的成果，配合应用了分布式节点健康检查插件性能，来保障节点在断网状况下即便节点被置为 NotReady 状态，然而服务还是持续可用。同时该节点上的 Pod 也不会在新的节点上从新拉起新的 Pod 正本。
咱们在极其网络环境下，将运行业务的多个节点手动执行重启操作来模仿节点异样重启场景。节点重启之后，节点组件失常启动，之前的 Pod 也会被主动被拉起，并且运行失常，处于 Running 状态。
那服务以及网络呢？咱们测试后发现，重启多个节点之后，咱们在节点手动申请 Pod ip，能够拜访胜利；进入 Pod A 外部别离申请在同一个节点上的 Pod B 以及另一个节点上的 Pod C（须要同一个厂房环境），都能够拜访胜利；在 Pod A 解析 同一厂房的 Service A，能够解析并胜利。最初，在内部对于该厂房外部的服务进行申请，拜访胜利。
如此看来，边缘自治性能，无效解决了传统 kubernetes 在弱网环境下所不能解决的用户痛点。
原理简介
咱们团队为边缘自治性能打磨了很久，波及方面泛滥，批改以及设计的中央比拟多，本文不太介绍具体代码实现细节。有趣味的同学能够和 TKE 边缘容器同学独特进行学习探讨。在此我简略分享一些设计原理。
lite-apiserver 机制
kubernetes 是典型的通过数据进行交互的架构。解决数据问题就能提供一个夯实的根底。所以弱网环境的边缘自治，首当其冲的，最最最须要解决的问题就是数据问题。
思考到弱网、断网状况，须要保障节点的组件与云端组件“通信”，或者说让节点认为此时还是能够“通信”的。如上图所示，咱们在边缘端加了一层镜像 lite-apiserver 组件。边缘节点上所有对 kube-apiserver 的申请都会发往 lite-apiserver，并由 lite-apiserver 转发到 kube-apiserver。对于边缘节点来说，lite-apiserver 提供的性能就是 kube-apiserver 一样，然而一方面 lite-apiserver 只对本节点无效，另一方面相比拟规范的 kube-apiserver，咱们对于 lite-apiserver 进行了裁剪，大幅度降低了其资源占用。咱们在没有批改原生 kube-apiserver 的状况下，实现了。在网络通顺的状况下，lite-apiserver 组件对于节点组件来说是通明的。当网络异常情况，lite-apiserver 组件会把本节点须要的数据返回给节点上组件，保障节点组件不会受网络异常情况影响。
网络快照机制
OK，lite-apiserver 机制保障了断网状况下，节点也不会和“apiserver”失联。既然节点能够拉取到本节点对应的数据，那么业务 Pod 也就可能被 kubelet 胜利拉起来。下一步就是解决 Pod 之间的相互拜访的问题了。
在边缘容器场景下，思考到适配性以及易用性，咱们采纳了 flannel 组件的 vxlan 模式作为网络解决方案。flannel 组件保障了跨节点之前的网络拜访。节点上的 flannel 以及每个 Pod 都有一些对应属于本人的网络信息，咱们这里采纳了网络快照机制，将专属于这些组件的网络信息定期快照，从而保障了断网环境下重启后网络可用。并且实现了同节点、跨节点 Pod 之间的网络互通。
DNS 解决方案
用户业务对外失常提供服务，以及集群内微服务之间相互调用，这些问题都会波及到域名解析。
如上图所示，在传统 kubernetes 上，通过在集群中创立一个 kube-dns deployment 来解决是来解决域名问题。然而边缘计算集群，所有节点可能是不在一个局域网，很可能是跨可用区的，各节点和 kube-dns 的拜访无奈保障，一个 kube-dns 的 deployment 不能满足边缘容器的需要。
在边缘容器场景下，采纳 DaemonSet 形式部署 kube-dns，保障每个节点都有可用的 kube-dns，同时批改每个节点上 kubelet 启动参数--cluster-dns，将其指向本机 IP。这样就保障了，即便断网状况下，也能解析 kubernetes service 的域名。
总结而言就是 lite-apiserver 机制为根底，kube-proxy、flannel、kube-dns 以及网络快照机制保障了边缘容器集群在弱网环境下的网络可靠性。
实用场景
腾讯云边缘容器产品反对用户在云端通过 kubernetes 形式来治理边缘节点，反对管控平台与 work 节点网络环境拆散，具备弱网环境下的容灾能力，反对用户自定义网络流量，并且所有外围组件都与开源 kubernentes 保持一致，目前曾经反对 1.18 版本。
目前 TKE@EDGE 具备私有云和公有云两种产品状态，欢送来官网体验应用边缘容器私有云产品（https://console.cloud.tencent.com/tke2/edge），产品入口目前为白名单可见，请分割文章作者开明白名单。
后续打算
后续咱们还会有一系列工作，来增强在弱网环境下的工作稳定性。
- 插件化革新。将边缘自治的解决方案革新为插件，提供给传统 kubernetes 某些业务来按需应用
- 反对齐全去中心化 lite-apiserver，来帮助 kube-apiserver 在弱网环境下业务的治理
写在最初
咱们的解决方案对于原生应用 kubernetes 的计划和理念都有所不同，然而我集体认为紧跟业务脚步的产品以及技术才是最有价值的。集体技术能力无限，表白可能有疏漏，技术可能有谬误，欢送大家指出谬误，共同进步。
这里欢送更多有业务场景须要、感兴趣的同学应用、退出、体验，提需要，共优化。欢送扫码加腾小云同学好友，一起进群探讨。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
