1、卷首语伴随着 Kubernetes 生态逐步完善，越来越多的大型互联网终端企业开始加入到云原生梯队中，云原生生态也在向一系列标准化趋势演进。面对当下开发者普遍关注的云原生应用交付与管理、边缘计算融合、多云混合云等难题，KubeMeet 系列线下开发者沙龙通过优秀经验的总结和实践案例的沉淀，让我们感受到了云原生技术和开源社区的魅力。KubeMeet 是由云原生基金会 CNCF 与阿里巴巴联合主办的、面向一线开发者的技术交流活动，内容聚焦云原生&Kubernetes 方向，旨在通过热门的开源技术、云原生在企业的应用实践案例、架构设计思维等，帮助开发者学习云原生技术、交流实践中的问题和痛点，推进云原

2、生和 Kubernetes 在国内的规模化应用落地。过去一年，KubeMeet 系列线下沙龙走过了上海、成都、深圳、杭州等城市，累计线下参与观众千余人，将 KubeVela、OpenYurt、OpenKruise、OCM、Sealer、Nacos 等从阿里巴巴走出来的热门开源技术深入到了各地开发者群体当中。2021 KubeMeet 开发者沙龙线下演讲实录合辑是 2021 年度 KubeMeet 线下开发者沙龙中的演讲内容沉淀，不仅包含云原生标准应用模型技术上的落地与思考、热门开源项目的技术架构解读、云原生应用部署开源实践等话题，更有第四范式、携程、极狐、Vmware、电信天翼云、深信服、招商

3、局、政采云等知名企业的一线云原生落地实践。对于希望了解云原生应用交付与管理难题、边缘计算融合难题的开发者，都可以在本书中找到答案和启发。未来，也期待 KubeMeet 有机会走到你的城市，来到你的身边。KubeMeet 杭州站活动现场合影KubeMeet 上海站参会者与嘉宾互动问答环节KubeMeet 深圳站演讲嘉宾议题分享环节KubeMeet 杭州站参会现场活动气氛高涨KubeMeet 成都站参会者针对演讲内容进行记录KubeMeet 成都站活动现场合影目录阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践5AIOS 应用管理和交付实践29OpenKruise：实现 Kuberne

4、tes 中容器粒度的不可变基础设施41OpenKruise 在携程的应用实践56基于 KubeVela 面向混合环境的应用交付64Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践79基于 GitLab+KubeVela 的 GitOps 实践86OpenKruise 带给云原生应用管理的新变化100开启边缘设备的云原生管理能力115深入理解 OpenYurt125深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践144从中心走向边缘深度解析云原生边缘计算落地痛点152OpenKruise 提升云原生应用自动化新高度174混合云环境云原生应用交

5、付和管理平台190集群镜像重塑分布式应用交付203政采云私有化业务交付实践213开放模块化多集群管理平台 OCM218Nacos2.0 的 K8s 服务发现生态应用及规划2285阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践作者：王仁达(封崇)，阿里云高级技术专家。主要负责云原生应用管理和云资源管理相关工作，致力于提升客户上云效率，推动云原生应用管理实现自研、开源、商用三位一体技术统一。议题简介：随着“云原生”的普及，越来越多的应用开发者开始追求快速构建交付应用，然而使用场景的不同往往意味着应用交付环境会有巨大的差异。如

6、何将应用管理和交付变得标准化，使应用研发不再需要花大量精力对接不同的交付平台，逐渐成为云原生应用管理的一大痛点。本次分享将针对这些问题介绍如何基于 KubeVela 构建标准化的应用交付管理平台，及阿里巴巴在此基础上的实践经验。一、云原生应用交付面临的问题与挑战1、多样化的交付环境是云原生应用交付面临的挑战：a、Workload 多样：对接不用集群环境、灰度发布、流量管理方案；b、部署环境多样：公共云、专有云、私有化部署，对接不同 APM 方案；c、云资源使用多样：对接不同 Provider、云资源管理方案，对接云产品差异化配置。多样化的交付环境，对于应用开发者来说门槛较高，需要了解 K8s

7、复杂的参数、配置等；而对于平台开发者来说，开发成本较高，需要写各种 controller 来完成比如像封装等能力。2、基于 K8s 资源组合也存在同样问题：a、复杂、难懂、门槛高；b、能力局限、不同场景各不相同；c、不统一，每个模式需要重新编写发布对接。阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践kubernetes-sigs/application4、Helm Chart：a、黑盒，不明确内部有哪些资源；b、缺失发布能力，helm upgrade 没有灰度能力；c、无法使用/对接云资源；阿里巴巴基于 KubeVela

8、 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践a、基于 Kubernetes 和 OAM 模型构建；b、纯 Golang 编写；c、社区发起，社区构建；d、2021.03 KubeVela 1.0 发布；e、1.7k star，60+contributors；2、KubeVela 1.0 的主要能力a、丰富的抽象模板能力（组合、转换、拆分、状态回流、数据传递等）；b、渐进式发布能力；c、应用云资源创建和绑定；d、多集群、多环境的应用部署；e、使用 Helm chart 对接 KubeVela Traits 生态；3、KubeVela 的 Applic

9、ation 对象Application 对象包括组件类型、镜像与启动参数，多组件、弹性扩容和可灵活扩展的其它能力等，它具有以下优势特点：a、完整的应用描述文件（以应用为中心）；b、灵活的“Schema”（能力模板自由组合）；阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践b、运维能力KubeVela的运维能力写作方式和component 的主要区别是要声明Trait 应用的 workload是什么，以及 CRD 对象（某些情况下 CRD 也可以不指定），其它能力基本和 component 一样。c、示例：上线新功能 met

10、rics平台研发团队：开发了一个新 Operator 叫做 metrics（监控），编写一个 K8s 能力描述文件metrics.yaml；阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践d、查看“能力模板”的用法$vela show webservice能力模板注册时，KubeVela 控制器会自动生成 OpenAPI v3 的 json schema 文件和文档；通过 vela 的命令行工具可以查看；用户也可以自己基于 json schema 去渲染集成进自己的前端。5、KubeVela 为什么能对不同 Workloa

11、d 做统一发布？a、工作负载类型：统一类型注册和识别；b、健康检查：统一状态检查和回流；c、发布模式：统一发布方式；d、资源模板：统一抽象方式。阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践模板参数，组装成一个应用，在发布的时候由 KubeVela 把资源创建出来。所以 KubeVela 团队协作的边界相对比较清晰。2、KubeVela 应用管理依赖的能力a、抽象能力各种资源组合、拆分无需写各种 Controller 对接安全的 patch 方案b、应对交付场景支持 helm 用于交付场景c、企业级应用发布能力版本化分批

12、发布滚动发布/原地发布发布暂停发布回滚日志监控健康检查多版本部署多版本流量灰度多集群/多环境灰度d、云资源管理能力多种资源编排方案(Terraform、Crossplane)标准化应用绑定阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践VolumeConfigMap阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践5、渐进式发布a、面向终态模式现在社区基本上是基于流量管理的发布，最常见的像 rolling，比如说按副本数的调整。但有些模型其实不太适合用

13、rolling 的方式，而且也很难维护。KubeVela 补足了这方面的能力，支持按流量发布。下图是按照副本数支持 rolling 的一个方案。面向终态模式是指在 application 里指定 rollout策略，它的工作机理是每次更新 application 的时候，KubeVela1.0 就新增一个 AppReversio-n 的操作对象，这个对象就等于是一个应用的完整的 snapshot，它包含了 definition 里面抽象的信息，也包含了转化到 K8s 里面 APP 终态的信息，是个非常完整的一个镜像。阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 Ku

14、beVela 的新一代应用交付管理系统实践b、发布单模式任何 PaaS 发布的时候都有一个发布单，K8s 是面向终态的，发布就是从一个版本到另一个版本的过程。发布单模式的工作原理是在更新 application 的时候，每次都会创建一个 AppRevision，但此时只会创建一个镜像，不会真正把资源下发下去，通过 AppRollout 的时候，它先接管应用的生命周期，把整个资源渲染出来下发到集群里。当发布完成之后，再把控制权交回给 applicati-on。阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践发布单模式下 Ap

15、plication 的更新不再实际操作资源，只生成版本快照；扩缩跟发布使用相同模型。d、面向终态的多版本共存KubeVela 提供多版本，有多个 Revision，按照流量逻辑去发布，通过 TrafficRules 指定不同版本的流量配比，每个 Revision 部署在不同的集群上，指定多集群的 clusterSelector 参数。它的工作原理和 Rollout 类似，亦即 application 的变化只生成 Revision，然后由 deployme-nt 去创建 K8s 资源。阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管

16、理系统实践e、多环境/多集群/多版本现在规划要做一个多环境/多集群/多版本的渐进式发布。首先定义环境，环境包括所依赖的集群和包，同时还要做一个基于环境的 patch，类似于kustomize-style 风格模板，指定相应的参数，patch 到不同的环境上。在真正集群里，比如说一个 application，对每一个 environment，patch 生成相应的 App Revision，然后复用这个application 的 deployment 多版本发布。6、云资源管理云资源管理有两种方式，一个是单应用，一个是多应用。a、云资源管理的单应用完成供给和消费单应用是在一个应用里声明云资源的供

17、给，比如说把 RDS 创建出来，同时做资源消费，把应用绑定。假如 application 有两个 component，一个 component 是云资源的配置，创建 RDS，同时指定要绑定的 secret。这个背后有两个能力模板，一个是做资源供给的，对接社区的方案，因为它本身 API 设计很好，扩展性很强，尤其是 secret 回血的能力，可以做成一个非常标准的东西。阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践在使用不同资源的时候（比如 AWS，或者是阿里云），所产生的资源 output 是不一样的，同样的数据库账号比

18、如 db-name 的名字可能是不一样的，有的可能是大写，有的可能是小写，那我们可以通过 insert 做一个转换的逻辑，上面所说的 patch 过程是稳定不动的，我们可以用中间态去做 patch，对接不同的输出资源。c、云资源管理集成 TerraformTerraform 已成为云资源管理事实上的一个标准，KubeVela 也正在集成 Terraform，做成一个正式化的 controller。其示意图如下：阿里巴巴基于 KubeVela 的新一代应用交付管理系统实践AIOS 应用管理和交付实践AIOS 应用管理和交付实践作者：马浩，第四范式-机器学习平台资深工程师，专注机器学习平台应用，模

19、型，workflow，metadata 等组件和模块的构建和优化。议题简介：为了更好解决 AI 落地难题，更好地利用云原生技术红利，为企业、生态伙伴、开发者提供更好的应用管理和交付平台，第四范式基于 OAM kubernetes runtime+扩展的Workload 和 Trait 打造统一的 AIOS，使多个生态伙伴以较低的改造成本完成 AIOS 接入，同时为内部建模中 DAG 计算提供更灵活的计算服务。本次分享将基于上述经验，介绍如何基于OAM 在 Kubernetes 之上开发聚焦应用、具备可靠性、可扩展性、可维护性的 PaaS。一、背景AIOS 是第四范式的一个机器学习的平台，在 A

20、IOS 之前，第四范式会把所有的产品 All-In-One 的打成一个包，通过 DevOps 开发的脚本给客户部署。但是随着产品的不断丰富完善和客户场景的日渐复杂化，这种 All-In-One 的模式带来了一些问题：迭代慢、灵活性差、不够开放。在这种情况下第四范式提出了 AIOS 的概念：1、所有的东西都是 App；2、Internal App,Eco Partner App,Developer App，所有的能力围绕 App 来打造；3、插件化；4、底层有 Kernel 来支撑 App，App 和 Kernel 可以独立发布；AIOS 应用管理和交付实践AIOS 应用管理和交付实践Open

21、Application Model Specification第四范式采用了将核心的业务逻辑做成 component 的镜像，其它四个方面围绕 OAM 的trait 加上 workload 去做 App 的封装的思想，设计了如下架构：该设计方案将上层 App 的静态文件通过集群的 Nexus 去展示，动态文件通过 AppConfig 去拉取，一个 App 可以拉取多个 Instance，每一个 Instance 可以拉取多个 AppConfig。这个方案不仅可以满足 App 的需求，算子平台、Model-Serving、Hypercycle ML 也都可以通过这个架构来满足。二、实践和场景落地

22、1、实践AIOS 应用管理和交付实践AIOS 应用管理和交付实践下图是 component 和 service 的模板示例：基于上面的模板，可以设计 AppFormat，主要包括 app 和 component 两个文件夹：app 文件夹包括：app 静态文件和 service.yaml 模板；component 文件夹包括：docker tar，component.yaml 模板，flyway 等。AIOS 应用管理和交付实践AIOS 应用管理和交付实践c、Model Serving 场景AIOS 应用管理和交付实践AIOS 应用管理和交付实践三、问题和挑战1、问题一：ManualScale

