OpenYurt v1.2 亮点速览丨云边流量峰值相比原生 K8s 降低 90%

2023-02-16
浙江
本文字数：2996 字
阅读完需：约 10 分钟

本文作者：
何淋波: 阿里云技术专家
陈绍强: Intel 资深软件架构师
俞林: Intel 高级软件工程师

北京时间 1 月 30 号发布的 OpenYurt v1.2.0 版本，社区呼声最高的几大特性终于落地，OpenYurt 的特点更加鲜明，主要特点包括：Kubernetes 无侵入，云边端全协同，可编程的资源访问控制，以及声明式云原生设备管理。

v1.2 版本聚焦在节点池治理，重点打造 OpenYurt 系统的差异化技术竞争力，主要特性有降低云边通信的流量成本，边缘自治能力增强，更丝滑的跨地域通信能力等。

大幅降低云边通信流量成本

在云边协同场景下，边缘通过公网和云端连接，当集群中部署了大量的业务 Pod 和微服务系统(引入大量 Service 和 Endpointslices)，边缘节点和云端之间需要消耗大量带宽，给用户带来极大的公网流量成本压力。

社区对降低云边通信流量一直有比较强的诉求，如何在不侵入修改 Kubernetes 的基础上满足需求，首先大家比较容易考虑到的方案是在节点池内增加一个 sync 组件，实时同步云端的数据，然后再分发给节点池中的各个组件。但是这个方案落地将面临不小的挑战，首先数据访问请求都是边缘主动向云端发起的，sync 如何拦截这些请求并分发数据呢？同时如果 sync 组件故障，边缘的请求将面临中断，而保障 sync 组件的高可用会非常棘手。

OpenYurt 社区首创基于 pool-coordinator+YurtHub 的云边流量复用机制，既与原生 Kubernetes 的云边通信链路无缝融合，又优雅的保障了通信链路的高可用(YurtHub Leader 选举)，实现云边通信成本的消减。

在节点池内，节点从云端获取的数据，可以分为两种类型：

pool scope data: 组件从云端获取的数据完全一致，如每个节点的 kube-proxy 获取到的 endpointslices
node scope data: 组件从云端获取的数据和自身节点相关，如每个节点的 kubelet 获取到的 pods

同时通过**测试 [ 1] **发现，真正占用云边带宽的数据是 pool scope data。OpenYurt v1.2 中通过在节点池中复用 pool scope data，从而大幅降低云边的数据通信量。如下图：

1.png

节点池中所有 YurtHub 组件通过节点池中的 Pool-Coordinator 进行选举产生 Leader，只有和云端网络连接正常的 YurtHub 才会成为 Leader。当 Leader 节点的云边网络连接异常时，Leader 将被其他 Follower 自动接替。
Yurthub Leader 主动从云端实时获取 pool scope data(如 Endpointslices)，然后存入节点池的 Pool-Coordinator 组件中
节点上组件(如 Kube-Proxy)通过 Yurthub 来获取 pool scope data 时，Yurthub 将从 Pool-Coordinator 返回实时的数据。

通过 Pool-Coordinator 和 Yurthub 的协同，单一节点池内云边只有一份 pool scope data 通信数据，从而大幅降低云边的通信数据量，相比原生 Kubernetes 云端出口流量峰值降低 90%。

另外带来一个有意思的能力，通过 Endpointslices 的流量复用，即使边缘节点与云端网络断开，仍然可以实时感知集群的服务拓扑状况。

边缘自洽能力增强

在云边协同场景下，边缘自治能力可以保障边缘业务持续提供服务。边缘自治能力既包括在边缘侧提供数据缓存，解决云边网络断连状态下节点重启时业务的恢复问题，同时也包括管控侧(云端控制器)对 Pod 驱逐策略的增强。

在原生 Kubernetes 中，边缘节点心跳一定时间没有上报时，云端控制器将对节点上 Pod 进行驱逐(删除并在正常节点上重建)。

云边协同场景下，边缘业务有不一样的需求。业务期待云边网络断连造成心跳无法上报时(此时节点本身正常)，业务 Pod 可以保持(不发生驱逐)，仅节点故障时才对 Pod 进行迁移重建。

