更灵活的边缘云原生运维:OpenYurt 单元化部署新增 Patch 特性

简介: 在正文开始之前,我们先回顾一下单元化部署的概念和设计理念。在边缘计算场景下,计算节点具有很明显的地域分布属性,相同的应用可能需要部署在不同地域下的计算节点上。

头图.png

作者 | 张杰(冰羽)
来源 | 阿里巴巴云原生公众号

背景

在正文开始之前,我们先回顾一下单元化部署的概念和设计理念。在边缘计算场景下,计算节点具有很明显的地域分布属性,相同的应用可能需要部署在不同地域下的计算节点上。以 Deployment 为例,如下图所示,传统的做法是先将相同地域的计算节点设置成相同的标签,然后创建多个 Deployment,不同 Deployment 通过 NodeSelectors 选定不同的标签,从而实现将相同的应用部署到不同地域的需求。

1.png

但是随着地域分布越来越多,使得运维变得越来越复杂,具体表现在以下几个方面:

  • 当镜像版本升级,需要修改大量相关的 Deployment 的镜像版本配置。
  • 需要自定义 Deployment 的命名规范来表明相同的应用。
  • 缺少一个更高的视角对这些 Deployment 进行统一管理和运维。运维的复杂性随着应用和地域分布增多出现线性增长。

基于以上需求和问题,openyurt 的 yurt-app-manager 组件提供的单元化部署(UnitedDeployment)通过更上层次的抽象,对这些子的 Deployment 进行统一管理:自动创建/更新/删除,从而大幅简化了运维复杂度的问题。

yurt-app-manager 组件: 
https://github.com/openyurtio/yurt-app-manager

如下图所示:

2.png

单元化部署(UnitedDeployment)对这些 Workload 进行了更高层次的抽象,UnitedDeployment 包含两个主要配置:WorkloadTemplate 和 Pools。workloadTemplate 格式可以是Deployment 也可以是Statefulset。Pools 是一个列表,每个列表都有一个 Pool 的配置,每个 Pool 都有它的 name、replicas 和 nodeSelector 配置。通过 nodeSelector 可以选择一组机器, 因此在边缘场景下 Pool 我们可以简单的认为它代表了某个地域下的一组机器。使用WorkloadTemplate + Pools 的定义,我们可以很容易的将一个 Deployment 或者 Statefulset 应用分发到不同的地域中去。

下面是一个具体的 UnitedDeployment 例子:

apiVersion: apps.openyurt.io/v1alpha1
kind: UnitedDeployment
metadata:name: testnamespace: default
spec:selector:matchLabels:app: testworkloadTemplate:deploymentTemplate:metadata:labels:app: testspec:selector:matchLabels:app: testtemplate:metadata:labels:app: testspec:containers:- image: nginx:1.18.0imagePullPolicy: Alwaysname: nginxtopology:pools:- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1- name: hangzhounodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- hangzhoureplicas: 2

UnitedDeployment 控制器的具体逻辑如下:

用户定义了一个 UnitedDeployment CR , CR 里定义了一个 DeploymentTemplate 和两个 Pool。

  • 其中 DeploymentTemplate 格式为一个 Deployment 格式定义,本例子中使用的 Image 为 nginx:1.18.0
  • Pool1 的 name 为 beijing, replicas=1,nodeSelector 为 apps.openyurt.io/nodepool=beijing。代表 UnitedDeployment 控制器将要创建一个子的 Deployment,replicas 为 1,nodeSelector 为 apps.openyurt.io/nodepool=beijing,其他的配置继承自 DeploymentTemplate 配置。
  • Pool2 的 name 为 hangzhou,replicas=2, nodeSelector 为 apps.openyurt.io/nodepool=hangzhou,代表 UnitedDeployment 控制器将要创建一个子的 Deployment,replicas 为 2,nodeSelector 为 apps.openyurt.io/nodepool=hangzhou,其他的配置继承自 DeploymentTemplate 配置。

UnitedDeployment 控制器检测到 name 为 test 的 UnitedDeployment CR 实例被创建后,会首先根据 DeploymentTemplate 里的配置生成一个 Deployment 的模板对象,根据 Pool1 和 Pool2 的配置和 Deployment 的模板对象,分别生成 name 前缀为 test-hangzhou- 和 test-beijing- 的两个 deployment 资源对象,这两个 Deployment 资源对象有自己的 nodeselector 和 replica 配置。这样通过使用 workloadTemplate+Pools 的形式,可以将 workload 分发到不同的地域,而无需用户维护大量的 Deployment 资源。

UnitedDeployment 所解决的问题

