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

北京时间 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,从而大幅降低云边的数据通信量。如下图:

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

  • 节点池中所有 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 保持的能力。如下图:

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

  • 节点的云边网络正常时,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 可以提供更通用的跨地域通信能力(云边互通/边边互通),如下图:

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

  • 每个节点池内选出一个 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 如下:

相关链接

[1] 测试https://openyurt.io/zh/docs/t...
[2] 1049https://www.yuque.com/r/goto?...
[3] 1065https://www.yuque.com/r/goto?...
[4] 1158https://www.yuque.com/r/goto?...[5] 1066https://github.com/openyurtio...

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

原文链接

本文为阿里云原创内容,未经允许不得转载。

你可能感兴趣的:(OpenYurt v1.2 亮点速览丨云边流量峰值相比原生 K8s 降低 90%)