23、rTraita、副本数问题：ManualScalerTrait 负责副本数，但在上线一段时间后发现副本数自动发生了变化，原来是K8s 的 Server-Side Apply 允许多个 controller 控制一个 resource，这个过程如下：workload 创建 deploy；trait 更新副本数为 3；当更新 appconfig image 从 1.0.0 到 2.0.0；workload 把副本数改回到 0。使用过程中我们不希望 workload 修改副本数，得到社区的反馈是不建议全量更新 deployme-nt 而是去增量更新。AIOS 应用管理和交付实践AIOS 应用管理和交

24、付实践statefulSet 禁止更新 volumeClaimTemplatesb.、解决方案：目前还是采取提前渲染 volumeClaimTemplates 的方法，但我们还是希望 VolumeMouterTra-it 去完成这个事情，社区已有同事在做，目前已经完成大部分的开发工作。社区参考网址：https:/ Binding随着 component 的不断增多，可以拿到 componentHub 等能力，有中间件的，有 app 注册的，当解决了一个 AppConfig 之后，是否可以把多个 app 还有中间件的部署，通过 bindi-ng 的能力绑定起来？让业务只需要渲染 yaml 就可以

25、迅速拉起服务，同时在 bingding 增多的时候，可以在 bingding 上端集成一整套解决方案。这个探索未来面临服务调用的问题，状态管理怎么去做，是否可以参考 event driver 去做，以及如何利用 sidecar 等问题。AIOS 应用管理和交付实践OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施作者：王思宇(酒祝)，阿里云技术专家、OpenKruise 作者&负责人，Kubernetes/OAM 社区贡献者，长期从事云原生、容器、调度等领域研发；阿里巴巴百万容器调度系统核心研

26、发成员，多年支撑阿里双十一超大规模容器集群经验。议题简介：众所周知，原生 Kubernetes 限制了最小操作单元为 Pod 级别，默认情况下我们只能操作扩容、缩容 Pod，甚至发布升级都是依赖于扩缩 Pod 来完成的。而 OpenKruise 在不对原生 Kubernetes 做任何侵入的基础上，为用户提供了更多细化到容器粒度的控制能力。在本次分享中，我们将会主要介绍 OpenKruise 项目是如何在不侵入 Kubernetes 的前提下实现这些容器粒度操作能力，以及用户如何通过使用 OpenKruise 这些能力更好地部署运维和管理云原生应用。一、OpenKruise 是什么1、Open

27、Kruise 简介Kruise 是 Cruise 的谐音，K for Kubernetes，寓意是 Kubernetes 上应用的自动化巡行，它是：CNCF 托管的 Sandbox 项目；阿里云开源的基于 Kubernetes 的云原生应用自动化套件；阿里巴巴经济体上云全面使用的部署基座；2、OpenKruise 的用户国内用户：阿里巴巴、蚂蚁、携程、美团金融、网易、小米、OPPO、有赞、苏宁、比心、申通、小红书、掌门教育、杭银消费、哈啰出行等。国外用户：Lyft、Bringg、Arkane Systems、Spectro Cloud、Linkedin 等。OpenKruise：实现 Kube

28、rnetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施ImagePullJob支持用户指定在任意范围的节点上预热镜像。4、OpenKruise 即将提供的功能容器重启支持对 running Pod 中的指定容器触发重启操作；级联删除防护防护 CRD、Namespace、Workload 的删除操作，避免批量 Pod 等资源被误删除；PodUnavailableBudget应用 Pod 可用性保护，相对于只能限制驱逐的 PDB，PUB 能保护 Pod 的删除、驱逐、原地升级等所有会导致服务不可用的操作；全局 Pod 删除流控可配置集群

29、中 Pod 删除流控规则，在限定时间范围内删除 Pod 数量超过阈值后则发生熔断；通用 operator 扩展支持对 operator 做运行时管控，通过水平扩展、灰度升级能力解决 controller 单主问题，外部对 controller 的异常行为做拦截防护、控制爆炸半径，同时带来更灵活的集群内多租能力。二、什么是容器粒度的不可变基础设施1、Kubernetes：Pod 维度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施2、OpenKruise 所提供的容器粒度管控能

30、力a、应用部署层面，以 CloneSet 为例：支持修改 image 以及 labels/annotations 原地升级；Pod 原地升级b、sidecar 容器定义：支持独立定义 sidecar 容器；一次声明，应用规模化注入；c、容器管理：支持对任意 running Pod 中一个或多个容器做重启操作；d、镜像预热：指定任意范围的节点上批量拉取镜像；OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施Kubernetes+OpenKruise 形态在 Kubernetes+OpenKrui

31、se 形态中，增加了 kruise-manager 和 kruise-daemon 组件，通过这个两个组件，OpenKruise 提供了一系列的拓展能力。1、原地升级能力a、技术背景背景 1：kubelet 计算容器 hash。当 Pod 的某个容器的 image 发生了变化，hash 值就发生变化，Kubelet 就会停掉旧容器，启用新容器。背景 2：apiserver 对 Pod 更新限制。目前对于存量 Pod 只允许更新 spec 中以下字段：OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基

32、础设施结论：对于一个现有的 Pod，我们能且只能修改其中的 spec.containersx.image 字段，来触发Pod 中对应容器升级到一个新的 image。如何判断升级成功由背景 3 可知：比较 spec 和 status 中的 image 字段是不靠谱的，因为很有可能 status 中上报的是 Node 上存在的另一个镜像名（相同 imageID）；结论：判断 Pod 原地升级是否成功，相对来说比较靠谱的办法，是对比升级前后的 imageID 是否变化；隐含的问题：不能用 tag 不同、实际 imageID 相同的镜像做原地升级。如何保证流量无损由背景 4 可知：addon 组件可以

33、通过设置 readinessGates 和更新 pod.status.conditions 中的自定义状态，来控制 Pod 是否可用；结论：定义一个叫 InPlaceUpdateReady 的 readinessGate，升级前修改 condition 为 not ready，升级完成后修改 condition 为 ready。达到原地升级过程中摘流的目标。原地升级是否存在一些问题？Q：原地升级能否支持修改 env 等字段？A：由于 apiserver 的限制，目前只能支持针对 image 的原地升级，修改 env 等其他字段还是会触发重建升级。Q：通过 imageID 判断升级完成有什么隐含

34、问题？A：不能用 tag 不同、实际 imageID 相同的镜像做原地升级。Q：通过 readinessGate 切流是否有损？A：为了避免摘流延迟，Kruise 提供了优雅静默时间，可以等待摘流一段时间后再真正执行升级。OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施4、Pod 容器重启（重建）通过声明一个名为 ContainerRecreateRequest 的 CRD，指明 Pod 中要重启的容器，Kruise-manager 会向其中补充一些信息，节点上的 Kruise-daemon

35、 感知到信息后，和 kubelet 配合，Kruise-daemon 执行 preStop 和 stop，然后由 kubelet 重建，从而实现对 K8s 无损的容器重启。OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施原地升级 Pod 中某个容器时，其他容器保持正常运行，网络、存储均不受影响。3、使用 SidecarSet 管理 sidecar 容器a、原生 K8s 用法存在的问题：业务 Pod 里面包含了运维、安全、代理等多个 sidecar 容器，业务不仅要完成自身主容器的配置，而且还

36、需要熟悉这些 sidecar 容器的配置（增加了业务方的工作量和风险）；Sidecar 容器的升级需要连同业务主容器一起重建（原生 Deployment 等 workload 基于Pod 重建来实现 Pod 的滚动升级），推动和升级支撑着线上数百款业务的 sidecar 容器（极大的业务阻力）；作为 sidecar 容器的提供者对线上诸多各种配置以及版本的 sidecar 容器没有直接有效的升级手段（潜在的管理风险）。b、SidecarSet 特性：配置单独管理：为每一个 sidecar 容器配置单独的 SidecarSet 配置，方便管理；自动注入：在新建、扩容、重建 pod 的场景中，实现

37、 sidecar 容器的自动注入；原地升级：支持不重建 pod 的方式完成 sidecar 容器的原地升级，不影响业务主容器，并包含丰富的灰度发布策略；热升级（v0.9.0）：对于 envoy/nginx 这类接入流量的 sidecar 容器，默认原地升级过程中会导致流量中断。V0.9.0 版本的 SidecarSet 提供 sidecar 热升级能力（同时也需要 sidec-ar 中的进程支持热切换）。3、组合拳：镜像预热+扩容a、原始 Pod 扩容的流程/耗时，可以看到最长的是 app 容器和 sidecar 容器拉镜像的耗时：OpenKruise：实现 Kubernetes 中容器粒度的

38、不可变基础设施OpenKruise：实现 Kubernetes 中容器粒度的不可变基础设施在使用 OpenKruise 的原地升级之后，没有优化的部分还有拉取少量 image layer 的耗时，如何继续优化呢？c、原地升级+镜像预热：在灰度第一批 Pod 的时候，提前在后续批次 Pod 的节点上预热即将发布的新版镜像，当后续的这些 Pod 真正做原地升级的时候，就不需要拉取镜像；d、终态原地升级：所以，最终的原地升级耗时就是启动应用的耗时，中间过程的时间都被优化了。OpenKruise 在携程的应用实践OpenKruise 在携程的应用实践应用发布：FAT GroupUAT Group（接近

39、生产环境的测试环境）PRO Group（生产环境）Group 发布：堡垒金丝雀第一批次最后批次实例发布：拉出实例部署实例点火拉入实例4、PaaS 1.0 经典部署模式如上图，PaaS 1.0 部署模式存在以下不足：虚拟机思维：先分资源再发布，限制扩容能力；CMS 为中心化存储，多云场景实时性不足，无法满足快速变化场景；K8s 只用来做资源调度，限制了发挥；PaaS 需要负责实例的拉入拉出，比较繁重；二、携程如何实现 K8s 云原生发布1、部署模式PaaS2.0 云原生部署模式的核心是以 K8s 做为 PaaS 引擎，做了以下改进：OpenKruise 在携程的应用实践OpenKruise 在携

40、程的应用实践抽象出具有可扩展性的工作流引擎；操作皆可作为变更，细粒度拆分为 Step；过程用户透明，易于排障；变更支持在任意节点重试与回滚，降低用户试错成本。3、基于 Kruise 的 Rollout 云原生发布方案发布流程 Operator 化，下沉至 K8s；中间件 Operator 化，下沉至 K8s，简化发布流程；精确控制发布流程（堡垒，金丝雀，滚动）；落地 Kruise 原地升级能力；同时支持无状态有状态发布；无状态：28000+CloneSet有状态：200+StatefulSet然后看下中间件，这里中间件主要是流量的入口，定义了一些 lable 的规范，用于控制流量的拉入拉出。O

41、penKruise 在携程的应用实践OpenKruise 在携程的应用实践e、对 inplace update 的修复和改进，当有多个 hook 的时候，在 update 完成后，未等到所有的 hook 移除就变成 normal 状态，携程内部有些有状态应用，希望将 lifecycle hook和 inplace update 结合，于是增加了 lifecycle hook 对 AdvancedStatefulSet 的支持。三、携程 PaaS 平台后续规划1、目标和挑战目标：控制面高可用的集群联邦，跨集群、跨 AZ 高可用，实现自动化容量管理。挑战：发布涉及所有资源集群联邦改造；发布状态难以

42、判断（zone、cluster）；存量 Group 如何无损迁移到集群联邦；对于 HPA 的高可用，是类似 Fed 的设计，如下图：OpenKruise 在携程的应用实践OpenKruise 在携程的应用实践3、Kruise 新特性落地a、Pod 生命周期 hook:原地升级前执行拉出，原地升级后做流量拉入；b、安全防护：删除、更新、驱逐保护；c.、原地升级与镜像预热结合。基于 KubeVela 面向混合环境的应用交付基于 KubeVela 面向混合环境的应用交付力推动了 OAM 模型的落地和发展。2021 年 6 月 OAM/KubeVela 正式成为 CNCF 项目（https:/ 月，K

43、ubeVela 发布 v1.1 版本，其核心能力是多集群混合云的管理能力。2、面向多云多环境的易用可扩展的部署引擎OAM/KubeVela 流程图OAM/KubeVela 流程图展示了基于 OAM 模型设计部署的拓扑结构、策略以及工作流。最上面End User 代表 KubeVela 面向的最终开发者；Workflow 工作流引擎用来解决 OAM 应用的完整交付链路和交付反馈问题，它是 KubeVela 的核心实现；KubeVela 下面是根据策略和工作流将应用的组件分发到目标云、IoT/边缘设备，或者任意 Kubernetes 集群。基于 KubeVela 面向混合环境的应用交付基于 Kub