UnitedDeployment 通过一个单元化部署实例就可以自动维护多个 Deployment 或者 Statefulset 资源,每个 Deployment 或者 Statefulset 资源都遵循统一的命名规范。同时还能实现 Name、NodeSelectors 和 Replicas 等的差异化配置。能极大地简化用户在边缘场景下的运维复杂度。

新的需求

UnitedDeployment 能满足用户的大部分需求,但是在我们进行推广和客户落地以及在与社区同学讨论的过程中,逐渐发现在一些特殊场景下,UnitedDeployment 提供的功能还显得有点不足,例如如下场景:

  • 应用镜像升级时候,用户计划先在在某个节点池中做验证,如果验证成功,再在所有节点池中全量更新发布。
  • 为了加快镜像拉取速度,用户可能在不同节点池中搭建自己的私有镜像仓库,因此同一个应用在每个节点池下的镜像名会不一样。
  • 不同的节点池下服务器数量,规格,以及业务访问压力不一致,因此同一个应用在不同节点池下 pod 的 cpu,内存等配置会不一样。
  • 同一个应用在不同节点池下可能会使用不同的 configmap 资源。

这些需求促使了 UnitedDeployment 需要提供针对每个 Pool 做一些个性化配置的功能,允许用户根据不同节点池下的实际情况做一些个性化的配置,比如镜像、pod 的 request 和 limit 等等。为了最大化的提供灵活性,经过讨论我们决定在 Pool 里增加 Patch 的字段,允许用户自定义 Patch 内容,但是需要遵循Kubernetes 的 strategic merge patch规范,其行为与我们常用的 kubectl patch 有点类似。

pool 里新增 patch,示例如下:

    pools:- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1          patch:spec:template:spec:containers:- image: nginx:1.19.3name: nginx

patch 里定义的内容,需要遵循Kubernetes 的 strategic merge patch 规范, 如果用过 kubectl patch 的同学就很容易的知道 patch 内容如何书写,具体可以参照使用 kubectl patch 更新 Kubernetest api 对象。
接下来我们演示一下 UnitedDeployment patch 的使用。

特性演示

1. 环境准备

  • 提供一个 K8s 集群或者 OpenYurt 集群,集群里至少 2 台节点。一台节点 label 为:apps.openyurt.io/nodepool=beiing, 另一台节点 label 为:apps.openyurt.io/nodepool=hangzhou。
  • 集群里需要安装 yurt-app-manager 组件。

yurt-app-manager 组件: 
https://github.com/openyurtio/yurt-app-manager

2. 创建 UnitedDeployment 实例

cat <<EOF | kubectl apply -f -apiVersion: apps.openyurt.io/v1alpha1
kind: UnitedDeployment
metadata:name: testnamespace: default
spec:selector:matchLabels:app: testworkloadTemplate:deploymentTemplate:metadata:labels:app: testspec:selector:matchLabels:app: testtemplate:metadata:labels:app: testspec:containers:- image: nginx:1.18.0imagePullPolicy: Alwaysname: nginxtopology:pools:- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1- name: hangzhounodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- hangzhoureplicas: 2              
EOF

实例中 workloadTemplate 使用了 Deployment 模板, 其中 name 为 nginx 的镜像为 nginx:1.18.0。同时拓扑里定义了两个 pool:beijing 和 hangzhou,replicas 数目分别为 1 和 2。

3. 查看 UnitedDeployment 创建的 Deployment

# kubectl get deployments
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
test-beijing-rk8g8    1/1     1            1           6m4s
test-hangzhou-kfhvj   2/2     2            2           6m4s

可以看到 yurt-app-manager 控制器创建了两个 Deployment,分布对应 beijing 和 hangzhou 的 pool,Deployment 的命名规范以 {UnitedDeployment name}-{pool name} 为前缀。查看这两个 Deployment 配置我们可以发现,Replicas 和 Nodeselector 继承了对应的每个 Pool 的配置,而其他的配置则继承了 workloadTemplate 模板的配置。

4. 查看对应创建的 Pod

# kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
test-beijing-rk8g8-5df688fbc5-ssffj    1/1     Running   0          3m36s
test-hangzhou-kfhvj-86d7c64899-2fqdj   1/1     Running   0          3m36s
test-hangzhou-kfhvj-86d7c64899-8vxqk   1/1     Running   0          3m36s

可以看到创建了 1 个 name 前缀为 test-beijing 的 pod,2 个 name 前缀为 test-hangzhou 的 pod。

5. 使用 patch 能力做差异化配置

使用 kubectl edit ud test  命令为 beijing 的 pool 增加 patch 字段,patch 里的内容是修改 name 为 nginx 的 container 镜像版本为:nginx:1.19.3。

