在云原生领域，CNCF 旗下的 Kubernetes （简称 K8s） 已经成为容器资源调度和编排的行业事实标准，其屏蔽了底层架构的差异性，帮助应用平滑地运行在不同的基础设施上。在 K8s 一统云计算服务端开发之际，有开发者开始探索用它来管理边缘端的资源调度和编排。
与传统服务端应用不同，边缘计算具有覆盖范围广、带宽成本高、受环境影响大等部署难点，如果要将 K8s 系统延展到边缘计算场景，边缘节点将通过公网和云端连接，从公网的不稳定性以及成本等因素考虑，就需要断网状态或者弱网状态下边缘业务仍可以持续运行，对系统的可用性提出了更高的要求。可一旦在边缘端成功部署，原本难以统一管理的边缘设备就将得到 K8s 带来的云原生技术便利，降低运维成本。
近日，经 CNCF 技术监督委员会投票决议，阿里巴巴云原生边缘计算平台 OpenYurt 正式成为 CNCF 沙箱级别项目。OpenYurt 是由阿里云容器服务团队开发的边缘计算解决方案，采用非侵入式增强 K8s 的设计理念，将 K8s 的能力拓展至边缘端，拥有边缘自治、边缘运维通道 YurtTunnel、一键式转换 K8s 集群等特性。
为深入了解 OpenYurt 项目的创建始末，以及云原生技术在边缘计算场景的发展趋势，我们邀请到了 OpenYurt 项目负责人、阿里云智能技术专家何淋波（花名：新胜），为我们分享了OpenYurt 项目三大特性的技术原理以及相关的行业趋势。
OpenYurt 的诞生背景
采访中，何淋波首先向我们介绍了 OpenYurt 诞生的背景。
2017 年底，作为典型的边缘计算业务，阿里云物联网（IoT）和 CDN 服务正面临着产品规模的爆发式增长、运维复杂度急剧攀升、运维效率不高的“三难”境地，引入云原生并成功转型成为各业务团队亟需解决的问题。同时由于阿里云容器服务团队一直深耕于云原生领域，双方的合作不谋而合。
“得益于阿里云 IoT 团队的容器化，K8s 化需求，促使我们做了‘云边一体’的边缘计算云原生基础设施的产品化思考。经过不断的产品打磨，阿里云容器服务 ACK@Edge 第一个线上版本在 2019 年 5 月份正式公测。”
何淋波介绍，与其他类似产品不同的是，OpenYurt 秉承“Extending your native Kubernetes to Edge”的非侵入式设计理念，拥有可实现边缘计算全场景覆盖的能力。在过去两年内，作为公共云服务 ACK@Edge 的核心框架，OpenYurt 已实现全网覆盖和本地覆盖的全场景落地，全网覆盖的应用场景如 CDN、音视频直播、物联网、物流、工业大脑、城市大脑等；本地覆盖的应用场景和案例如阿里云 LinkEdge、优酷、盒马、AIBox、银泰商城等。
什么是边缘自治
从官方的文档中我们得知，OpenYurt 已开源的特性中包含边缘自治，那么边缘自治具体是一种什么样的能力呢？
何淋波解释，边缘自治能力是指，当边缘资源脱离云端管控时，OpenYurt 既可以保障边缘业务的持续运行(比如云边网络断连时，节点上业务不迁移)，又可以保障边缘业务的弹性(比如边缘节点故障时，节点上业务自动迁移到正常节点上)。
为了可以更好的将云上的能力(如 AI，大数据等)延伸到边缘，OpenYurt 采用了“云边一体”的架构。也意味 OpenYurt 集群的管控组件托管在云端，同时用户的边缘资源通过公网或者专线等方式接入云端管控。
在 OpenYurt 的云边一体架构中，边是指靠近端侧，具备一定计算能力的边缘节点。而边缘终端是更下层的资源，需要通过边缘节点及其上面运行的服务来管控的，即边缘终端的数据上传到边缘节点进行处理，而不用回传云端，而从大大降低对公网带宽的要求。
正是由于边缘自治能力的增强，使得用户可以基于云边一体化架构，获得统一的视角对边缘业务的生命周期进行管理，解决大规模业务的部署，扩容，升级，运维等边缘场景下的常见痛点。
实现边缘自治需要解决的问题
那么在延时敏感、弱网络连接的边缘场景下，实现边缘自治也就需要解决一些技术上的难题。
当边缘资源脱离云端管控时，边缘自治既要保障边缘业务的持续运行，又要保证边缘业务的弹性。从技术上需要解决下面的问题：
问题1: 云端管控: 边缘节点状态的精准识别
边缘节点正常，仅因为和云端网络断连导致脱离管控，这时保障边缘业务持续运行即可边缘节点故障导致脱离管控，这时需要把故障节点的业务迁移到正常节点
问题2: 边缘节点: 网络断连状态下对边缘业务自愈恢复
主要是针对云边网络断连时，边缘节点重启或者业务重启时，边缘节点需要保证边缘业务可以自动恢复并持续运行。
OpenYurt 采用非侵入式对 kubernetes 增强，通过在云端增加独立 yurt controller 组件，边缘增加 yurthub 组件来解决上述问题。具体如下图所示：
![]()
- 解决1: 节点状态感知除了原生的云端通过 NodeLease 监控外，增加边缘感知因素。由于边缘节点之间通过内网连接，因此能够更好的感知节点状态(边缘感知处理待开源)。
- 解决2: 边缘节点上增加 yurthub 组件，接管节点和云端的通信同时把边缘业务的元数据持久化在本地，当云边网络断连时，可以通过本地的元数据来恢复边缘业务。
云边流量控制
OpenYurt 的第二个特性是边缘运维通道 YurtTunnel 。官方文档显示，YurtTunnel 通过在管控与边缘节点之间建立反向通道，和节点的生命周期完整联动，承载原生运维 APIs 的流量。那么 YurtTunnel 是否会对边缘网络带宽提出更高的要求呢？
面对我们的疑问，何淋波介绍了 YurtTunnel 的技术原理。OpenYurt 的边缘运维通道 YurtTunnel 主要用于解决边缘节点位于用户内网中，从云端往边缘下发运维指令的需求(如: kubectl logs/exec 等)。在云端节点上部署 Yurt-Tunnel-Server，同时在每个边缘节点上部署一个 Yurt-Tunnel-Agent(待边缘单元能力开源后，也可以每个单元部署一个)。
当 Yurt-Tunnel-Agent 启动时，会根据配置自动发起请求和云端 Yurt-Tunnel-Server 建立 TCP 连接。此后云端将基于该 TCP 长连接往边缘下发指令。同时并不会对带宽提出额外需求。server 和 agent 间的长连接只会定时发送 keepalive package，keepalive 的 request body 为空，所以并不需要增加多少额外带宽。
此外，云边通道上的也有相应的流量控制机制。首先，server 接到的是 apiserver 发来的请求，apiserver 已经会进行限流(qps)。目前考虑在 tunnel server 端针对单一用户做限流，可以在 server 端对每一名用户（不同用户可以根据 src ip 区分）限定在单位时间内可以转发的请求数。如果用户发送 request 过于频繁，可以延迟或者丢弃转发该用户的请求。
保持原生 K8s 零侵入
OpenYurt 的另一个特性是对原生 K8s 的“零侵入”，可以实现原生 K8s 集群一键式转换为边缘集群，从技术上来说，这种“一键式转换”又是如何实现的呢？
从 OpenYurt 的架构图来看，蓝色框是原生 k8s 组件，橙色框是 OpenYurt 组件：
![]()
整个转换方式主要包括两个部分：
- Yurt Controllers 和 Yurt Tunnel 的部署: 直接通过常见 workload（deployment，daemonset）模式部署。
- YurtHub： 需要以 static pod 形式部署在节点上，以确保其生命周期与 kubelet 同步。因此以 job 形式，通过在目标边缘节点上运行 privilege pod ，从而完成 static pod(yurthub) 的部署。
可以通过下述命令完成原生 K8s 到 OpenYurt 的转换：
_output/bin/yurtctl convert --provider [minikube|ack]
OpenYurt 的未来
最后，何淋波向我们透露了 OpenYurt 项目第三季度的版本迭代计划：
- 添加 Yurt 隧道服务器/代理以启用跨 Intranet /防火墙的云到边缘网络通信。
- 升级 openyurt 组件以支持 Kubernetes 1.18。
- 引入 YurtClustercrd 来帮助管理自治边缘节点并实现 crd 控制器。
- 添加 YurtUnit 功能并启用 YurtUnit 自治功能。
- 添加基本的 Pod 网络恢复机制以处理边缘节点重启。
- 改善 YurtCtl 用户体验。
- 添加更多的 e2e 测试用例并提高总体代码覆盖率。
何淋波表示，作为对原生 K8s 完整生态全部兼容的智能开放平台，OpenYurt 还将基于行业场景与 5G、AI、大数据、区块链等新兴技术结合。未来 OpenYurt 将以开源社区为基础，致力于推进云原生技术在边缘计算领域的生态建设与普及，与全球开发者一起拓展云原生的边界。
采访嘉宾介绍
![]()
何淋波（花名：新胜），阿里云智能技术专家，主要从事 Kubernetes 相关产品的设计研发工作，致力于探索云原生新落地场景。先后负责或参与物联网边缘计算、ACK@Edge 等相关产品的设计与研发工作。目前负责阿里云原生边缘计算平台 OpenYurt 的开源工作。
OpenYurt 详细信息：点击查看
OpenYurt 项目下载：点击下载
