Skip to main content

从边缘自治看YurtHub的扩展能力

· 阅读需要 1 分钟
rambohe
rambohe
Maintainer of OpenYurt

导读：OpenYurt 自开源以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。 本文主要介绍了 OpenYurt 中组件 YurtHub 的扩展能力。

OpenYurt介绍​

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

同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念：

  • 非侵入式增强 K8s

  • 保持和云原生社区主流技术同步演进

YurtHub架构说明​

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

image

与Kubernetes设计理念契合，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 状态以及相应的配置信息。如下图所示:

image

问题 2，3 和 Kubernetes core 无关，主要涉及到 cni 插件和 flanneld 的增强，后续文章中再详细介绍。

2）多云端地址支持​

公有云上的 Kubernetes 高可用部署时，多实例 kube-apiserver 前面一般都挂了一个 SLB，但是在专有云场景下或者边缘计算场景下，节点需要通过多个云端地址来访问。比如:

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

YurtHub正式考虑到了上述的需求，支持多云端地址访问。云端地址的负载均衡模式可以选择：

  • rr(round-robin)：轮转模式，默认选择该模式；

  • priority: 优先级模式，高优先级地址故障后才使用低优先级地址。

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

image

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 向更高性能，更高稳定性发展。

原文链接