44、eVela 面向混合环境的应用交付运维能力 traits应用部署后的持续运维，比如路由规则、自动扩缩容规则等 像乐高一样可以附着作用于组件上；应用的全局策略 policies比如多集群分发策略、安全策略、健康检查策略、防火墙规则等，任何一个部署前需要遵守的规则都可以在这个阶段声明和执行；交付工作流 workflow比如蓝绿部署、带流量的渐进式部署、手动审批等任意的管道式持续交付策略。基于 KubeVela 面向混合环境的应用交付基于 KubeVela 面向混合环境的应用交付示例 1：组件定义示例 2 是 sidecar 容器注入的运维特征，通过 patch 的方式注入到组件中使 Deploym

45、ent 的配置更加丰富。示例 2：运维特征定义基于 KubeVela 面向混合环境的应用交付基于 KubeVela 面向混合环境的应用交付关于 IaC 存在缺陷的相关讨论State of infrastructure drift 2021下载地址： IaC 的缺陷，在 IaC 模式（CUE）的基础上增加一个统一控制平面，管理应用工作流和生态对接。如下图所示，开发者（Application）编写一个 yaml 文件放入集群中形成从希望状态到现实状态的循环控制，然后结合上层 API 及对象 UI 体验回流到用户端以实现品牌化体验。基于 KubeVela 面向混合环境的应用交付基于 KubeVela

46、 面向混合环境的应用交付模式二：下发 Pull 模式，使用 Cluster Gateway 对接 OCM 获取状态当遇到边缘集群或网络受限集群无法直接通讯时，就需要 Pull 模式来解决。如下图所示，底层Runtime Cluster 通过 OCM 管理证书注册到 Cluster gateway，Cluster gateway 借助代理的Tunnel 反向获取资源。这种模式的下发使用 Pull 模式，而回流则仍然需要主动查询。四、KubeVela 多集群（混合云）方面的用户场景综合上面对 KubeVela 的介绍，总结以下几个主要的用户场景：基于 KubeVela 面向混合环境的应用交付基于

47、KubeVela 面向混合环境的应用交付3、场景三：混合环境（多集群、混合云）应用交付控制平面特点：围绕应用的多集群资源编排和部署；混合环境差异化部署；围绕应用的多集群状态查询；跨环境部署工作流；开发者经常遇到的场景是从开发环境、测试环境到生产环境的多环境或混合环境的实践，或面对不同客户的集群，都会需要使用多集群、混合云的部署模式，即运用控制面进行应用集群编排，再分发至多个集群的分发流程。基于 KubeVela 面向混合环境的应用交付基于 KubeVela 面向混合环境的应用交付5、场景五：GitOps 多集群/多环境应用交付特点：无缝对接各类传统 CI；完全基于 Pull 模式的 GitOp

48、s 支持；基于集群环境的自治；发布维度的场景，是基于 Pull 模式的 GitOps 体验。当上层 CI 完成后生成 image 并推送到应用配置仓库进行变更，之后被 KubeVela 获取后进行 CD 流程。Pull 模式下，控制面数据下发以后，runtime 集群会自动订阅数据 repo 的变化，形成集群自治。基于 KubeVela 面向混合环境的应用交付Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践作者：金敏(左修)，阿里云开发工程师，Kubernetes 维

49、护者一、OCM 概述1、OCM 定义OCM 是企业级多集群管理平台开源社区项目，也会是未来开源社区多集群工作小组 SIG Multi-Cluster 主推的多集群管理平台。目前主要的生态合作维护伙伴主要有支付宝、阿里云、RedHat，Microsoft Azure。同时，OCM 项目也正在积极和生态中相关的优秀开源社区项目比如 KubeVela，ArgoCD，腾讯云 Clusternet、OpenKruise、Submariner 等等研发集成，通过登陆 OCM 多集群管理平台，可以平滑引入更多优秀云原生开源项目到实际生产中。2021 年底，OCM 进入 CNCF 沙箱项目。网站链接：http

50、s:/open-cluster-management.io/2、OCM 的核心优势OCM 作为多集群容器资源管理平台的核心优势在于：高度模块化，功能可以根据场景自由裁剪；可纳管集群数量规模多；分布式自治架构，更强容灾能力；自定义拓展性强；厂商中立；Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践c、站点级别弹性问题站点级别弹性问题包括：机房级别离线：支付宝 527 事故；机房级别伸缩：双十一大促扩容建站；三、OCM 架构1、OCM 整体架构对标 KubeFed 架构，

51、KubeFed 架构是在多机房/站点之上由一个中枢大脑做决策和部署，属于Push 架构；OCM 架构是将中枢大脑分割开沉到各个机房/站点中，每个机房自治管理，属于Pull 架构。OCM 架构的优势体现在以下几个方面：a、机房集群高度自治：当遇到网络分区或机房灾害的情况时，机房内部可以实现自治，根据自身情况判断，而不是通过大脑自动化下达操作指令；b、开放式插件化：OCM 是模块化，模块支持热插拔，即可以在模块运行时进行安装或卸载；“轻”管控面；c、“零信任”握手控制权限：不同于之前的中枢集群和子集群的控制管理关系，OCM 的子集群和中枢集群是从“零信任”开始握手慢慢放开权限，在注册管理方面有效避

52、免了异构环境中可能产生的子集群对中枢集群的侵害。Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践4、OCM 特性双向互信的集群注册及注销管理；多集群路由/匹配规则编写；多集群资源/配置下发能力；插件框架允许开发者自由集成；5、阿里云开源家族关系OCM 在阿里内部定位是多集群基础功能/资源管理的界面。下图展示了 OCM 与阿里云开源家族的关系。Open-Cluster-Management(OCM)多云混合云容器编排引擎及阿里实践Open-Cluster-Managem

53、ent(OCM)多云混合云容器编排引擎及阿里实践3、阿里云 CNStack AECP 迁移到 OCM 作为底层引擎AECP 是一个基于 Kubernetes 的私有化容器管理平台。在 CNStack 内作为容器管理产品与其他的产品（EDAS、MQ 等）一起在小天基平台上部署和运维。小天基也是一套包含 Kubernetes的管理平台，以及一系列基础服务，其中一些基础服务以虚拟机为运行环境。目前正在紧锣密鼓构建基于 OCM 的高级多集群产品能力。4、蚂蚁集团 PaaS 多集群建站及演练在阿里/蚂蚁的 LDC 应用架构下，一个应用根据自己的业务属性可以被划分到不同 Cell 里进行部署，可能是 G-

54、Zone，C-Zone 或者 R-Zone。而 Cell 和物理集群之间事实上是多对多的关系：一个集群可能被规划切割为多个 Cell：这也是最常见的默认的场景，一个集群从被创建出来再到可以进行 LDC 架构的应用的部署之间就需要管理员提前将其切割为多个 Cell；一个 Cell 可能横跨多个集群：在实际的场景中，因为某些历史原因，单个数据中心里会同时部署多个 Sigma/Kubernetes 集群；除此之外，在新春红包的场景中，还出现了在单个 IDC中扩建 ASI 集群的需求，出现这些 ASI 集群的 Cell 也可能是同时横跨 Sigma 集群的。基于 GitLab+KubeVela 的 G

55、itOps 实践基于 GitLab+KubeVela 的 GitOps 实践3、GitLab 十年演进发展之路GitLab 从 2017 年开始持续保持每个月一个小版本发布，每年一个大版本更新。4、一体化 DevOps 平台将 DevOps 平台一体化可以提高系统维护能力，降低维护时间和成本。比如针对安全方面的管理，在平台没有一体化之前，平台中任何功能的升级都不能错过，一旦错过就会造成安全隐患，现在只需要升级 GitLab 就可以将平台上所有功能同步升级。基于 GitLab+KubeVela 的 GitOps 实践基于 GitLab+KubeVela 的 GitOps 实践CI/CD Work

56、flow push 模型2、GitOps 特性GitOps 的特性主要包含以下几个方面：以声明式系统(包括基础设施和应用程序)为基座(典型如 Kubernetes)；如下图所示，在 GitOps 的这种模式中有一个保存配置文件的仓库与配置文件保持实时同步，以实现简化流程以及提高可观测性；以 Git(典型如极狐 GitLab)为单一可信源；一切皆代码(应用程序&基础设施)。GitOps pull 模型基于 GitLab+KubeVela 的 GitOps 实践基于 GitLab+KubeVela 的 GitOps 实践三、KubeVela+GitLab1、GitOps+KubeVelaKubeV

57、ela 作为一个声明式的应用交付控制平面，就是为 GitOps 而生。从下图的针对 KubeVela 和 Kustomize、Helm 的对比可以看出，Kustomize 和 Helm 都包含了多层的字段，而其中一些基础设施相关字段对于业务开发者来说并不需要关注，如果强制他们参与则会产生更多的问题。反观 KubeVela 是将平台和业务的功能分开，平台提供模板和架构，业务只需要根据具体需求填写相关参数即可。2、Push 模型Push 模型是 CI/CD 模式，如下图。基于 GitLab+KubeVela 的 GitOps 实践基于 GitLab+KubeVela 的 GitOps 实践4、灵活

58、编排-有向无循环水线 DAG Pipeline有向无环流水线(DAG Pipeline)能够突破普通流水线中前序步骤所有任务执行完后，才能执行后续步骤中任务的限制。支持按照任务为粒度进行跨步骤的关联建立，降低任务等待时间的浪费。并提供可视化能力快速识别任务的运行情况。适用场景操作系统类软件；多平台支持类软件；单仓库多模块微服务应用；价值体现减少任务等待时间；提升流水线执行效率；加快交付结果反馈；直观呈现任务关系；基于 GitLab+KubeVela 的 GitOps 实践基于 GitLab+KubeVela 的 GitOps 实践7、app.yaml 配置相比 kustomize 和 Helm

59、，以应用为中心的 KubeVela 对于开发更加友好，无需操心各种无关字段，专注业务相关配置即可。Demo 地址：https:/ GitLab+KubeVela 的 GitOps 实践基于 GitLab+KubeVela 的 GitOps 实践2）基础设施Kubernetes与 GitLab Agent 集成安装新代理；系统自动生成一个唯一的 token（下图红框中），打开 CLI 并连接到需要安装代理的集群使用给出的命令进行安装即可。基于 GitLab+KubeVela 的 GitOps 实践基于 GitLab+KubeVela 的 GitOps 实践为积极响应国家“十四五规划和 2035

60、年远景目标纲要”指导精神，进一步推动中国开源、开放GitOps 技术在各“产学研”领域的规范化实施和落地，极狐信息技术(湖北)有限公司联合云原生计算基金会（CNCF）共同发起“开源 GitOps 产业联盟”（Open GitOps Industry Alliance，英文简称：OGA），致力于支撑国家相关技术标准的研究制定和规范实践，构建国内外领先开源技术提供商与行业用户之间的研究、交流平台，推动开源、开放 GitOps 技术在中国的自主创新发展与落地实践，帮助企业在满足数据安全和信息安全的同时加速软件开发创新与价值实现。OpenKruise 带给云原生应用管理的新变化OpenKruise 带

61、给云原生应用管理的新变化PaaS 可以通过使用 OpenKruise 提供的扩展功能使应用部署、管理流程更加强大与高效。2、功能视图如下图所示，OpenKruise 的能力主要专注于五个领域：应用工作负载（部署、发布）；Sidecar 容器管理；应用分区管理；包括多中心部署、不同资源池、不同机型差异化部署；增强运维能力；应用安全性防护；OpenKruise 绝大部分能力都是基于 CRD 扩展来定义的，可以运行在任意纯净的 Kubernetes集群中。官方文档：https:/openkruise.io/zh/docs/OpenKruise 带给云原生应用管理的新变化OpenKruise 带给云原

62、生应用管理的新变化2、如何看待原生 Workload 的局限性下图是 OpenKruise 进入 CNCF 时针对 K8s 原生 Workload 的讨论。大意是 K8s 官方认为上游原生 Kubernetes 已经不倾向于接受新的工作负载 controller，他们欢迎第三方项目如 OpenKr-uise 加入以拓展 K8s 工作负载能力。3、原地升级（In-Place Update）原地升级是 OpenKruise 扩展应用工作负载所带来的一大特性。首先看一下镜像重建升级，以下图为例，重建升级后旧的 pod-a 被删除，重建了新的 pod-b，变化包括：name、uid、image、nod

63、eName、podIP。反观原地升级如下图所示，改变的只有镜像，从 v1 升级至 v2。镜像（重建）升级OpenKruise 带给云原生应用管理的新变化OpenKruise 带给云原生应用管理的新变化示例：原地升级自动镜像预热Advanced StatefulSet vs.StatefulSet：支持 maxUnavailable 控制并发窗口，提高发布效率;流式窗口扩容;可配置 Ordinal 序号保留（跳过）;原地升级自动镜像预热;Advanced DaemonSet vs.DaemonSet：按 node label selector 标签选择灰度升级;通过 partition 控制灰度