格式如下:

    - name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1patch:spec:template:spec:containers:- image: nginx:1.19.3name: nginx

6. 查看 Deploy 实例配置

重新查看前缀为 test-beijing 的 Deployment,可以看到 container 的镜像配置已经变成了 1.19.3。

 kubectl get deployments  test-beijing-rk8g8 -o yaml

总结

通过 UnitedDeployment 的 workloadTemplate + Pools 的形式,可以将 workload 通过继承的模板的方式快速分发到不同的地域。在加上 Pool 的 patch 能力,在继承模板的配置的同时还能提供更灵活的差异化配置,基本上已经可以满足大部分客户在边缘场景下特殊的需求。

原文链接

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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/513561.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Gartner:2022年全球IT支出将超4万亿美元,软件增速最高

编辑 | 宋慧 供稿 | Gartner 根据Gartner的最新预测&#xff0c;2022年全球IT支出预计将达到4.5万亿美元&#xff0c;相比2021年增长5.5%。 Gartner杰出研究副总裁John-David Lovelock表示&#xff1a;“越来越多的企业将构建新技术和软件&#xff0c;而不是购买和部署它们&am…

Flink 实时计算在微博的应用

简介&#xff1a; 微博通过将 Flink 实时流计算框架跟业务场景相结合&#xff0c;在平台化、服务化方面做了很大的工作&#xff0c;在开发效率、稳定性方面也做了很多优化。我们通过模块化设计和平台化开发&#xff0c;提高开发效率。 微博机器学习研发中心数据计算负责人&…

移动云帮我养出了一片致富鱼塘

“通过U鱼智慧管理平台&#xff0c;水产养殖由‘人治’转变为‘智治’&#xff0c;养得舒心、卖得放心、吃得安心。”广东省渔业种质保护中心相关负责人表示。准确研究&#xff0c;提升科学养殖水平广东省渔业种质保护中心坐落于广州市南沙区东涌镇&#xff0c;占地580亩&#…

sketch里的ios控件_使用Sketch建立Design System

一、 有关Design System之前的文章《使用Adobe XD建立Design System》中介绍了什么是Design System&#xff0c;它有什么用&#xff0c;在设计的哪个阶段使用以及如何用Adobe XD来搭建。这篇文章主要侧重在UI风格已确定的设计后期&#xff0c;用Sketch工具来搭建一个Design Sys…

论好文章和烂文章

简介&#xff1a; 我们为何写作&#xff1f;对于许多技术同学来说&#xff0c;写作是一件比写代码困难许多的事情&#xff0c;和电脑相顾无言数小时&#xff0c;发现自己写不出什么像样的东西来&#xff0c;着实不是一种很好的体验。 作者 | 许晓斌 来源 | 阿里巴巴云原生公众号…

好代码实践:基于Redis的轻量级分布式均衡消费队列

简介&#xff1a; 好代码&#xff0c;给人第一个印象的感觉&#xff0c;就像一篇好文章一样&#xff0c;读起来朗朗上口。不同的文章有不同的风格体裁&#xff0c;不同的代码也有不同的编程风格要求。Python有严格的缩进&#xff0c;像诗歌一样工整对仗&#xff1b;C语言面向过…

浅析低功耗广域网及在智慧城市中的应用

作者 | 沈建华、冷咏雪根据知名物联网分析机构IoT Analytics预测&#xff0c;到2025年&#xff0c;物联网连接数将达到非物联网连接数的3倍。低功耗广域网(LPWAN)作为物联网连接的核心基础设施&#xff0c;其业务特点是发送数据极小&#xff0c;并且为了维持电池供电设备的长时…

rocketmq怎么保证数据不会重复_RocketMQ保证信息有序性和防止重复

分布式开放消息系统(RocketMQ)的原理与实践分布式消息系统做为实现分布式系统可扩展、可伸缩性的关键组件&#xff0c;须要具备高吞吐量、高可用等特色。而谈到消息系统的设计&#xff0c;就回避不了两个问题&#xff1a;java消息的顺序问题消息的重复问题RocketMQ做为阿里开源…

云效Codeup代码评审中的代码协同

简介&#xff1a; 云效 Codeup 汇集了阿里巴巴最新的代码托管、代码协同技术&#xff0c;希望能够造福更多中国和世界的开发者。 大神说&#xff1a;“Show me the code”&#xff0c;于是就有了代码评审。 “Talk is cheap. Show me the code.” ——Linus Torvalds, founder …

代码安全无忧—云效Codeup代码加密技术发展之路

