作者 | 新胜  阿里云技术专家

导读：OpenYurt 开源两周以来，以非侵入式的架构设计交融云原生和边缘计算两大畛域，引起了不少行业内同学的关注。阿里云推出开源我的项目 OpenYurt，一方面是把阿里云在云原生边缘计算畛域的教训回馈给开源社区，另一方面也心愿减速云计算向边缘延长的过程，并和社区独特探讨将来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，咱们顺便推出 【深度解读 OpenYurt】 系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩大能力。

系列文章举荐：

• OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力
• 深度解读 OpenYurt：边缘自治能力设计解析

OpenYurt 介绍

阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt，跟其余开源的容器化边缘计算计划的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 零碎零批改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。

同时随着 OpenYurt 的继续演进，也肯定会持续放弃如下倒退理念：

• 非侵入式加强 K8s
• 放弃和云原生社区支流技术同步演进

YurtHub 架构阐明

在上篇文章中，咱们介绍了 OpenYurt 的边缘自治能力，重点解读了其中的组件 YurtHub。其架构图如下：

同时在介绍 YurtHub 的劣势中咱们提到 与 Kubernetes 设计理念符合，YurtHub 非常容易扩大出更多的能力。具体在 YurtHub 扩大出了什么能力呢？接下来咱们将一一开展介绍。

YurtHub 的扩大能力

1. 边缘网络自治

首先介绍一下何谓边缘网络自治：即在边缘和云端网络断连时，不论时业务容器重启，或是边缘节点重启等，边缘业务的跨节点通信能够继续工作或是主动复原。

在 OpenYurt 中，实现边缘网络自治须要解决如下的问题（以 flannel vxlan overlay 网络为例）：

• 问题 1: 节点上的网络配置能够自治，kube-proxy 的 iptables/ipvs 规定，flannel 的 fdb/arp/route 配置，coredns 的域名解析等网络配置，在节点重启后能够主动复原，否则边缘跨节点通信将无奈继续；
• 问题 2: 业务容器 IP 放弃不变，因为和云端网络断连状态下容器 IP 变动将无奈告诉到其余节点；
• 问题 3: vtep(vxlan tunnel endpoint) 的 mac 地址放弃不变，起因和容器 IP 放弃不变相似。

从问题 1 能够看出，必须解决 kube-proxy/flannel/coredns 等组件的自治，能力实现网络配置的自治。如果之前边缘自治是采纳重构 kubelet 来实现的话，要实现边缘网络自治就会碰到很大的麻烦，如果强行把重构的 kubelet 自治能力移植到各个网络组件 (kube-proxy/flannel/coredns)，也对整个架构将是噩梦。

在 OpenYurt 中因为 YurtHub 的独立性，kube-proxy/flannel/coredns 等网络组件轻松应用 YurtHub 来实现网络配置的自治能力。因为 YurtHub 缓存了 service 等网络配置资源在 local storage，即便断网并且节点重启，网络组件依然能够取得断网前的 object 状态以及相应的配置信息。如下图所示:

问题 2，3 和 Kubernetes core 无关，次要波及到 cni 插件和 flanneld 的加强，后续文章中再具体介绍。

2. 多云端地址反对

私有云上的 Kubernetes 高可用部署时，多实例 kube-apiserver 后面个别都挂了一个 SLB，然而在专有云场景下或者边缘计算场景下，节点须要通过多个云端地址来拜访。比方:

• 专有云场景：因为没有 SLB 服务，用户须要须要在云端通过 VIP 形式来自行实现 kube-apiserver 的负载平衡，或者像 kubespray 那样在每个节点上部署一个 nginx 来实现多云端地址的拜访；
• 边缘计算场景: 思考到边缘和云端之间网络的稳定性和安全性要求，某些场景下用户也通过专线和公网两种形式和云端通信，比方优先采纳专线，当专线故障时能主动切换到公网通信。

YurtHub 正式思考到了上述的需要，反对多云端地址拜访。云端地址的负载平衡模式能够抉择：

• rr(round-robin)：轮转模式，默认抉择该模式；
• priority: 优先级模式，高优先级地址故障后才应用低优先级地址。

具体能够参照 YurtHub 的 LB 模块，如下图所示：

3. 节点维度的云端流控

对于一个分布式系统来说，流控都是一个无奈回避的问题。原生 Kubernetes 从集群视角在 kube-apiserver 中以及从访问者视角在 client-go 库中封装了流量管控，在边缘计算场景下，client-go 的流量管控既扩散又对业务有肯定侵入，显然不能很好的解决流控问题。

YurtHub 在边缘能够接管不论是零碎组件还是业务容器对云端拜访的流量，能够很好的解决节点维度的云端流控问题。目前 YurtHub 的流控配置是：单节点上对云端的并发申请数超过 250 个时，将回绝新的申请。

4. 节点证书轮换治理

Kubernetes 曾经反对节点证书主动轮换，即当节点证书快过期前，kubelet 会主动向云端申请新的节点证书。然而在边缘计算场景下，很有可能因为边缘和云端网络的断连，造成 kubelet 将无奈实现证书的轮换。证书过期后即便和云端网络连接复原，节点证书也可能无奈主动轮换，并造成 kubelet 的频繁重启。

YurtHub 在接管节点和云端通信流量时，同时也能够接管节点的证书治理。这样既解决了各类装置工具对节点证书的治理的不统一，也解决了证书过期后网络再复原时的证书轮换问题。另外目前 YurtHub 还是 kubelet 共享节点证书，YurtHub 的独立节点证书治理性能将在近期开源。

5. 其余

YurtHub 除了后面介绍的扩大能力，还有很多有价值的能力，在此也简略介绍：

• 节点多租隔离治理：在具备多租隔离能力的 Kubernetes 集群中，假设节点归属于某个租户，那么 YurtHub 将能够确保节点上所有云端申请都只返回节点所属租户的资源。比如说 list service 将只返回该租户的 service。而这种多租隔离能力不须要其余组件做任何批改。当然如果要实现集群内的多租隔离，须要配合相应的多组 CRD 等，具体能够参照我的项目 kubernetes-sigs/multi-tenancy；
• 集群间节点迁徙：某些场景下，边缘节点须要从集群 A 迁徙到集群 B，惯例操作是先从集群 A 下线，而后再次接入集群 B，最初在集群 B 部署节点上的利用。因为 YurtHub 对节点流量以及节点证书的接管，能够间接对 YurtHub 注入集群 B 的信息，让节点无损迁徙到集群 B；
• 通过域名拜访云端 kube-apiserver 等等一些其余性能。

总结

• 通过上述的扩大能力能够看出，YurtHub 不仅仅是边缘节点上的带有数据缓存能力的反向代理。而是对 Kubernetes 节点利用生命周期治理加了一层新的封装，提供边缘计算所须要的外围管控能力；
• YurtHub 不仅仅实用于边缘计算场景，其实能够作为节点侧的一个常备组件，实用于应用 Kubernetes 的任意场景。置信这也会驱动 YurtHub 向更高性能，更高稳定性倒退。

参考链接

• kubespray: HA endpoints for K8s

OpenYurt 我的项目地址：https://github.com/alibaba/openyurt，欢送大家参加共建！有疑难可退出钉钉交换群：31993519

课程举荐

为了更多开发者可能享受到 Serverless 带来的红利，这一次，咱们集结了 10+ 位阿里巴巴 Serverless 畛域技术专家，打造出最适宜开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。

点击即可收费观看课程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”