64、分批;支持 Pod 热升级，保证升级过程 Daemon 服务不中断。5、Sidecar 容器独立定义与管理在很多场景下都会有针对 Sidecar 容器独立定义和管理的需求，比如在业务中需要 Sidecar 容器采集日志，因此要在工作负载中定义 Sidecar 容器，如果升级 Sidecar 容器则需要升级整个Deployment，就导致在良好运行的业务 pod 需要重建的问题。OpenKruise 提供的 Sidecar 容器独立管理方案是新定义一个 SidecarSet，如下图所示，用户定义一个 logtail SidecarSet，业务部署 Deployment 或 CloneSet 工作

65、负载而无需定义 Sidecar容器，这个 pod 在创建时会被 OpenKruise Webhook 拦截，并将定义好的 logtail 注入到业务pod 中。这样对于业务人员无需关注 Sidecar 容器，对于维护 logtail 容器的人员也只需要关注SidecarSet CR，而业务 pod 中的 Sidecar 容器则无需费心。如果业务将 SidecarSet 中镜像版本从 1.0.0 改成 1.1.0，SidecarSet 会将已有 pod 中的 logtail容器从 1.0 原地升级。OpenKruise 带给云原生应用管理的新变化OpenKruise 带给云原生应用管理的新变化如

66、下图所示，workloadspread 通过 targetRef 关联到原生 Deployment 或者 CloneSet，可以定义多个 subset，这里的 subset 等同于 pod 分组的概念。特性：无需修改 Workload 或 Pod，可直接配合原有 Deployment/CloneSet 使用；多个拓扑或区域维度，按比例打散，或按固定数量分配；支持多区域调度顺序选择，在前一个 subset 数量满足或资源不足时选择下一个 subset；通过 deletion-cost 自动设置 Workload 缩容优先级。3、应用场景场景一：两个资源池，Normal 是固定资源池，Elasti

67、c 是弹性资源池，即其中的业务是具有周期性的，比如白天将 node 开机，晚上停机以节省成本。通过定义 workloadspread 将固定量的 pod 部署到基础资源池，将弹性 node 部署到弹性资源池。OpenKruise 带给云原生应用管理的新变化OpenKruise 带给云原生应用管理的新变化场景四：集群中有不同机型，如下图示例中的 x86 和 arm，不同机型的算力不同导致 pod 在不同机型中部署的 request limit 就可能不同。四、增强机型运维能力1、容器原地重启OpenKruise 带给云原生应用管理的新变化OpenKruise 带给云原生应用管理的新变化定义好之后

68、，OpenKruise 会将符合条件的节点上的镜像预拉到本地。镜像预拉取运用的场景，比如刚部署的节点中的镜像是空的，之后部署业务都需要一个拉取基础镜像的过程，如果先在集群中部署 ImagePullJob 并保持持续预热，基础镜像预热，之后任何新增节点都可以自动将基础镜像预热，当这个节点提供服务时就可以直接使用，这样可以大幅度提高应用部署的效率。五、应用安全性防护1、级联删除防护面向终态是 Kubernetes 的一个核心能力，但同时也存在一定的风险（见下图）：CRD 误删除导致所有 CR 对象丢失；Newspace 误删除导致 Newspace 下所有对象被删除；Workload 误删除导致下

69、面所有 Pod 被删除。上述情况一旦出现会产生严重的后果。OpenKruise 带给云原生应用管理的新变化OpenKruise 带给云原生应用管理的新变化驱逐；删除；应用原地升级；Sidecar 原地升级；容器重启；当定义 maxUnavailable：25%时，OpenKruise 会尽量保证主动导致 Pod 不可用的操作数量在25%以下。apiVersion:policy.kruise.io/v1alpha1kind:PodUnavailableBudgetspec:selector:#.label selectortargetRef:#.workload referencemaxUnav

70、ailable:25%#minAvailable:15如下图所示，所有会导致 Pod 不可用的操作在经过 ApiServer 时全部被 OpenKruise Webhook拦截，Webhook 会根据客户定义的 PUB 结合 Pod 当前所用数量来决定当前操作是否可以执行。OpenKruise 带给云原生应用管理的新变化开启边缘设备的云原生管理能力开启边缘设备的云原生管理能力作者：刘武明，VMware 主任工程师一、云原生场景下边缘设备的管理云中心大多都是 X86 的服务器，但边缘计算里会遇到不同厂商提供的各种边缘盒子和设备。所以边缘计算需要去管理更多设备。这些设备的能力不同，存储架构也不同可

71、能是 arm 的，可能是 MIPS 的，还有一些很特殊的比如 RSICV。此外还有很多加速器、传感器等等，除了传统的温度传感器、压力传感器，现在还有一些激光雷达、机械控制的手臂等等。开启边缘设备的云原生管理能力开启边缘设备的云原生管理能力首先解释一下为什么需要集成 EdgeX。因为 Kubernetes 主要是管理计算资源,不是管理边缘设备的。另外物联网开发，协议和应用是非常碎片化和定制化的，如果直接去改变原生的Kubernetes，需要对 Kubernetes 进行很大程度的定制化处理。而如果未来升级的话，会有很多 conflicate merge，也很繁琐。Edgex 是 Linux 基金

72、会里面一个领先的开源物联网平台，它里面已经支撑了大量的物联网设备和协议，通过集成它，可以减少 openyurt 用户二次开发的成本，能让快速支持很多的边缘设备。开启边缘设备的云原生管理能力开启边缘设备的云原生管理能力OpenYurt 里面有很多节点池，可以对每个节点池创建不同的 edgex，它们会共享一个服务名称。节点池的部署是以节点池为单位的，可以在里面定义 edgex 的模块，根据所需要的设备去定制化。unite depoinment 是 OpenYurt 里的一个原生特性，通过它来部署 edgex 的时候，可以很大程度上减少维护量。我们在考虑集成的时候，也考虑了 edgex 的易用性和扩

73、展性。首先定义了 8 个基础模块，用户只需要指定它的节点池和版本，就可以向对应的节点池里部署 edgex。同时它也允许用户去定制化地对 edgex 进行部署，比如管理一个 gpl 设备或者蓝牙设备，可以根据节点池里面设备的能力去自动部署这些插件。开启边缘设备的云原生管理能力开启边缘设备的云原生管理能力这里还做了不同设备的区分，分为已管理设备和未管理设备。有些设备并不支持云端控制，只能查询它的状态，比如说温度或摄像头等等，这些是未管理设备。但是有一些设备我们希望它是可以被云端控制的，就是已管理设备。而且云端的优先级是大于边缘侧的。另外它还是声明式的设备管理。上图右边是一个配置的案例，如果想配置一

74、个灯泡，要先声明颜色。未来我们要完成 edgex 新版本的支持。另外对于节点池里面有混合架构节点的问题，服务和高可用问题，都会在下一个版本里解决。三、使用 OpenYurt 管理边缘设备看一下 OpenYurt 的新功能。开启边缘设备的云原生管理能力开启边缘设备的云原生管理能力device controller 部署下去以后，会去扫描边缘设备节点，同时以 CR 的形式反映到云端，在云端就可以查询到这些 CR。后面只需要控制 CR 就可以控制边缘设备。四、演示接下来看一个实际的演示。这是一个云节点和一个边缘节点组成的 OpenYurt 集群，边缘节点是一个树莓派，通过 GPIO连接一个带颜色的灯

75、和一个温度湿度传感器。开启边缘设备的云原生管理能力深入理解 OpenYurt深入理解 OpenYurt作者：张力方，电信天翼云研发工程师一、从云到边缘的挑战与应对目前来看，边缘计算场景下的挑战还是比较多的。下图中的两个挑战可以凸显 OpenYurt 的一些特性。第一点是在边缘计算场景下节点数量会非常多，特别是在一些 IoT 场景，运维的复杂度非常高。如果没有一个统一的运维入口，分开管理会非常麻烦。同时，如果我们用原生 K8s 做法，按地域把每个内网划分成一个集群，那就会有相当大的集群量，要对那么多集群进行管理，运维难度也是相当大的。第二点是网络问题，没有公网访问条件的情况下，在原生 K8s 上

76、的 APIServer 没有办法访问到节点 kubelet，exec/logs 命令都无法执行。再者,如果边缘节点跟云端网络断联，重启边缘节点的时候是没有办法恢复的，因为它没办法从 APIServer 里面拿到启动它所需的 pod 和其他相关信息。深入理解 OpenYurt深入理解 OpenYurt上图描述了这样一个场景：假设我们有广州、深圳两个地域的应用。我们通过节点池把它们划分出来，当我们需要在不同的地域节点上去部署应用的时候，就可以通过 YurtAppSet(原名（UnitedDeployment)去定义这个应用。可以看到，广州的节点数量比深圳的少一些，通过YurtAppSet 就可以做

77、到对不同的节点池定义不同的副本数，去适配每个节点池的能力。单化部署有节点池流量闭环的能力，就是把节点池内部的 service 流量管控在单一的节点池之内。比如广州深圳这两个节点池，如果网络上没有做特殊打通的话，从广州节点池肯定无法访问到深圳 service Endpoint 的。深入理解 OpenYurt深入理解 OpenYurt在实际应用场景中，只提供副本数的差异化配置是不够的，除了副本数以外，其他的字段也可能会有差异。这种情况下，YurtAppSet 提供了一种 patch 的功能，通过 patch 字段，可以修改节点池里的一些定义，这样就可以在继承整个部署模板的前提下做一些定制化的改造，

78、提高YurtAPPSet 的实用性。三、YurtHub1、YurtHub 概览YurtHub 是 OpenYurt 里面非常重要的组件。深入理解 OpenYurt深入理解 OpenYurt除了上述反向代理能力以外，YurtHub 还有两个比较重要的能力。一个是流量闭环，它用来保证 service 流量不出节点池的范围，从而保证 service 可以正常访问。还有一个是 API 地址的改写能力，主要是为了让边缘应用无缝接入 YurtHub。YurtHub 数据缓存的原理是用 Json 文件的方式把响应保存在本地的磁盘上。看一下上图右侧的目录，它的默认保存路径是在 etc 的 cache 目录下，

79、以组件的维度做了缓存，component/resource/namespace/name 这整一段就是一个 catch key。当组件去访问 YurtHub，它就会根据 catch key 去拿对应的信息。2、YurtHub 数据缓存能力深入理解 OpenYurt深入理解 OpenYurt3、YurtHub 数据过滤框架YurtHub 的数据过滤框架，主要原理就是在收到 API server 响应后，返回响应前，在 YurtHu-b 中注入一个修改点。深入理解 OpenYurt深入理解 OpenYurt第三点要为 kube-proxy 开启 EndpointSlices feature gat

80、e；只有开启了 EndpointSlices feature gate，kube-proxy 才能拿到这个节点上的 endpoint 拓扑信息。如果使用的版本是小于等于 1.18 的，我们要手动开一下，因为它默认是关闭的；如果使用的版本是大于 1.18 的，它是默认支持的。最后要配置 kube-proxy，将 YurtHub 地址作为 APIserver 的地址。如何方便的将 kube-proxy 的 APIServer 地址替换成 YurtHub 呢？这就引出下面一个问题：Yurthub 数据过滤框架的 APIServer 地址改写。APIServe 集群里面的 pod 可以通过内部的 se

81、rvice 去访问 APIServer，当 kubelet 在 listwatch service 的时候，我们会看到这个地址是一个 service 地址clusterIP 10.96.0.1。如果这个 service 的后端 endpoint 对应的是一个公网 IP 的话，那它的确是可以访问的，但访问的依旧是 APIServer，而不是 YurtHub。深入理解 OpenYurt深入理解 OpenYurt从原来的架构图来上看，大家可能觉得只有边缘才会有 YurtHub。实际上后来我们为 YurtHub增加了另外一种工作模式CloudMode。YurtHub 在云端主要的作用是开启流量闭环，它

82、不需要做缓存工作。所以当 YurtHub 工作在cloud mode，它会关闭缓存能力，请求只透传，不缓存。并且禁用数据过滤框架的 discardcl-oudservice fliter。三、YurtTunnel1、YurtTunnel 概览深入理解 OpenYurt深入理解 OpenYurt首先，Agent 启动的时候，要有一个注册流程。其次，当 TunnelServer 收到请求的时候，内部会有一个 Interceptor 模块。因为 ANP server 是上游社区的组件，它要求客户端要用HTTP Connect 的方式显式地创建代理。显然我们不太可能改变原有应用的请求方式，所以就在 T

83、unnelServer 内部增加了 Interceptor 模块，由他来代替客户端向 ANP server 去发起connect 请求。server 和 agent 之间是用 gRPC 的方式来通信，比如建立连接，然后响应数据关闭这些功能。2、YurtTunnel 导流模式提到 TunnelServer，有一个很重要的概念导流模式，就是怎么样把云端访问到边缘的流量导入到 tunnel 里面。YurtTunnel 目前有两种导流方式，第一种就是 DNAT 的模式，它是开箱即用的，开发人员可以直接使用它，不用做任何配置。第二个是 DNS 模式，稍微复杂一点。深入理解 OpenYurt深入理解 Op

