关于云原生:OpenYurt-v12-亮点速览丨云边流量峰值相比原生-K8s-降低-90

2次阅读

共计 3381 个字符，预计需要花费 9 分钟才能阅读完成。

北京工夫 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，从而大幅升高云边的数据通信量。如下图：

节点池中所有 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 放弃的能力。如下图：

节点的云边网络失常时，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 能够提供更通用的跨地区通信能力(云边互通 / 边边互通)，如下图:

每个节点池内选出一个 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/openy…
SIG DataPlanehttps://github.com/orgs/openy…
SIG IoThttps://github.com/orgs/openy…

[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…