导语：边缘计算模式下，云端的控制中心和边缘端的设备之间网络环境较复杂，网络质量差次不齐没有保障。用户每每但愿在弱网环境下，边缘容器能提供高可用的业务能力。TKE 边缘容器团队在弱网环境下提出了边缘自治功能。本文着重介绍了边缘容器在弱网环境下为了保证业务高可用而作的工做。docker
问题背景
边缘计算使用的边缘设备数量庞大、分布全国各地，网络环境复杂，因特网、以太网、5G、WIFI 等形态均有可能。所以，云端的控制中心和边缘端的设备之间网络环境较复杂，网络质量差次不齐没有保障。api
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 的方案和理念都有所不一样，可是我我的认为紧跟业务脚步的产品以及技术才是最有价值的。我的技术能力有限，表达可能有疏漏，技术可能有错误，欢迎你们指出错误，共同进步。
这里欢迎更多有业务场景须要、感兴趣的同窗使用、加入、体验，提需求，共优化。欢迎扫码加腾小云同窗好友，一块儿进群讨论。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！