84、enYurt上图描述了隧道不通的情形。在多 master 的架构下，client 通过 loadBalance 去访问，如果采用的是这种轮巡的方式，访问到没有 Tunnel 的节点，运维隧道就没有办法正常工作。要解决这个问题，我们推荐使用 DNS 模式。深入理解 OpenYurt深入理解 OpenYurt第三点是要修改 DNS 的配置，要将 yurt-tunnel-nodes ConfigMap 挂载为 Volume。还要修改 CoreDNS 的配置，添加 Host 插件。3、YurtTunnelWhats next最后谈一下对 YurtTunnel 的期待和展望。首先 DNS 的配置的确比较

85、复杂，不够便捷。其次 YurtTunnel 不具备边缘通信能力，也不支持PodeIP 和 ServiceIP 的访问，它相对于原生的 k8s 体验还是有一定的差距的。这些都将成为接下来行业发展的方向和目标。深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践万物互联的时代，产生了很多智能家居，它们除了简单的接入网关之外，还有很多数据需要处理，这部分也是边缘侧的应用场景。以上都是是我们遇到的机遇，那挑战是什么？对于一些传统行业而言，它们的云计算可能是很小的，比如市面上有很多私有云场景、政府专有云场景，它们不足以做到像大厂商那

86、些云计算一样无限的扩容来做很多计算处理。目前的市场环境下，云和端的环境非常不理想，主要原因有以下几个方面。第一，因为端侧数据采集的设备普及率非常低，导致很多有用的数据没有办法采集上来供云端的大脑进行分析操作。第二，采集数据的维度特别低，功能单一，会漏掉一部分有价值的数据。第三，前端设备的维保非常难。以摄像头为例，我们没办法对每一个摄像头进行严密的监控和维护。出事故以后去追溯问题，可能已经过了好几天了。在这种情况下，这部分数据就会丢失。第四，行业的数据标准不一样。设备一直在更新迭代，数据的标准也在不断更新。市面上有很多不同类型的设备，把这些设备的数据统一集中到云端去做处理，云端的能力也跟不上。深

87、信服智能边缘计算平台与 OpenYurt 落地方案探索与实践深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践首先，我们采取的是云端一体化架构。在边端给用户部署一个云边一体机，也可以理解成是一个小型的服务器，它可以和终端设备放在同一个地方。于是他们之间会整体形成一个独立的小网络。这样边端的设备就可以把数据发给云边一体机，数据就可以得到尽快的处理和响应。其次，即使在云边断网的情况下，端侧可以和边侧一体机进行网络访问，我们可以内置一些 AI算法进去，让他在特定场合下的指令也可以得到响应。最后就是关于数据的处理。云侧边侧的网络带宽是有限的，我们可以先将数据收集在一体机里，先做一轮处理，把

88、一些有效的数据处理出来。再将这些数据通过的 SD-WAN 网络汇报到中心侧进行处理，这样一方面减轻了带宽的压力，另一方面提高了中心侧的数据处理能力。云边断网情况下的边缘自治能力其实是根据我们和社区的 OpenYurt 进行结合，将云边运维通道、边缘端的自治以及单元化部署都有机结合到了一起，形成了这样一个边缘计算的架构图。云边一体机的最终目标是为智能化改造打通最后一公里。它里面提供了很多功能，包括控制面板，AI 算法的平台，以及监控日志的收集，当然还有最重要的安全网络管理，以及一些视频的解码编码。同时这个盒子也是支持硬件适配的，比如 arm架构、x86 架构，还包括不同的网络 GPU 的配合、底

89、层数据操作系统适配。深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践说了这么多关于真实业务落地场景，后面将会结合整个平台的架构来讲解我们的改造思路。KubeManager（KM）架构是我们公司自研的一个产品，它是一个容器管理平台，底层是由多个 k8s 集群管理构建起来的，集成了多个应用商店和软件，还有一些数据的采集和监控、给用户的可视化展示。它主要分为两个大的模块，上图左下方是管理集群，前文提到的一系列内容都是在管理集群里去承接的。用户集群可以通过接入层来进行数据接入，然后将 API 的数据发送到 API 业务层，再把

90、这些数据存储到原生 k8s 的 etcd 里面去。我们做改造的部分主要是针对用户集群这一块，跟 OpenYurt 做结合。在改造落地的过程中也出现了很多问题。深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践改造之后，用户集群架构就从上图左边这切换到了右边的状态。这里面的改造主要有以下几点：第一，对 YurtControlManager 组件做了改动，以前它是个 deployment，它的副本数是 1。现在把它改成了 DaemonSet，会随着 master 数量的变化自动扩缩容，这是一个。第二，因为整体流量是通过 Ng

91、inx 找不同的 APS server 做代理，所以 YurtHub 其实不是直接访问 APIserver，而是通过 Nginx。但它现在这样也可以达到边缘集群和 OpenYurt 的结合之后想要的效果比如流量过滤和边缘自治。四、行业未来展望以及社区发展期许最后说一下关于整个行业的发展和未来的期望。从上图可以看到，边缘设备的成长是一个不断累积的过程。整个行业的发展对边缘设备会有非常多的需求，这么大的需求会带动整个行业的发展，行业的发展也离不开边缘社区，包括OpenYurt 社区的贡献。希望每一个用户在使用 OpenYurt 的时候可以更加边缘化、安全化和智能化。从中心走向边缘深度解析云原生边缘

92、计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业数字化在敏捷连接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求”。从 CT 电信领域视角，边缘计算最初也被称为移动边缘计算（MEC）。欧洲电信标准协会（ETSI）对 MEC 的定义：“移动边缘计算在移动网络的边缘、无线接入网（RAN）的内部以及移动用户的近处提供了一个 IT 服务环境以及云计算能力”。边缘计算的定义各有侧重，但核心思想基本一致边缘计算是基于云计算核心技术，构建在边缘基础设施之上的新型分布式计算形式，在边缘端靠近最终用户提供计算能力，是一种靠近数据源的

93、现场云计算。中心云计算凭借其强大的数据中心，为业务应用提供大规模池化，弹性扩展的计算、存储、网络等基础设施服务，更适用于非实时、长周期数据、业务决策场景；边缘计算则聚焦在实时性、短周期数据、本地决策等业务场景，比如当下热门的音视频直播、IoT、产业互联网、虚拟现实甚至元宇宙等，将工作负载下沉至离终端设备或者靠近最终用户的地方，以此实现更低的网络延迟，提升用户的使用体验。2、“章鱼式”边缘计算边缘是相对中心式计算的边缘分散式计算。边缘计算的核心目标是快速决策，将中心云的计算能力拓展至“最后一公里”。因此它不能独立于中心云，而是在云-边-端的整体架构之下，有中心式管控决策，也有分散式边缘自主决策，

94、即章鱼式边缘计算。从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点边缘计算生态参与者众多，云厂商、设备厂商、运营商三大关键服务商方以及一些新型 AI 服务商等，都是从各自现有优势延伸，拓展更多客户及市场空间。设备商借助物联网逐渐构建单一功能的专业云；云厂商从中心化的公有云开始下沉，走向分布式区域云，区域云之间通过云联网打通，形成一个覆盖更大的云。运营商在互联网时代被公有云及繁荣的移动应用完全屏蔽只能充当管道，但在边缘计算时代，业务及网络定义边缘计算，运营商重新回归焦点，不可替代。4、边缘计算的类型1）网络定义的边缘计算：通过优化终端与云中心网络路径，将中

95、心云能力逐渐下沉至靠近终端，实现业务就近接入访问。从中心到边缘依次分为区域云/中心云，边缘云/边缘计算，边缘计算/本地计算三大类型：区域云/中心云：将中心云计算的服务在骨干网拓展延伸，将中心化云能力拓展至区域，实现区域全覆盖，解决在骨干网上耗时，将网络延迟优化至 30ms 左右，但逻辑上仍是中心云服务。边缘云/边缘计算：将中心云计算的服务沿着运营商的网络节点延伸，构建中小规模云服务或类云服务能力，将网络延迟优化至 15ms 左右，比如多接入边缘计算（MEC）、CDN。边缘计算/本地计算：主要是接近终端的现场设备及服务能力，将终端部分逻辑剥离出来，实现边缘自主的智能服务，由云端控制边缘的资源调度

96、、应用管理与业务编排等能力，将网络延迟优化至 5ms 左右，比如多功能一体机、智能路由器等。从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点码头，矿山等）领域，相比消费者领域，相信会带来更大变革与价值。2）业务定义的边缘计算：除了面向消费者的互联网边缘场景，边缘计算更多的是面向实体产业及智慧化社会衍生的场景。对于实体产业场景来说，由于历史原因，在边缘及现场存在大量异构的基础设施资源；通过业务需求驱动边缘计算平台的建设，不仅要整合利用现有基础设施资源，还要将中心云计算技术及能力下沉至边缘及现场，实现大量存量业务运营管控上云，海量数据统一入湖，以此支持整个企

97、业的数字化转型。对于智慧化社会衍生场景来说，越是新型的业务，对网络时延敏感越高，数据量越大，结构化数据逐渐转化成非结构化数据，需要人工智能，神经网络等高等智能化技术支持。当前对网络时延敏感的新型业务场景，都是通过云端总控管理，设备现场实时计算这种分布式架构策略，以此减弱对网络的强依赖。面向业务将边缘计算分为智能设备/专业云及产业边缘/行业云两种类型：智能设备/专业云：基于云计算能力之上，围绕智能设备提供整体化，有竞争力的解决方案，包含智能设备、云端的服务以及端到云之间的边缘侧服务，比如视频监控云、G7 货运物联等；从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算

98、落地痛点总的来说，边缘计算范围大，场景泛，目前整个行业缺少经典的案例及标准。因此推动边缘计算落地，一定是面向真实的业务场景及需求整体规划，面向价值逐步建设。二、Kubernetes 从中心走向边缘Kubernetes 遵循以应用为中心的技术架构与思想，以一套技术体系支持任意负载，运行于任意基础设施之上；向下屏蔽基础设施差异，实现底层基础资源统一调度及编排；向上通过容器镜像标准化应用，实现应用负载自动化部署；向外突破中心云计算的边界，将云计算能力无缝拓展至边缘及现场，快速构建云边一体基础设施。将云原生技术从中心拓展到边缘，不仅实现了云边基础设施技术架构大一统，业务也实现了云边自由编排部署。相对于

99、 Kubernetes 在中心云的革命性创新，在边缘场景虽优势明显，但缺点也很致命，因为边缘侧存在资源有限、网络受限不稳定等特殊情况，需要根据不同业务场景，选择不同 Kubernetes 边缘方案。1、Kubernetes 架构及边缘化的挑战Kubernetes 是典型的分布式架构，Master 控制节点是集群“大脑”，负责管理节点，调度Pod 以及控制集群运行状态。Node 工作节点，负责运行容器（Container），监控/上报运行状态。边缘计算场景存在以下比较明显的挑战：从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点边缘节点 Remote Nod

100、e：基于 Kubernetes 二次开发增强扩展，将 Kubernetes 解耦适配成云边分布式架构的场景，中心化部署 Master 管理节点，分散式部署 Worker 管理节点。此外，一致性是边缘计算的痛点，在边缘增加一个 Cache 即可实现断网特殊情况的边缘自治，同时可以保证正常网络情况的数据一致；还有就是 Kubelet 比较重的问题，随着 Kubernetes放弃 Docker 已经开始精简；同时硬件更新迭代较快，相比少量硬件成本，保持 Kubernetes 原生及通用性为大。其实更希望 Kubernetes 社区本身提供适配边缘化方案，同时考虑为 Kubelet增加缓存机制。3、K

101、ubernetes 边缘容器快速发展Kubernetes 已成为容器编排和调度的事实标准，针对边缘计算场景，目前国内各个公有云厂商都开源了各自基于 Kubernetes 的边缘计算云原生项目，比如阿里云向 CNCF 贡献的OpenYurt，采用边缘节点 Remote Node 方案,是业界首个开源的非侵入式边缘计算云原生平台，秉承“Extending your native Kubernetes to Edge”的非侵入式设计理念，拥有可实现边缘计算全场景覆盖的能力。华为、腾讯、百度等，也都开源了自己的边缘容器平台。边缘容器的快速发展带动了领域的创新，但一定程度上也导致构建边缘计算平台时难以抉

102、择。从技术架构来看，几个边缘容器产品总的架构思路主要是将 Kubernetes 解耦成适合云边、弱网络及资源稀缺的边缘计算场景，本质上无太大差异；从产品功能来看也是如此，基本上都涵盖云边协同、边缘自治、单元化部署功能等。4、如何构建云边一体化云原生平台从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点三、OpenYurt：智能边缘计算平台开源实践OpenYurt 以上游开源项目 Kubernetes 为基础，针对边缘场景适配的发行版。是业界首个依托云原生技术体系、“零”侵入实现的智能边缘计算平台。具备全方位的“云、边、端一体化”能力，能够快速实现海量边缘计

