作者 | 黄玉奇（徙远） 阿里巴巴高级技术专家
关注“阿里巴巴云原生”公众号，回复关键词 1219 即可下载本文 PPT 及实操演示视频。
导读：伴随 5G、IoT 的发展，边缘计算正在成为云计算的新边界，而规模和复杂度的日益提升对边缘计算的效率、可靠性、资源利用率等一系列能力又提出了新的诉求。试想，如果能将云能力从中心往边缘触达，上述问题是不是将迎刃而解？在云原生时代构建云到边的触达通路，保持云边一致性体验，我们的抓手又在哪里呢？本文将一一为你揭晓。
云原生的理念现今正如火如荼。它不仅仅是一种技术，更是随着云生态的发展而被逐渐提炼出的一系列技术、最佳实践与方法论的集合；它带来了资源利用率提升、分布式系统的弹性扩展与可靠性等能力，能够让 IT 系统最大程度的享受云计算红利，业界全面拥抱云原生就是最好的佐证。
云原生概念
云原生的概念最早是在 2013 年被提出，经过近几年的发展，尤其是从 2015 年 Google 牵头成立 CNCF 以来，云原生技术开始进入公众的视线并逐渐演变成包括 DevOps、持续交付、微服务、容器、基础设施、Serverless、FaaS 等一系列的技术、实践和方法论集合。伴随着技术的普及，与之相配套的团队建设、技术文化、组织架构和管理方法也呼之欲出。
越来越多的企业选择云原生构建其应用，以此来获得更好的资源效率和持续的服务能力。相比较过往着力云原生概念的普及、理解和力求共识，云原生落地已经成为现如今 I/CT 日常主旋律。
云原生的技术范畴包括了以下几个方面：云应用定义与开发、云应用的编排与管理、监控与可观测性、云原生的底层技术（比如容器运行时、云原生存储技术、云原生网络技术等）、云原生工具集、Serverless。
虽然，CNCF 以目前 200 多个项目和产品（CNCF 云原生全景）的巨大体量保持高速发展，不断壮大云原生体系的技术集合，但所有项目基本都在上述技术范畴中，紧守云原生理念不放。
那么云原生的核心优势到底有哪些？能带给我们真实体感又是什么呢？
引用 CNCF 的重新定义："Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."
云原生和边缘基础设施
在云计算真正普及之前，获取基础设施能力（比如服务发现、流量控制、监控与可观测性、访问控制、网络控制、存储层抽象等）需要应用通过某种抽象或接口方式，使得两者之间是非常紧密的耦合关系，应用本身的能力和演进需要强依赖基础设施。
而在云原生时代，类似 Kubernetes 这样的标准化资源抽象、编排、整合平台促进基础设施能力正在不断下沉，云能力和应用之间的隔阂也正在云原生技术体系下被不断瓦解。“面向云架构”、“面向云编程”的呼声日渐高涨的同时，cloudnative 的云基础设施越来越“友好”。但是，云原生基础设施概念远远超出公有云上运行的基础设施范畴。
“软硬件技术的成熟、巨大的社会价值和伟大的商业模式”造就了云计算的兴起和蓬勃发展，迅猛的势头也催生了各种新型技术架构的诞生，我认为云原生的出现同样是顺应了技术和商业的浪潮。
放眼当下，随着互联网智能终端设备数量的急剧增加和数据、业务下沉的诉求增多，边缘计算规模和业务复杂度已经发生了翻天覆地的变化，边缘智能、边缘实时计算、边缘分析等新型业务不断涌现。传统云计算中心集中存储、计算的模式已经无法满足边缘设备对于时效、容量、算力的需求，如何打造边缘基础设施成了一个新课题。
本次分享也是从这个问题出发，和大家一起探讨云原生基础设施在边缘计算落地的可能性。
试想，从云到端，是否能将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控，通过粘合云计算核心能力和边缘算力，构筑在边缘基础设施之上的云计算平台？
在回答这个问题之前，我们先梳理一下边缘计算可能面临的一些挑战：
- 云边端协同：缺少统一的交付、运维、管控标准；
- 安全：边缘服务和边缘数据的安全风险控制难度较高；
- 网络：边缘网络的可靠性和带宽限制；
- 异构资源：对不同硬件架构、硬件规格、通信协议的支持，以及基于异构资源、网络、规模等差异化提供标准统一的服务能力的挑战。
这些问题云原生模式能够解决吗？云原生的技术底座 Kubernetes 能撑起大梁吗？
众所周知，以 Kubernetes 为基础的云原生技术，核心价值之一是通过统一的标准，实现在任何基础设施上提供和云上一致的功能及体验。那么借助云原生技术，实现云-边-端一体化的应用分发，解决在海量边、端设备上统一完成大规模应用交付、运维、管控的诉求是不是就有可能呢？
同时在安全方面，云原生技术可以提供容器等更加安全的工作负载运行环境，以及流量控制、网络策略等能力，能够有效提升边缘服务和边缘数据的安全性。而依托云原生领域强大的社区和厂商支持，云原生技术对异构资源的适用性逐步提升，在物联网领域，云原生技术已经能够很好地支持多种 CPU 架构 (x86-64/arm/arm64) 和通信协议，并实现较低的资源占用。
K8s 虽好，但落地边缘计算场景好像还有一段路要走。
Kubernetes 概念
基本概念
“Kubernetes——让容器应用进入大规模工业生产，已然成了容器编排系统的事实标准”。
下图是 Kubernetes 架构图：
- 核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境；
- 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）；
- 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）；
- 接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦；
- 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴（内部/外部）。
- Kubernetes 外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等；
- Kubernetes 内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等。
Kubernetes 落地形态
随着 Kubernetes 的普及，越来越多的上层系统开始搭建在 Kubernetes 底座之上，比如 CICD、Serverless、IoT、PaaS 等业务。过往经验告诉我们，在享受 Kubernetes 带来的方便快捷集成体验的同时，Kubernetes 的自身运维也带来了额外的巨大工作量：Kubernetes 的升级、高可用部署，资源对接、监控、事件告警、多租管理等等。因此，专门的运维团队、运维工具，以及公有云托管服务就应运而生了，这也是当前业界 Kubernetes 几种常见的服务形态。
先说说公共云托管 Kubernetes 服务，目前主流云厂商基本上都推出了 XKS/XCK 的服务，虽然底层实现各异，但是都有着类似的用户体验。用户只需要在云厂商界面提交集群配置，点击购买按钮，一个高可用的、无缝对接各种云资源及云服务的 Kubernetes 集群就能够在 3-5 分钟内被创建出来；且后续的集群升级、运维、扩缩容等运维操作都是动动小手的白屏化操作，体验简捷到极致。
Kubernetes 强大的接口能力也能够让用户快速便捷的按需使用上各厂商的 IaaS 资源。综合各种因素，公共云托管 Kubernetes 服务正成为大多数用户的选择。但往往也有出于各种数据安全、集群规模、价格因素等考虑，部分用户会选择自建或者使用云厂商的专有云 Kubernetes 版本、混合云版本。
如果从 Kubernetes 层面考量，三者本质都大同小异，依赖第三方提供一个稳定、兼容、安全可持续发展的商业化 Kubernetes 底座，以期得到规模化、标准化的 K8s 服务能力。
重新回到前面的问题，边缘计算基础设施既要云原生，又要云边一体，还要一致性体验，那么使用云端托管、边缘定制会不会是一个很好的选择呢？接下来展开叙述。
云端管控、边缘自治
“云边端一体化协同”作为标准化的一个构想，将标准化的云原生能力向边缘端复制，需要分为三个层次：
- 第一个层次是能够在云端提供标准化的接口、管控能力，或者是标准的云服务和云资源的接入能力，其中我们能够看到 Kubernetes 的身影；
- 第二个层次是能够高效的管理处在整个边缘端的众多资源，其中包括在边缘端应用的效率问题；
- 第三层次是典型的 IoT 场景中的端设备，例如智慧楼宇智能停车设备，蓝牙设备、人脸识别设备等。
云端托管原生 K8s
先看最核心的云端托管层，在云边一体的设计理念中，自然而然的能够联想到将原生的标准 K8s 托管在公共云上，开箱即用各种被集成的云能力必定是不二之选。K8s 免运维上面已经谈到了几点原因，原生的 K8s 便于被上层业务系统集成，却常常被忽视，通过云厂商将 Kubernetes 和其他云能力（弹性、日志监控、应用市场，镜像服务等）打通，无论是终端用户直接使用，还是做新业务创新，复杂度都大大降低。
此外，将云管控作为中心式服务，通过提供统一管控能力，反而非常适合管理边缘场景中零散分布的计算资源和应用，比如 CDN 服务、IoT 业务等；最后，云原生的方式又可以让用户以往的 K8s 经验用于新的边缘计算业务。
上图所示的管控架构也符合前文提到的云边分层结构：“分而自治，中心管控”。
适度定制适配边缘场景
K8s 除了上述特征之外，还有一个强大的插件机制，CxI 自不必说，CRD、Operator 更是让 K8s 如虎添翼。在面向边缘场景，自然而然会有一些别样的逻辑需要适配，例如：边缘节点和云端管控走弱连接公网交互带来的管理逻辑适配；边缘节点应用驱逐逻辑适配；边缘节点支持原生运维接口适配等等。
插件化的非侵入方式可以让原生 K8s 在免受任何冲击的同时，扩展更多的逻辑，比如用来做边缘单元化管理的 EdgeUnit Operator 再比如做边缘节点自治管理的 EdgeNode Operator。
前文提到，边缘托管集群要将运维能力统一收编到云端，中心式的运维能力高效又便捷。所以，除了各种控制器之外，云端还有各种运维控制器来做日志、监控数据等请求的转运，如：日志控制器，MetricServer 等；EdgeTunnelServer 提供了一条稳健的反向数据通道，很多云到边的请求都要从此经过，至于它的用途后面进行讲解；
如上图所示，每个 Edge 节点上配备了一个 EdgeHub 组件，边缘节点自治离不开它。
先说说背景，众所周知 K8s 原生设计为数据中心内部的容器编排系统（DCOS），默认网络可靠、可信。管控端（apiserver、调度器、资源控制器）源源不断收集节点心跳做相应的调度决策，若 worker 节点和管控断链，原生 K8s 管控就要将节点置为不可用、并驱逐应用（容忍时间到了之后）。而这些看似再正常不过的业务逻辑，在边缘场景却是万万不可接受的。
在“分而自治，中心管控”的设计理念下，woker 节点和中心管控走弱连接的公网交互，各种环境、网络、人为因素都会带来网络的抖动甚至是不可用。但此时，边缘节点上的业务和 agent 却要能够持续提供服务，这就是自治。概括起来还包括 worker 节点和云端断连后：
- 节点上 agent（kubelet、proxy 等）无感知持续运行，就像还稳稳的连着 master（其实是要骗骗它们）；
- 节点间东西向流量持续稳定交互（老师不在，同学们自己上自习）；
- 节点重启后，节点上管控元信息和应用原信息能够恢复原样，因为没法通过管控配置中心同步（邮局关门，我不能给你写信，我就在原地等你带着青春容颜--mac 地址保持、podIP 保持等）；
EdgeHub 作为节点上的临时配置中心，在断链情况下，持续为节点上所有设备提供断网前一刻的配置服务。数据持久化在本地磁盘，和节点共存亡，EdgeHub 上实现了诸多 K8s api，除了给 agent 用，节点上承载的业务 pod 也可以使用，轻量又便捷。
原生运维支持
说完边缘端，再来说说云边链接的“脐带”--EdgeTunnel。用过 K8s 命令行工具--kubectl 的同学，肯定会对 "kubectl exec，kubectl logs， kubectl attach，kubectl top" 等运维命令直呼过瘾，原理也很简单，大致就是 apiserver 建联到 kubelet 提供长链接支持。
但是在边缘场景，由于大多数边缘节点没有暴露在公网之上，主动的云到边的网络建链突然变成不可能，所有的原生运维 api 黯然失效。
EdgeTunnel 的设计目的就是为了弥补这份缺失，它通过在管控与边缘 worker 节点之间建立反向通道，并和 worker 节点的生命周期完整联动，支持证书配置、支持 websocktet 等等。我们看到最终 apiserver 通过它按需中转，metricserver（K8s 原生运维工具）通过它按需中转......
至此，这条宽似太平洋的通道让运维接口又转动起来，既安全又高效，皆大欢喜。
边缘单元
在真实落地过程中，我们发现边缘场景还真的是新奇又多彩。先卖个关子：
客户 A，IoT 厂商，他们负责交付安防设备到商场、机场、火车站等；但是各场所的资源、应用管理诉求不同，客户希望能够一次提交，单元化管理，且要有“逻辑多租能力”：流量单一场地闭环，部署按场地调度；
客户 B，CDN 厂商，机房遍布世界各地，海外和国内业务部署差异明显，资源规格各异；希望能够将资源分组，为后续开展不同业务铺垫。单元化、单元化流量管理、单元化调度、批量管理？K8s 好像没有这个能力，但是 K8s 的自定义资源控制器（CRD&Operator）提供了一条方便的解决途径。
通过 K8s 的扩展机制，在原生 K8s 基础上我们增加了 edgeunit 的管控逻辑：
- 分属同一个 edgeunit 的 worker 节点，可以批量控制节点上的标签、annotation，设置节点调度状态等等；
- 用户提交应用，可以按照单元化部署；如用户提交一份 "deployment" 配置，通过边缘单元的调度控制，可以在每个 edgeunit 中被克隆部署；除了批量管理之外，也可以赋予“单元”的独立控制能力，灵活高效；
- 用户的服务流量控制，可以在单元内闭环。大家都知道，原生 K8s Service 提供的集群内东西流量交互，是不会感知边缘场景下节点位置属性而做额外处理的，但是出于数据安全或天然的网络隔离等考虑，我们需要将东西流量限制在一个边缘单元内，这也是 edgeunit 在 service 管理上需要额外设计的逻辑。
轻量化
上文提到，边缘算力的涵义颇广，包括：规模较大的 CDN 资源，通常被称之为“另一朵云”的边缘基础设施；也有浩如烟海的 IoT 的边缘设备，算力规模小但是数量庞大。
在处理 IoT 场景云原生转型问题上，轻量化是绕不开的一环。我们知道，IoT 业务场景充斥着大量的异构、小规格的边缘算力，像各种智能终端、设备，它们对资源的约束是极致的，难于接受额外的资源占用。所以，首当其冲的必然是管控层面的轻量化，简单介绍下目前常见的技术尝试：
- 管控组件的轻量化替代和压缩，如 containerd 替代 docker，以及减少额外 node sidecar 的部署和开销方案等；
- 管控组件的裁剪，在 K8s 体系下对 kubelet 相关功能的裁剪和模块化，社区也有类似方案。
边缘 K8s 用在哪里
那么回头再看，是否还有一个问题我们还没有讨论到：边缘容器/K8s 到底用在哪里？一言以蔽之，Edge Kubernetes 适用于需要通过中心统一管控远端机房、服务器、设备的场景，轻松实现云、边、端一体的应用交付、运维、管控能力。
- 在 IoT 领域，可用于工厂、仓库、楼宇、园区、高速收费站等场景；
- 在 CDN 领域，可以支持视频直播、视频监控、在线教育等行业客户就近计算和存储的需求；
- 在 ENS 边缘计算产品上，提供了针对 ENS 边缘实例的 DevOps 能力，方便针对边缘的应用分发及部署运维。
阿里云容器服务边缘托管 ACK@Edge
人们常说“技术的发展有其自身的内在直接动力”，而阿里云边缘云原生的产品化落地动力却是实实在在的客户场景催生。大致分以下几个阶段：
第一阶段：云边一体概念萌生
众所周知，阿里云在两大边缘计算领域 CDN 和 IoT 深耕已久，边缘规模和业务复杂度的日益攀升带来了不小的效能问题。在云原生大有爆发之势的 2018 年，阿里云容器服务先是和 IoT 业务团队联合推出 Kubernetes Edge 定制版本，作为云上 IoT 边缘托管服务底座，支持海量边缘网关节点接入，深度融合 IoT 云端市场、云端 FaaS、消息、运维等服务，云边一体概念萌生。
在这个过程中，云原生让 IoT 托管如虎添翼，持续落地智慧楼宇、智慧工厂、智慧仓储项目，云边端分层结构也日益显现，这里和大家分享两个案例：亲橙里和 XX 仓储。
智慧楼宇-亲橙里
智慧仓储-XX 仓储
第二阶段：云边一体威力初现
随着 IoT 业务规模增长，Kubernetes Edge 定制版作为独立底座的维护成本越来越高，产品化势在必行。在 2019 年 4 月，阿里云容器服务 ACK 推出 EdgeKubernetes 的托管服务（ACK@Edge），就是上文提到的 K8s 的托管服务，只不过兼具了满足边缘计算场景的能力补齐，云边一体威力初现。
而这一次，ACK@Edge 又在产品化之初选择和 CDN 联合。阿里云有着国内最大体量的 CDN 业务，并正在从以内容分发服务为主转变为边缘计算，以 ACK@Edge 为依托构建云原生的 EdgePaaS 服务，而 CDN 的海量节点也考验了ACK@Edge 的大规模服务能力。
第三阶段：云边一体成熟化
随着 ACK@Edge 的技术成熟，越来越多的内外部客户选择云边一体的云原生标准 K8s 托管服务。
这里有一个优酷的 case，优酷是国内最大的视频平台，随着业务的快速发展，需要将原来部署在若干 IDC 内的集中式架构，演进到云+ 边缘计算的架构。这就势必需要业务方能够有一种方式来统一管理阿里云十几个 region 和众多的边缘节点。
通过边缘 K8s 架构，统一管理云与边缘的节点，实现了应用发布和弹性扩缩容的统一。通过弹性能力，节省了 50% 以上的机器成本；用户终端就近访问边缘节点，让端到端网络延迟降低了 75%。
边缘云原生未来
云原生未来的技术演进是我们共同的期待，在消除边缘和云的差异之后，云边一体的架构体系会在未来将边缘计算牢牢坚定在“云计算新边界”的理念之上。新业务的开展将和云上保持高度一致：Serverless、安全沙箱技术、函数计算等新的业务形态都会在不远的将来落地，ACK@Edge 将和大家一起见证。
欢迎有兴趣的同学加入钉钉讨论群！
Q & A
Q1：如何适配不同的平台？OS 不同（linux 及各种发行版、非 linux）、硬件架构不同（x86、ARM 等等）。不同平台的节点能在同一个集群内管理吗？
A1：可以的，当前 ack@edge 支持 OS 类型：linux (centos、ubuntu)，windows server；CPU 架构：X86，arm 边缘节点接入；支持异构节点在同一个集群管理；K8s管控托管在云上，异构节点的支持主要在边缘端实施。
Q2：如何应对 worker 节点网络不一定通的问题，通过 servicename 或者 clusterIP 是否还能访问？
A2：分两个角度：ACK@Edge 提供了完整的标准的 K8s 能力，所以 servicename 和 clusterIP 默认是可以 work 的；如果 worker 节点间网络不通，那么 Pod 间东西向流量是不可达的。所以我们扩展了 service 的 scope 能力，service 的流量只会被限制在一组网络可达的节点之间转发（就是上文中提到的 edgeunit）。
Q3：边缘能自治到什么程度，还能正常做增删改查吗？apiserver 资源发生变化时节点还能感知和同步吗？目前如果触发了边缘自治，对我的应用程序会有哪些影响？
A3：首先，明确边缘自治工作的时机是在边缘节点和云端管控失联后，此时为了防止脑裂云端会限制相关应用和节点资源的操作。apiserver 资源的变化只能够在网络恢复后同步到 worker 节点，并且网络恢复后，woker 节点相关的资源状态仍然以 apiserver 数据为准；进入自治状态后，节点上 agent 和应用都只能够消费断网前一刻的资源状态，自治组件 edgehub 替代 apiserver 接管了所有发往 apiserver 的请求。
Q4：K8s 具备很好的应用容灾能力，ack@edge 在应用容灾方面具备哪些能力？
A4：ack@edge 就是标准的 K8s；除了具备 K8s 原生的应用、资源管理能力之外，在边缘场景还提供了断网自治，元信息保持等等能力，这些也都是为应用容灾考虑。除此之外，因为提供的标准 K8s 完整能力，K8s 周边生态 servicemesh、Knative 等都能很好支持。
Q5：项目是否有开源的计划？
A5：edgehub、edgetunnel、edgeunit、knative-edge 等相关边缘能力都在开源流程中，敬请期待。
Q6：可否直接打通云-边-端的网络，比如我边上的 pod 访问云上的服务，直接通过servicename.namespace.cluster.svc.local，而不是用 ingress 暴露云上服务，目前 kubeedge 经过定制是具备这个能力的，还未做生产验证。阿里的和 kubeedge 及 k3s 有什么区别？A6：这个问题的本质是容器网络能否跨云，边，端；在 ack@edge 中我们也支持 overlay 跨公网的安全方案，支持反向网络穿透打通云、边，支持 VPN 网络等。
Q7：ack@edge 是否有提供原生 K8s API？还是经过封装后的 API？云边直连的安全问题，要把 apiserver 直接暴露到外网是不是不太安全？
A7：ack@edge 的设计理念是将原生的 K8s 托管在云上，支持接入边缘算力；用户可以很便捷的通过产品界面配置并生产出一个原生的高可用的 K8s 集群，并默认安装上支持边缘能力的 addons 和 operator，因此边缘 K8s 提供了原生的 API。云上 apiserver 通过阿里云 slb 暴露，对外提供服务，通过云上 slb 服务的安全能力结合 K8s 的认证、鉴权能力保证了云上 apiserver 的安全。
Q8：ack@edge 容器化后的程序与激光雷达、深度相机、imu、com 通信协议的底层控制板等传感器的通信和数据交互是如何进行的？是否能够提供稳定的数据交互通道？点云及图像数据的传输与直接运行在操作系统上的程序是否会有差别 ？
A8：应用容器化与否和对物联网协议的支持不冲突，传统的裸进程部署和容器化部署对应用而言是不感知的，数据通道需要依赖其他的物联网协议支持。
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”