比云边公网连接的复杂网络情况，同一个节点池内的节点处在一个局域网，网络连接状况良好。业界常用的方案是边缘节点间相互网络探测，构建一个分布式的节点健康状态检测机制。但是该方案中的网络探测会产生不小的东西流量，同时每个节点也需要增加一定的计算，随着节点池规模增大，检测效果会面临一定的挑战。

OpenYurt v1.2 版本首创基于 pool-coordinator+YurtHub 的中心式心跳代理机制，既可以减少节点池内的东西向通信流量，又降低了整体算力需求。同时也提供云边网络断连时 Pod 保持的能力。如下图：

2.png

节点的云边网络正常时，Kubelet 通过 YurtHub 组件同时上报心跳到云端和 Pool-Coordinator 两处。
节点的云边网络断连时，Kubelet 通过 YurtHub 组件上报心跳到云端失败，此时上报到 Pool-Coordinator 的心跳带上特定标签。
Leader YurtHub 会实时 list/watch pool-coordinator 中的心跳数据，当获得的心跳数据中带有特定标签时将帮助转发该心跳到云端。

通过 Pool-Coordinator 和 YurtHub 协同实现的心跳代理机制，成功保障了节点在云边网络断连状态下，心跳仍可继续上报到云端，从而保证节点上业务 Pod 不被驱逐。同时心跳被代理上报的节点，也会被实时加上特殊的 taints，用于限制管控调度新 Pod 到该节点。

更丝滑的跨地域通信能力

OpenYurt 社区的 Raven 项目已经演进到 v0.3 版本，主要提供跨地域的 3 层通信能力。相比 Yurt-Tunnel 提供的云边隧道仅支持云到边的 7 层流量转发，Raven 可以提供更通用的跨地域通信能力(云边互通/边边互通)，如下图:

3.png

每个节点池内选出一个 Gateway 节点(Solo 节点自动为 Gateway 节点)，Gateway 节点通过云端建立 VPN 隧道，通过 Raven 在每个节点上配置流量转发规则。
跨节点请求将被拦截，并转发到 Gateway 节点，再经过 VPN 隧道转发到对应的节点或 Pod。同时节点池内的访问流量不被拦截，通过原生 CNI 容器网络方案通信。

Raven 方案和原生 CNI 容器网络方案无缝兼容，跨地域的流量转发对应用本身是无感知状态，因此在云边/边边的跨地域通信中，OpenYurt 中应用互访可以保持原生 Kubernetes 中的一致使用体验。从 OpenYurt v1.2 开始，我们推荐使用 Raven 来代替 YurtTunnel。

其他重要更新

yurtadm 组件优化，底层完全基于 kubeadm 二进制实现，保持与 Kubernetes 社区良好的兼容性 #1049 [ 2]
云边协同场景下边缘 static pod 的优雅升级方案 proposal #1065 [ 3]
增加 inclusterconfig 过滤器，用于保证 kube-proxy 通过 YurtHub 链路访问 kube-apiserver #1158 [ 4]
解决 YurtHub 对转发 Watch 请求时，response 中单个返回数据超过 32KB 会截断的问题 #1066 [ 5]

未来计划

OpenYurt v1.2 版本能够顺利发布，这里再次感谢来自 Intel，美团，阿里云，浙大，同济，索尼，浪潮，京东等数十位同学的大力贡献。

目前 OpenYurt v1.3 版本的开发正在稳步推进，欢迎有兴趣的同学来参与共建，共同探索一个稳定，可靠的无侵入云原生边缘计算平台的事实标准。各 SIG RoadMap 如下：

SIG ControlPlanehttps://github.com/orgs/openyurtio/projects/11
SIG DataPlanehttps://github.com/orgs/openyurtio/projects/9
SIG IoThttps://github.com/orgs/openyurtio/projects/2

如果您对于 OpenYurt 有任何疑问，欢迎使用钉钉扫描二维码或者搜索群号（12640034121）加入钉钉交流群。

4.png

创作场景