103、算业务和异构算力的高效交付、运维及管理。1、设计原则OpenYurt 采用当前业界主流的“中心管控、边缘运行”的云边分布式协同技术架构，始终贯彻“Extending your native Kubernetes to Edge”理念，同时遵守以下设计原则：“云边一体化”原则：保证与中心云一致的用户体验及产品能力的基础上，通过云边管控通道将云原生能力下沉至边缘，实现海量的智能边缘节点及业务应用，基础架构提升至业界领的云原生架构的重大突破。“零侵入”原则：确保面向用户开放的 API 与原生 Kubernetes 完全一致。通过节点网络流量代理方式（proxy node network traffi

104、c），对 Worker 工作节点应用生命周期管理新增一层封装抽象，实现分散式工作节点资源及应用统一管理及调度。同时遵循“UpStream First”开源法则；从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点3）边缘单元化负载：在边缘计算场景，面向业务一般都是“集中式管控，分散式运行”这种云边协同分布式架构；对于管理端，需要将相同的业务同时部署到不同地域节点；对于边缘端，Worker 工作节是一般是分散在广域空间，并且具有较强的地域性，跨地域的节点之间网络不互通、资源不共享、资源异构等明显的隔离属性。适配增强 Kubernetes 能力，基于资源，应用及

105、流量三层实现对边缘负载进行单元化管理调度。通过 OpenYurt 开源社区引入更多的参与方共建，联合研发方式提供更多的可选的专业功能，OpenYurt 特性正在逐步完善，并扩大覆盖能力：1）边缘设备管理：在边缘计算场景，端侧设备才是平台真正的服务对象；基于云原生理念，抽象非侵入、可扩展的设备管理标准模型，无缝融合 Kubernetes 工作负载模型与 IoT 设备管理模型，实现平台赋能业务的最后一公里。目前，通过标准模型完成 EdgeX Foundry 开源项目的集成，极大的提升了边缘设备的管理效率。2）本地资源管理：在边缘计算场景，将边缘节点上已有的块设备或者持久化内存设备，初始化成云原生便

106、捷使用的容器存储，支持两种本地存储设备：（一）基于块设备或者是持久化内存设备创建的 LVM；（二）基于块设备或者是持久化内存设备创建的 QuotaPath3、OpenYurt 设计架构及原理1）设计架构从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点OpenYurt 践行云原生架构理念，面向边缘计算场景实现云边协同分布式架构及中心管控边缘运行的能力：针对边缘节点自治能力，一方面，通过新增 YurtHub 组件实现边缘向中心管控请求（Edge ToCloud Request）代理，并缓存机制将最新的元数据持久化在边缘节点；另一方面新增YurtControl

107、lerManager 组件接管原生 Kubernetes 调度，实现边缘自治节点状态异常不触发重新调度；针对 Kubernetes 能力完整及生态兼容，通过新增 YurtTunnel 组件，构建云边（Cloud ToEdge Request）反向通道，保证 Kubectl，Promethus 等中心运维管控产品一致能力及用户体验；同时将中心其他能力下沉至边缘，包含各不同的工作负载及 Ingress 路由等。针对边缘单元化管理能力，通过新增 YurtAppManager 组件，同时搭配 NodePool,YurtAppSet（原 UnitedDeployment），YurtAppDaemon，S

108、erviceTopology 等实现边缘资源，工作负载及流量三层单元化管理；针对赋能边缘实际业务平台能力，通过新增 NodeResourceManager 实现边缘存储便捷使用，通过引入 YurtEdgeXManager/YurtDeviceController 实现通过云原生模式管理边缘设备。4、核心组件OpenYurt 所有新增功能及组件，均是通过 Addon 与 Controller 方式来实现其核心必选与可选组件如下：从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点5、当前挑战1）云边网络在边缘计算场景中，被提到最多的就是云边网络差且不稳定；其实

109、国内基础网络在 2015 年开始全面升级；尤其是在“雪亮工程”全面完成之后，基础网络有一个很大的提升。上图摘自第48 次中国互联网络发展状况报告，固网 100Mbps 接入占比已达 91.5%；无线网络接入已经都是 4G，5G 的优质网络。真的挑战在云边网络组网，对于使用公有云的场景：公有云屏蔽数据中心网络，只提供了互联网出口带宽，通过互联网打通云边，通常只需要解决数据安全传输即可，接入不复杂。对于私有自建的 IDC 场景：打通云边网络并不容易，主要是运营商网络没有完全产品化，同时私有IDC 层层防火墙等其他复杂产品，需要专业的网络人员才能完成实施工作。2）list-watch 机制与云边流量

110、从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点源非常充足，足以将整个云原生体系下沉。针对智能设备边缘，资源相对比较稀缺，但一般都会通过一个智能边缘盒子，一端连接设备，一端连接中心管控服务，从上图的 AI 边缘盒子来看，整体配置提升速度较快，长期来看，边缘的算力快速增强以此来满足更复杂更智能化的场景需求。4）Kubelet 比较重，运行占用资源多对于 Kubelet 比较重，运行占用资源多的问题，需要深入了解节点资源分配及使用情况，通常节点的资源自下而上分为四层：运行操作系统和系统守护进程（如 SSH、systemd 等）所需的资源。运行 Kuberne

111、tes 代理所需的资源，如 Kubelet、容器运行时、节点问题检测器等。Pod 可用的资源。保留到驱逐阈值的资源。从中心走向边缘深度解析云原生边缘计算落地痛点从中心走向边缘深度解析云原生边缘计算落地痛点基于中心云的分布式业务应用架构，与云边分布式协同业务应用架构本质上有很大差别。在中心云更多的是基于 DDD 业务领域，将复杂的业务系统拆分成一个个相对独立的服务，整体构建一个松耦合的分布式应用；但在云边分布式场景下，更多强调的是集中式管控运营，分散式运作支撑；将管理运营系统集中在云中心，实现中心式管控；将支撑业务实时运作的应用分散至边缘，实现低延迟快速响应。从业务应用来看，财务/经营，计划/管

112、理两层属于管控运营类的应用，就是需要通过中心云统一汇聚，实现集中化强管控；对延迟不敏感，对安全，大数据分析能力等要求较高；控制，传感/执行，生产过程三层属于运作支撑类应用，也可以优先考虑中心云；如果业务场景对延迟敏感，才考虑通过边缘计算能力，实现分散式低时延响应；从请求响应来看，对时延不敏感（50ms 以上）都有限考虑部署在中心云计算及云化的边缘产品（CDN）实现；对延迟敏感（小于 10ms），运营商骨干网完全无法支持的，考虑建设边缘计算平台，同时业务面临不小的投入及人员；以实体物流领域为例，经典的 OTW 系统（OMS 订单管理系统，WMS 仓库管理系统，TMS 运输管理系统）；其中 OT

113、就属于典型的管理运营系统，所以建议部署在中心云，通过中心云数据汇聚，实现拼单拆单，多式联运等跨区域业务；W 是仓库管理系统，管理四面墙的任务，属于运作支撑应用，并且仓库一般都有一些自动化设备，就可以考虑将 W 部署在边缘。五、总结边缘计算平台的建设，以 Kubernetes 为核心的云原生技术体系，无疑是当前最佳的选择与建设路径；但是云原生体系庞大，组件复杂，将体系下沉至边缘会面临很大的挑战与困难，同时充满巨大的机遇及想象空间。业务应用想要真正践行边缘的云原生体系，需要从理念、系统设计、架构设计等多方面来共同实现，才能充分发挥边缘的优势及价值。OpenKruise 提升云原生应用自动化新高度O

114、penKruise 提升云原生应用自动化新高度基于 OpenKruise 部署 K8S 的逻辑架构图3、OpenKruise 能做什么？a、OpenKruise 专注领域包括：通用工作负载（部署、发布）；Sidecar 容器管理；应用分区管理；增强运维能力；可用性防护；OpenKruise 提升云原生应用自动化新高度OpenKruise 提升云原生应用自动化新高度OpenKruise 是阿里“双十一”全链路部署基座。其中：CloneSet 部署了集团大部分无状态应用；Advanced StatefulSet 是针对原生 StatefulSet 的扩展，部署有状态的中间件应用；SidecarSe

115、t 是 Sidecar 管理的资源，针对 Mesh 容器、运维容器、安全容器的管理；Advanced DaemonSet 针对基础网络组件和基础存储组件；Operation Capabilities 针对运维能力。二、OpenKruise 为云原生带来高效的部署能力1、核心能力 1-原地升级a、Kubernetes-Pod 维度的不可变基础设施如下图所示，在 K8s 中 Pod 重建需要删除旧的 Pod 然后调度再拉起新的 Pod，流程复杂且耗时长，如果在类似双十一的场景下就无法实现。b、容器维度的管控能力-原地升级下图中 CloneSet 是针对 Deployment 的工作负载，省去中间的

116、 Replicas 直接连 Pod，如果Pod 要升级，CloneSet 先停止 nginx v1，拉起 v2 版本镜像，这个过程不涉及 Pod 重建，Pod的网络、存储都不变，即为原地升级。OpenKruise 提升云原生应用自动化新高度OpenKruise 提升云原生应用自动化新高度a、优势：将辅助能力同业务容器解耦，实现独立发布和能力重用；b、缺点：Sidecar 升级将导致业务 Pod 重建；业务 Pod 配置耦合（运维、安全、代理）多种 sidecar，增加配置的复杂性，以及 sidecar更新难度。c、SidecarSet 管理 Sidecar 容器的利器针对上述缺点开发的 Sid

117、ecarSet 工作负载，如下图：OpenKruise 提升云原生应用自动化新高度OpenKruise 提升云原生应用自动化新高度思考：镜像拉取占用了大量时间，能否有优化的空间？b、OpenKruise 提供“规模化镜像预热的能力”OpenKruise 提供 ImagePullJob 的 CRD 解决上述问题。组合拳：镜像预热+扩容1）原始 Pod 扩容流程/耗时：2）用 ImagePullJob 长期预热 app 基础镜像和 Sidecar 镜像：3）基础预热后的 Pod 扩容/耗时：OpenKruise 提升云原生应用自动化新高度OpenKruise 提升云原生应用自动化新高度面向终态是

118、Kubernetes 的一个核心能力，但同时也存在一定的风险（见下图）：CRD 误删除导致所有 CR 对象丢失；Namespace 误删除导致 Namespac 下所有对象被删除；Workload 误删除导致 Workload 下面所有的 Pod 被删除。因此，OpenKruise 提供级联删除防护能力，将定义的资源增加一个 label，当发生删除时，OpenKruise 会对加 label 的资源进行再校验。metadata:labels:policy.kruise.io/delete-protection:CascadingCascading：这个对象如果还有可用的下属资源，则禁止被删除；

119、Always：这个对象禁止被删除，除非上述 label 被去掉。支持防护的资源类型：NamespaceCustomResourceDefinition（CRD）OpenKruise 提升云原生应用自动化新高度OpenKruise 提升云原生应用自动化新高度5、核心能力 5-分区拓扑和弹性管理a、云时代的“部署挑战”在 K8s 中部署都是均匀的，不会有优先等级。OpenKruise 提供弹性调度能力，在业务高峰期时将 Pod 部署在 ECI 上按量付费，高峰期过后就可以将 ECI 中的 Pod 缩容。OpenKruise 提升云原生应用自动化新高度OpenKruise 提升云原生应用自动化新高度

120、WorkloadSpread 架构d、“极致弹性调度”最佳实践在上图代码中：subset-a 和 subset-b，分别对应右图中的自由资源池和弹性资源池；maxRelicas:300，是自由资源池最多 300 个 Pod；OpenKruise 提升云原生应用自动化新高度 2021.12（v1.0.0）规划：2022 年 CNCF Sandbox-Incubation双周周会（每周四晚 19 点）业界用户：国内：阿里巴巴、蚂蚁、携程、苏宁、OPPO、小米、斗鱼 TV、有赞、Boss 直聘、申通、小红书等 25+登记企业用户；国外：Lyft、Bringg、Arkane Systems、Spect

121、ro Cloud 等 5+登记企业用户。感兴趣的朋友可以加入社区钉钉群了解更多内容，一起交流分享。189OpenKruise 提升云原生应用自动化新高度2、Roadmap未来会针对以下领域开展工作：针对有状态的服务，比如固定 IP 或 PV；资源分发；分批发布、流量发布、灰度发布；欢迎对以上领域感兴趣的朋友加入社区一起分享。混合云环境云原生应用交付和管理平台混合云环境云原生应用交付和管理平台1、CI：如图示上方是一个典型的 CI 流程，可分为三个部分：镜像构建（Build）、测试(Test)和应用打包(Artifacts)。这个流水线过程的目的是输入源码到输出云原生制品。在这个过程中针对代码处