简介&#xff1a; 从代码服务及代码安全角度出发&#xff0c;看看云效代码加密技术如何解决这一问题 代码数据存在云端&#xff0c;如何保障它的安全&#xff1f; 部分企业管理者对于云端代码托管存在一丝担心&#xff1a;我的代码存在云端服务器&#xff0c;会不会被泄露&…

杀死 Oculus ,Facebook 改名 Meta ,是押注元宇宙还是“金蝉脱壳”?

整理 | 祝涛出品 | CSDN&#xff08;ID&#xff1a;CSDNnews&#xff09;美东时间10月28日周四&#xff0c;在名为Facebook Connect的年度大会上&#xff0c;Facebook宣布&#xff0c;Facebook将公司名称更改为“Meta”&#xff0c;这个新名字反映了该公司在社交媒体之外的雄心…

java sdp_[java,SDP] java 7 SDP 技术/Socket Direct Protocol 2

With Java 7 and Sockets Direct Protocol , Java Now does RDMA ( Remote Direct Memory Access)有了 SDP 技术支持之后的 Java 7 已经开始逐步实现 RDMA 技术 (远程内存直接访问)RDMA is Remote Dynamic Memory Accesss -- which is a way of moving application buffers bet…

百信银行基于 Apache Hudi 实时数据湖演进方案

简介&#xff1a; 本文介绍了百信银行实时计算平台的建设情况&#xff0c;实时数据湖构建在 Hudi 上的方案和实践方法&#xff0c;以及实时计算平台集成 Hudi 和使用 Hudi 的方式。 本文介绍了百信银行实时计算平台的建设情况&#xff0c;实时数据湖构建在 Hudi 上的方案和实践…

如何做一场高质量的分享

简介&#xff1a; 每个人在分享前都应该先问自己这么一个问题&#xff0c;我为什么要分享&#xff1f;我觉得分享就一个最纯粹的原因&#xff0c;就是“我有一些知识&#xff0c;是别人不知道的&#xff0c;但对他人会有所帮助&#xff0c;所以我想分享给大家”。 作者 | 阿相 …

RTE2021,实时互动技术的进化与蝶变

10 月 22—23 日&#xff0c;由声网 Agora 主办的 RTE2021 实时互联网大会在北京圆满落幕。大会以“万象频道”为主题&#xff0c;带来了 20 余场实时互联网全生态线下论坛及活动、近百场的精彩演讲分享&#xff0c;覆盖技术开发、行业观察、创业投资、趋势洞察等多维度话题。同…

Java编程技巧之单元测试用例编写流程

简介&#xff1a; 立足于“如何来编写单元测试用例”&#xff0c;让大家“有章可循”&#xff0c;快速编写出单元测试用例。 作者 | 常意 来源 | 阿里技术公众号 温馨提示&#xff1a;本文较长&#xff0c;同学们可收藏后再看 :)前言 清代杰出思想家章学诚有一句名言&#xff…

KubeVela + KEDA:为应用带来“与生俱来”的弹性伸缩能力

简介&#xff1a; 在这篇博文中&#xff0c;我们将简要解释需要考虑的领域&#xff0c;KEDA 如何使应用自动伸缩变得简单&#xff0c;以及为什么阿里云企业分布式应用服务&#xff08;EDAS&#xff09;在 KEDA 上完全标准化。 联合作者 | Yan Xun&#xff0c;阿里云 EDAS 团队…

mysql行转列函数_一个小知识点-Hive行转列实现Pivot

前言传统关系型数据库中&#xff0c;无论是Oracle(11g之后)还是SQLserver(2005之后)&#xff0c;都自带了Pivot函数实现行转列功能&#xff0c;本文主要讲述在Hive中实现行转列的两种方式。传统数据库方式这种方式是借鉴在Oracle或者SQLserver在支持Pivot函数之前实现行转列的方…

安全之心:一文读懂可信计算

简介&#xff1a; 信 or 不信&#xff0c;这是个问题 可信计算 TC &#xff08;Trusted Computing&#xff09; 业界新宠&#xff0c;越来越被高频提到 本质是创造可信执行环境的芯片级安全防护方案 然而&#xff0c;江湖流传 TA 的传说 却鲜少有人见过真身 阿里云作为亚太区最…

国内顶级AI赛事再启程,第三届“中国人工智能大赛”聚焦算法治理、深度伪造与网络安全

本届大赛赛题分为算法治理、深度伪造和网络安全三大方向的七大赛题&#xff0c;分别是&#xff1a;过滤算法鲁棒性、深度伪造视频检测、深度伪造视频生成方法识别、基于人工智能的音视频合成比赛、说话人无关的音频深度伪造检测识别、说话人相关的音频深度伪造检测识别、Webshe…