122、理和制品处理的工具链已经很丰富，比如 Jenkins 的插件体系。目前也有比较多的企业在 CI 流水线的最后一步直接进行应用的部署，它的目标可能有主机、容器环境、K8s 环境、甚至更大规模的多集群 K8s 环境等，把服务进行发布上线的过程就是接下来我们要聊的 CD 环节。2、CD：图示下方是将 CD 环节拆开来看，将制品进行部署的过程包括环境和参数配置、资源组装、流程编排、部署到多环境等，在开发环境、预发环境、生产环境、私有环境或各个边缘环境中去部署和发布。发布过程需要可观测，可追踪、可回退，发布的后续动作还会包括监控、运维等。我们可以发现，CD 环节需要面对的复杂性不亚于 CI 环节，相反，

123、它还是影响业务稳定的最重要环节。3、CIOps:围绕 CI 工具的持续交付kubectl applyhelm upgrade其它模板方案然后 apply.以上是围绕 CI 做发布的常见形式，比较笼统的将服务配置下发的目标集群上。二、CIOps：做 CI 很好，CD 问题很多1、问题一：“基础设施的复杂性”暴露给开发者混合云环境云原生应用交付和管理平台混合云环境云原生应用交付和管理平台目前中大型公司已经开始了上云、容器化的工作，整个云的形态已经朝着分布式的形式发展，但由于发布环境各异，需求各异，导致编排极其复杂。a、场景现状：同一个应用，在不同环境下部署的组件依赖差异巨大；数据库、负载均衡、K8

124、s,在不同云上也存在诸多差异；b、开发现状：开发者心智负担重，单一系统缺乏统一交付能力；需要补充大量人工操作，缺乏自动化；c、同一个应用，在不同场景下的运维能力要求差异巨大开发测试环境：需要进行热加载、调试、查看开发日志以及实时运行的情况等；预发联调环境：需要考虑服务之间的调用，测试时需要观看响应指标，绑定资源，错误定位，进行攻防演练等；生产环境：包括可观测性、流量、云服务等。3、问题三：以“脚本”为中心的系统缺乏自动化混合云环境云原生应用交付和管理平台混合云环境云原生应用交付和管理平台CI/CD 的安全域无法隔离，各种权限混合使用；CI 系统的权限难以控制，多集群、多租户。三、云原生应用持续

125、交付，用户的核心诉求是什么？1、用户对云原生应用持续交付的核心诉求CD 持续发布过程中的诉求：统一抽象：K8s 持续演进帮助我们把底层各种各样的基础设施完全抽象化，抽象化过程需要不同企业的相应类似描述文件，描述文件相同的是描述、日志等，不同的是服务名称、镜像、服务端口等；自动化编排：屏蔽编排的复杂性，提供自动化能力；部署能力：安全、稳定、大规模地把此资源分发到不同环境和集群里。目标是开发者在制品仓库输入变量，后面的过程可以完全自动化的进行，将复杂巨大的程序都屏蔽在底层，如果有问题可以由专业的工程师做相应的维护和调试。2、如何实现K8s 带来的启示：声明式是用户侧抽象的最佳表达方式，将复杂管理逻

126、辑下沉到 K8s 中，对用户仅暴露终态/意图的输入。混合云环境云原生应用交付和管理平台混合云环境云原生应用交付和管理平台KubeVela 为广大开发者提供了一个面向现代云原生环境的应用交付/持续交付系统：以应用为中心的开发者体验；面向终态的声明式交付工作流；面向混合环境，基础设施无关；laC/可编程，高度可扩展；CNCF 项目地址：https:/ K8s 控制平面，面向混合环境统一交付混合云环境云原生应用交付和管理平台混合云环境云原生应用交付和管理平台面向终态的统一云资源管理；KubeVela 集成了 Terraform 的云资源描述能力，继而集成了 Terraform 的云资源支持生态，通过

127、 Application 描述用户可以同时交付普通服务和云服务组成完整交付应用。云边一体的统一交付模式；集成边缘应用的描述规范，边缘环境以 KubeAPI 规范接入到管控平面，实现边缘应用的维护和分发。面向不同场景需求用户分层集成；KubeVela 架构上分为核心模块和上层终端产品 VelaUX，对于大型企业的 PaaS 平台开发者，可直接集成 KubeVela 核心模块，获取应用引擎能力。对于中小型终端客户，可借助终端产品生态快速落地。同时 VelaUX 也具备了必要的扩展能力，通过编辑配置即可适应不同企业的应用管理诉求。3、Application Demo 示例：1）待交付组件比如容器镜像

128、、Helm chart、云资源 Terraform 模块等.定义任意可交付制品!混合云环境云原生应用交付和管理平台混合云环境云原生应用交付和管理平台5、生态项目对比纯粹的 GitOps 系统：本质上是在运行时集群中的 agent,无法跨环境交付；经典应用 CI/CD 交付平台：本质上是面向过程的执行，不具备声明式系统的自动、幂等、收敛、确定等特性；安全性问题的本质：基于过程式的 Push vs 基于统一模型的 Pull；各类 Kubernetes 发行版：定位上就严格遵守 K8s 的 API,不提供 K8s 之.上的应用层能力；经典 PaaS/各类“云原生应用管理平台：本质上是不具备开放性的封

129、闭抽象只能处理容器交付，不能面向云进行统一交付不可扩展(需要重写代码和重新部署)，不能跟随用户一起成长和演进被集成性差:用户需要做出唯-性选择，不能够跟其他平台共存6、OAM：现代微服务与应用交付模型要屏蔽繁杂的底层，一个重要的问题就是标准化。将应用通过标准化的描述，让业务和基础测试有完美的衔接，KubeVela 体系完全基于 OAM 的生态去做，欢迎各大厂商共建，普惠云的开发者。7、实践案例-Serverless 应用引擎（SAE）混合云环境云原生应用交付和管理平台集群镜像重塑分布式应用交付集群镜像重塑分布式应用交付作者：方海涛(中弈)，sealer 项目发起人，阿里云技术专家，拥有七年以上

130、云原生从业经验，sealos 作者，数千家企业在生产环境中使用该项目。议题简介：集群镜像把整个集群看成一台服务器，把 K8s 看成云操作系统，实现整个集群的镜像化打包和交付，为企业级软件提供一种“开箱即用”的应用封装技术。以行业 ISV 为例，集群镜像帮助企业解决了分布式软件的部署一致性难题、降低了交付出错率，最终指数级降低分布式软件的交付成本。受 docker 等容器技术的启发，集群镜像将单机应用封装技术，上升到分布式集群维度，最终实现分布式软件的高效交付（build,share,run)。一、背景介绍从应用视角看云的发展历程，就是一个不断屏蔽底层细节的过程。最早是物理机；openstack

131、：做了资源虚拟化，但并未对应用管理做思考，注重了利用率；Docker：主要考虑针对单个应用的打包；kubernetes：管理整个集群，向下整个资源做抽象，向上整个分布式应用做管理，如何部署、升级、配置等；集群镜像重塑分布式应用交付集群镜像重塑分布式应用交付要的镜像甚至二进制如何打包。更不会帮你处理交付时一些常规的操作如修改主机名，时间同步等。三、Sealer-集群镜像介绍定义：如同 Docker 或者虚拟机镜像一样，把整个集群当成一台机器把 kubernetes 当成操作系统，整个集群所有依赖整体打包的技术称之为集群镜像。1、集群镜像介绍如上对比图所示：驱动层：单机上有计算、存储、网络驱动，集

132、群里是 K8s 容器运行 CRI、CNI、CSI 时的实现；操作系统层：单机有 ubuntu centos，集群里是 Kubernetes；容器层：单机是 Docker 镜像，集群里运行着 K8s 的集群；镜像层：单机是 Docker 镜像，而集群里是缺失的环节。集群镜像重塑分布式应用交付集群镜像重塑分布式应用交付定义一个类似于 Docker 文件的 kubefile（如上图左边所示），进行创建 Sealer 集群镜像，包含了内嵌的 kubernetes 和它的所有依赖，到客户环境中，只需要提供好机器，装好操作系统，连接好网络就可以去运行 Sealer。4、集群分享与运行集群镜像重塑分布式应用

133、交付集群镜像重塑分布式应用交付在做高可用的时候不用再去依赖过重的组件；如果启用 Nginx 做反向代理，流量会走 Nginx 的进程，当进程出现问题会影响整体的可用性，而 ipvs 负载只要内核在运行，上层管控组件出现问题时不会影响整个集群的高可用。7、容器镜像缓存机制集群镜像重塑分布式应用交付集群镜像重塑分布式应用交付在交付 Redis 时，账户密码等有变更，同样可以在 Clusterfile 中去定义一个 Config，可以覆盖掉镜像里的任何的文件，不管是 Helm 的 values，还是 etcd 里的文件或者修改自定义的文件。Sealer 的配置能力非常灵活，而且不会限制到底是使用哪种

134、编排工具。四、总结与规划1、客户列表很多客户使用 sealer 极大的提升了交付稳定性和交付效率，把一周左右的交付周期缩短到了小时级别。2、Roadmap 未来规划V1.0 版本发布：着重在整个核心功能，充分测试，高性能，高稳定性；生态系统：让 CloudImage 足够多，更好用，比如让 MySQL、Redis 等更好用；社区推动：推动社区开发者，尽量把 Sealer 作为默认的安装方式，一键交付到客户的集群中。集群镜像重塑分布式应用交付政采云私有化业务交付实践政采云私有化业务交付实践作者：汪勋，sealer maintainer，政采云技术专家，拥有多年云原生实践经验，具备丰富的大型私有化

135、项目交付实践经验。摘要：应用 Sealer 的政采云私有化业务交付实践一、业务私有化交付之痛1、业务背景介绍政采云的业务主要是专注服务于政企采购的云服务平台，业务主要面向政府和大型企业；具有较多的私有化部署项目；业务组件 300+，800+CPU 核心 2000G+内存；交付依赖：30G+2、交付痛点在业务私有化之前，政采云业务都是建立在公有云上，基础设施稳定并可控，但转为私有化以后，政府基于数据安全考虑对网络和基础设施都有一定的限制，导致在交付过程中遇到很多困难和问题：交付环境复杂，不可控；交付涉及任务太多，碎片严重，交付完总有遗漏事项；差异化的版本、配置导致 ansible 的方式成本很高

136、。下图是最初第一版私有化业务交付系统的架构，使用 ansible 方式的问题是 ansible 只解决交付过程而不关心交付依赖。政采云私有化业务交付实践政采云私有化业务交付实践2、Sealer 的亮点功能a、编排定义：简单而不失强大FROM kubernetes:1.19.9COPY helm/binRUN wgethttps:/cai- helm install app app-chartCMD helmlistb、镜像缓存基于文本镜像清单自动打包；多仓库镜像代理；多域名镜像缓存能力；更多的 Sealer 亮点功能还包括：集群证书自动是 100 年无需担心证书过期或额外配置；APIServi

137、ce 实现高可用无需用户做额外配置等。3、交付架构升级下图是交付系统升级后的架构，以 Sealer 为核心，通过编排渲染产出集群镜像，其中包括交付环境的所有依赖，实现纯离线场景下的业务交付。政采云私有化业务交付实践政采云私有化业务交付实践2、对 Sealer 未来的期望随着对数据安全和隐私越来越高的需求，私有云逐渐抢占公有云市场，私有化业务也会随之迅速增长。针对目前使用 Sealer 的一些经验，对 Sealer 社区提出以下期望：生态建设：围绕业务交付的中间件、存储等依赖提供一整套的解决方案；管理功能强化：管理控制台、API；使用体验的持续优化：还存在一些待改进的地方；社区建设：吸引更多的伙

138、伴和场景。开放模块化多集群管理平台 OCM开放模块化多集群管理平台 OCMa、跨机房/地域 Etcd 运维问题首先是跨机房跨地域 Etcd 运维的问题，在轻量规模的 K8s 运维里，一个 Kubernetes 集群可以看作是 Etcd 上面无状态的应用，大部分情况 K8s 的运维的问题，是取决于 Etcd 的运维问题；Etcd 有地域化配置的一些硬性要求，包括两个机房之间的延迟，如果地域比较远，将面临Etcd 要拆分进行部署，如跨机房跨地域，因为 Etcd 要拆分进行部署，所以对应的 k8s 集群也需要进行重新规划，另外在生产运维过程中也随着K8s的规模增长而遇到Etcd请求压力的瓶颈。b、K

139、ubenretes“可用性半径”控制问题其次单机群的一个瓶颈是“可用性半径”控制问题，在 K8s 里面虽然有 Namespace 的概念，在设计上希望能够通过 Namespace 描述这样的租户隔离性，比如应用 1 应该部署在 Namespa-ce1，应用 2 部署在 Namespace2，但事实上 K8s 原生的隔离性还未达到期望，此外即使达到了理想的隔离状态，但还需要预防一些不能预知的灾难（如 k8s 升级/运维/宕机事件），为了能够最简单方式隔绝这些问题，就需要进行“可用性半径”控制，也就是经常提到的爆炸半径控制(比如在成都有个机房，上海有个机房，分别部署一套 K8s，在地域化推荐的服务

140、中也可以通过每个地域一套集群使得各自可用性不会出现冲突和相互牵连)。c、原生 Kubernetes 租户级别隔离性不足最后是 K8s 内部原生租户级别的隔离性不足，在多集群之外，还有一个并行的工作小组叫做多租户，多集群和多租户要解决的问题是同质的，而多集群解决隔离性是采取一种更温和的方式：充分尊重单个集群 K8s，不修改源代码，在控制平面进行对应 K8s 集群的管理，可以灵活的接管或者踢出一个集群。所谓的多租户形态的集群管理，目标是能全透明的将各个集群的信息映射/收集回中枢控制面中再进行统一的管理。2、多集群用户场景a、集群级别的弹性扩容目前多集群应用的场景也有很多，首先是集群级别的弹性扩容，

141、如阿里云上双 11 的弹性大促和扩容；类似场景还有机房级别的弹性迁移，如在多机房迁移或者运营商的切换等情况下，需要进行集群级别的迁移，这种情况下需要多集群的控制平面，去管理和衔接其中的复杂性。开放模块化多集群管理平台 OCM开放模块化多集群管理平台 OCM1、主要架构OCM 的架构图首先，在 K8s 架构中，K8s 有一个控制节点叫 kube-master（包括 Scheduler、Apiserver、Controller manager 等组件），将节点注册到 master 里，在这个过程中，Node 是通过 ListWatch 是从远端控制面里把对应的元数据信息（如 Pod、Node）拉取

142、下来，所以这是一个经典的 Pull 的架构模型。在原生的 K8s 里面有 Kubemaster，还有 Kubelet，在 OCM 里面对标是：Hub Cluster 对标 Kubemaster，Klusterlet 对标 Kubelet，将 K8s 集群当原子的黑箱看成Klusterlet，在运维 OCM 多集群管控面的集群时，其实就是在像运维某个 Node 一样运维单个Kubernetes 群，该架构是天然模仿 Kubernetes 的架构也就是基于 Pull 模型。2、主要概念在了解 Hub 和 Klusterlet 这两个核心的概念后，目前 OCM 支持的核心功能是什么呢？开放模块化多集

143、群管理平台 OCM开放模块化多集群管理平台 OCM如上图是被纳管的集群接入到 OCM 中枢的场景，首先需要规划出中枢集群，在中枢集群里执行命令 Clusteradm join 操作，生成渲染后的指令，将其复制在被纳管集群里执行，这样被纳管的集群就注册成功了。OCM 注册流程是不互信的，需要双向握手，类似于 TCP 握手，不仅需要被纳管的集群向中枢集群发起接管的请求，还需要中枢集群去批准这个请求。四、OCM 近期特性介绍1、插件框架/Addon-Framework插件框架具备以下特性：自由扩展；自由拆卸；持续运维和升级；开放模块化多集群管理平台 OCM开放模块化多集群管理平台 OCM3、多集群资

144、源状态回流下图是多集群资源状态回流的 yaml 文件。4、可扩展的基于评分的多集群调度可扩展的基于评分多集群调度是基于打分机制将不同的应用部署到不同的集群中，适应于多集群细粒度调度、主备容灾等场景。开放模块化多集群管理平台 OCM开放模块化多集群管理平台 OCM如上图，用户在中枢集群里面，需要访问被纳管的集群，Cluster Gateway 会将中枢集群与被纳管集群的进行网络打通，通过 Cluster Gateway 与 Knnoectivity 隧道做原生的集成，屏蔽掉中枢集群与纳管集群网络的复杂性，解决了多集群网络连通性问题。如上图，在 KubeVela1.2 版本中提供了安装 OCM 的

145、快捷入口，OCM 是基于 Pull 指令的架构，可以通过安装插件实现类似流量推送的功能。Nacos2.0 的 K8s 服务发现生态应用及规划Nacos2.0 的 K8s 服务发现生态应用及规划Nacos 诞生于阿里巴巴的五彩石项目，在阿里十年的双十一中成长迭代，解决了应用扩展性和大规模治理的问题。为了帮助更多的公司和企业都能享受到微服务带来的便利并加速数字化转型，在 2018 年阿里巴巴将 Nacos 进行开源。Nacos 在开源的三年多中，用户的使用场景变得越来越复杂，用户规模越来越庞大，基于Nacos1.0 的 HTTP 架构就暴露出来了性能问题和扩展性问题，于是 Nacos 进行了 2.

146、0 的架构升级，引入了 Grpc 这个更高效的通信协议。并对功能架构做了大量的重构和优化。最终使得Nacos2.0 在扩展性和性能上提升了 10 倍。2、Nacos2.0 架构：Nacos2.0 架构图，从上到下依次为接入层、通信协议、连接层、功能层、一次性协议、持久化层a、接入层首先是接入层，接入层为用户使用和接入 Nacos 提供了一个入口，包括一些客户端、OpenAPI、Springboot、阿里巴巴应用框架、Dubbo 的 RPC 框架，也有一些用户（主要是运维人员）通过控制台使用 Nacos。b、通信协议和连接层Nacos2.0 的 K8s 服务发现生态应用及规划Nacos2.0 的

147、 K8s 服务发现生态应用及规划比如 Dubbo、RPC 框架和 SOFA 的 RPC 框架以及应用框架 Spring Cloud Alibaba、还有高可用框架 Sentinel（在运行生态中做一些隔断等操作）。各类网关也用到了 Nacos，比如阿里基于 Nginx 研发的 Tengine 网关、Spring Cloud Gatewa-y、Zuul 都是社区中比较常用的。Nacos 也在和原生社区进行结合，比如 MCP 协议就是进行数据交换、向 Envoy 网关推送配置规则、和应用框架（比如 Dapr 多语言框架）进行结合。二、Nacos 在 K8s 中服务发现的应用实践1、早期的应用实践早

148、期 Nacos 及整个微服务应用体系并没有完全接入到 K8s 的能力体系中（比如服务网格体系），K8s 最初是作为一个容器资源调度的平台来使用的，在这个框架下，所有的应用节点以及Nacos 自身节点会基于 K8s 进行部署，用 K8s 的一些自我恢复以及易于扩容缩容的能力作为资源的调度。Nacos2.0 的 K8s 服务发现生态应用及规划Nacos2.0 的 K8s 服务发现生态应用及规划a、Tengine 不支持热更新Tengine 网关识别基于 Nginx 开发的，不支持动态配置，在配置变更后，需要人工进行 reload(重新加载)操作才能使变更后的配置生效，这就导致了紧急配置不能及时生效

149、，影响研发效率和线上处理故障的效率；b、两层网关成本高流量经过两层网关（Tengine 网关和微服务网关），流量的 RT 会相对变长，而且架构中如果引入一个插件，系统会变得更加复杂，对应的运维成本和服务器成本会增加；c、Fat SDK 模式，服务治理、服务发现等逻辑与 SDK 强耦合，升级困难在 Nacos 架构中，服务发现能力主要是基于应用所依赖的 Nacos SDK 所实现的，这会导致SDK 和应用的耦合度非常高，SDK 一旦出现问题或需要添加一个功能时，就需要应用侧对 SDK进行升级，这个升级过程时间长而且难度大；d、多语言维护成本高，服务治理策略不统一不同公司的业务和系统会使用不同的编

150、程语言，维护不同多语言的 SDK 成本会比较高。不同语言的 SDK 在实现上会有一定的差别，而且版本演进迟缓，这导致有不能统一功能或治理策略，影响到最终的流量治理情况；e、纯粹只拿 K8s 作为调度，应用程度低这个框架是纯粹的将 K8s 作为一个资源调度的工具，并没有使用到 K8s 提供的一些高级能力比如服务网格。2、云原生改造-使用服务网格为了解决以上 5 个问题，就需要对应用和框架进行改造。Nacos2.0 的 K8s 服务发现生态应用及规划Nacos2.0 的 K8s 服务发现生态应用及规划只有全新的应用可以使用，无法和旧体系互通，无法做到平滑迭代；应用元数据需要转移到 Pod 的 la

151、bel 或 annotation 中，维护成本和改造成本高；注册中心如何支持服务网格生态？3、解决方案a、将网关升级优化将两个网关 Tengine 网关和 Envoy 网关进行融合，融合后的网关命名为云原生网关。云原生网关同时具备了微服务网关的能力，能够直接对接 K8s 的所有服务体系，而且具备了一定Tengine 网关的能力、https 证书认证、安全防护的扩展能力。这个云原生网关的优势就是将两个网关合二为一，这样减少了服务器的部署成本。这个云原生网关其实已经在阿里云上提供给广大用户生产使用了（可以搜索“微服务引擎MSE”）。流量经过网关，只需一次转发，这样可以降低整个 RT；另一方面，像应

152、用侧这方面的能力可以通过轻量级 SDK 将逻辑下沉到 Sidecar 中，然后这种轻量级 SDK 只是去获取信息，然后直接和Sidecar 进行交互，这样大部分逻辑下沉到 Sidecar 之后，就会降低多语言的维护成本，不需要很大程度的改造业务代码，可能只需要更换一下 SDK 版本就可以了。Nacos2.0 的 K8s 服务发现生态应用及规划Nacos2.0 的 K8s 服务发现生态应用及规划在阿里的落地实践架构中，中间部分是集团的服务架构，如果新业务或部分应用的灰度节点会接入 MSE 体系，基于 Envoy/Sidecar 方式注册到 Nacos 中，很多正在承载线上业务流量的节点仍然使用旧

153、的 SDK 的体系进行注册和发现。在 Nacos 管理的所有服务列表中，通过 Istio 下发到 Ingress 的 Envoy 网关，实现预期的调用。随着灰度程度扩大，会逐渐将原来的 Fat SDK 模式逐渐全部转化为 Envoy/Sidecar 模式。在右边钉钉的架构模型中，因为钉钉本身是一个新的业务，而且它和集团之间依赖关系比较弱，所以它可以直接使用这种云原生网关加服务网格的架构进行落地，流量经过 MSE 云原生网关，云原生网关中有从 Nacos 网关中获取到的所有服务的信息，就可以通过 Dubbo3 协议转发到各个微服务体系框架中，进行和预期一样的调用。上图左边是蚂蚁的用户流量，它先是

154、经过 Tengine 网关，然后是经过 Mson On Envoy 网关，再路由到它们自身的一个 SOFA Micro Service 体系中进行调用。在跨业务域的调用过程中，云原生网关和 Envoy 网关也能够很好的进行互相调用、互相发现，这样的话也可以解决跨业务域之间的网络安全性能问题，因为只有网关可以进行互相调用和互相发现，微服务体系之间是不能互相调用和发现的。三、Nacos 的 K8s 服务网格应用规划Nacos2.0 的 K8s 服务发现生态应用及规划Nacos2.0 的 K8s 服务发现生态应用及规划Nacos 可以通过一定手段获取到相关信息，可以获取到暴露了哪些接口、输入/输出参

155、数对应的是什么等这类信息，利用这些更细节、更细腻的信息来进行控制面的生成，能够更精细的控制流量的转发（灰度能力），简单来说就是微服务治理能力，这样可以作为原生服务网格能力的增强。所以 Nacos 在未来会做一个控制面的功能，比如说直接实现 xDS 协议、暴露出一系列控制 API等），提供给使用 Nacos 的用户做控制面的管理；同时实现 xDS 协议对控制面的直接对接，也可以解决一部分由于 MCP 协议同步大量服务信息所带来的一些问题。3、Nacos 的服务治理生态其实在整个的实践和落地过程中，将已经运行在微服务产品或微服务体系中的应用迁移到服务网格体系中的代价非常大的，而且这个过程中，对于不

156、同的业务线、不同部门在对接过程中是有很多重复工作的，将微服务体系迁移到微服务网格中同样也会面临这样的问题和阻力。所以我们希望将 Nacos 和其它微服务产品共同解决这个问题，可以共同制定一个微服务治理的标准协议，来实现低成本或无成本的无缝对接；也可以将服务治理的标准协议转化成服务网格协议（比如 xDS 协议），可以快速实现和原生服务网格控制面的对接，让使用微服务产品的用户享受到低成本迁移到服务网格生态的便利，这也是 Nacos 今后发展的主要方向。Nacos2.0 的 K8s 服务发现生态应用及规划240相关链接：Nacos 官方文档：https:/nacos.io/Nacos 源码：https:/ 生态：https:/