OpenKruise 如何实现 K8s 社区首个规模化镜像预热能力

简介: OpenKruise 是阿里云开源的云原生应用自动化管理套件,也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀,是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件,也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

头图.png

作者 | 王思宇(酒祝)
来源 | 阿里巴巴云原生公众号

前言

OpenKruise 是阿里云开源的云原生应用自动化管理套件,也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀,是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件,也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

OpenKruise 在 2021.3.4 发布了最新的 v0.8.0 版本(ChangeLog),其中一个主要变动是新增了 镜像预热 能力。本文由《通过 OpenKruise 实现大规模集群 镜像预热&部署发布加速实践》分享整理为文字,为大家介绍我们所提供的镜像预热能力的需求来源、实现方式以及使用场景。

背景:为什么镜像预热能力是必要的

“镜像” 也算是 Docker 为容器领域带来的一大创新。在 Docker 之前,虽然 Linux 已经提供了 cgroup 隔离,尽管阿里巴巴从 2011 年已经逐渐基于 LXC 开始容器化,但都缺乏镜像这种对运行环境的封装。不过呢,尽管镜像为我们带来了诸多好处,但不可否认在实际场景中我们也面临各种各样拉镜像带来的问题,其中最常见的一点就是拉镜像的耗时。

我们过去听到过很多用户对容器化的期待和认识,比如 “极致弹性”、“秒级扩容”、“高效发布” 等等,但结合 Kubernetes 中一个标准的 Pod 创建过程来看,和用户的期望还是有一定差距的(假设 Pod 中包含 sidecar、app 两个容器):

1.png

正常来说,对于小规模集群中调度、分配/挂载远程盘、分配网络等操作耗时较小,对于大规模集群需要做一定优化,但都还在可控的范围内。然而对于拉镜像的耗时,在大规模弹性的集群中则尤为棘手,即使采用了 P2P 等技术手段来优化,对于一个较大的业务镜像还是可能需要较长的时间来拉取,与用户所期望的扩容、发布速度不符。

而我们如果能做到将 sidecar 容器的镜像、以及业务容器的基础镜像提前在节点上拉取好,则 Pod 创建过程可以大幅缩短,其中拉镜像的耗时甚至能优化 70% 以上:

2.png

而 Kubernetes 自身是没有提供任何面向镜像的操作能力的,围绕 Kubernetes 的生态来看,目前也没有比较成熟的规模化镜像预热产品。这是我们在 OpenKruise 中提供镜像预热的原因,并且这套镜像预热能力已经在阿里巴巴内部的云原生环境大面积落地,在后文的实践中也会简单介绍我们的基本用法。

OpenKruise 是如何实现镜像预热的

OpenKruise 实现镜像预热的原理,要先从它的运行架构看起:

3.png

从 v0.8.0 开始,安装了 Kruise 之后,有两个在 kruise-system 命名空间下的组件:kruise-manager 与 kruise-daemon。前者是一个由 Deployment 部署的中心化组件,一个 kruise-manager 容器(进程)中包含了多个 controller 和 webhook;后者则由 DaemonSet 部署到集群中的节点上,通过与 CRI 交互来绕过 Kubelet 完成一些扩展能力(比如拉取镜像、重启容器等)。

因此,Kruise 会为每个节点(Node)创建一个同名对应的自定义资源:NodeImage,而每个节点的 NodeImage 里写明了在这个节点上需要预热哪些镜像,因此这个节点上的 kruise-daemon 只要按照 NodeImage 来执行镜像的拉取任务即可:

4.png

如上图所示,我们在 NodeImage 中能指定要拉取的镜像名、tag、拉取的策略,比如单次拉取的超时、失败重试次数、任务的 deadline、TTL 时间等等。

有了 NodeImage,我们也就拥有了最基本的镜像预热能力了,不过还不能完全满足大规模场景的预热需求。在一个有 5k 个节点的集群中,要用户去一个个更新 NodeImage 资源来做预热显然是不够友好的。因此,Kruise 还提供了一个更高抽象的自定义资源 ImagePullJob:

5.png

如上图所示,在 ImagePullJob 中用户可以指定一个镜像要在哪些范围的节点上批量做预热,以及这个 job 的拉取策略、生命周期等。一个 ImagePullJob 创建后,会被 kruise-manager 中的 imagepulljob-controller 接收到并处理,将其分解并写入到所有匹配节点的 NodeImage 中,以此来完成规模化的预热。

整体的流程如下:

6.png

而有了镜像预热能力后,我们怎么去使用它,或者说什么场景下需要来使用呢?接下来我们介绍下镜像预热在阿里巴巴中的几种常见使用方式。

常见的镜像预热使用方式有哪些

1. 基础镜像 – 集群维度预热

最常见的预热场景,是在整个集群维度持续预热一些基础镜像:

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:name: base-image-job
spec:image: xxx/base-image:latestparallelism: 10completionPolicy:type: NeverpullPolicy:backoffLimit: 3timeoutSeconds: 300

如上述 ImagePullJob 有几个特征:

  1. 不配置 selector 规则,即默认整个集群维度预热

    1. 存量的节点上统一预热
    2. 后续新增(导入)的节点上也会立即自动做预热
  2. 采用 Never 的 completionPolicy 策略来长期运行

    1. Never 策略表明这个 job 持续做预热,不会结束(除非被删除)
    2. Never 策略下,ImagePullJob 每隔 24h 左右会触发在所有匹配的节点上重试拉取一次,也就是每天都会确保一次镜像存在

根据我们的经验,一个集群中预热基础镜像的 ImagePullJob 在 10~30 个左右,具体视集群以及业务场景而定。

2. sidecar 镜像 – 集群维度预热

我们同样也可以对一些 sidecar 的镜像做预热,尤其是那些基本上每个业务 Pod 中都会带有的基础 sidecar:

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:name: sidecar-image-job
spec:image: xxx/sidecar-image:latestparallelism: 20completionPolicy:type: AlwaysactiveDeadlineSeconds: 1800ttlSecondsAfterFinished: 300pullPolicy:backoffLimit: 3timeoutSeconds: 300

如上述 ImagePullJob 有几个特征:

  1. 不配置 selector,默认整个集群维度预热,这一点与基础镜像类似
  2. 采用 Always 策略一次性预热

    1. 所有节点做一次预热
    2. 整个 job 预热超时时间 30min
    3. job 完成后过 5min 自动删除

当然,这里的 sidecar 预热也可以配置为 Never 策略,视场景而定。以我们的经验来看,尤其在 sidecar 做版本迭代、镜像升级的时候,提前做一次规模化的镜像预热,可以大幅提升后续 Pod 扩容、发布的速度。

3. 特殊业务镜像 – 资源池维度预热

对于一些多租的 Kubernetes 集群中会存在多个不同的业务资源池,其中可能需要将一些特定的业务镜像按资源池维度来预热:

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:name: serverless-job
spec:image: xxx/serverless-image:latestparallelism: 10completionPolicy:type: NeverpullPolicy:backoffLimit: 3timeoutSeconds: 300selector:matchLabels:resource-pool: serverless

如上述 ImagePullJob 有几个特征:

  1. 采用 Never 策略长期预热
  2. 指定 selector 预热范围,是匹配 resource-pool=serverless 标签的节点

当然,这里只是以资源池为例,用户可以根据自身的场景来定义在哪些节点上预热某种镜像。

版本前瞻:原地升级与预热的结合

最后,再来介绍下 OpenKruise 的下个版本(v0.9.0)中,我们会基于当前的镜像预热实现怎样的增强能力呢?

之前对 OpenKruise 了解过的同学一定知道,我们提供的一大特性就是 “原地升级”,即打破了 Kubernetes 原生 workload 发布时必须将 Pod 删除、重建的模式,支持在原 Pod 上只更新其中某个容器的镜像。对原地升级原理感兴趣的同学可以读这篇文章:《揭秘:如何为 Kubernetes 实现原地升级?》。

由于原地升级避免了 Pod 删除、重建的过程,它本身已经能为我们带来了如下的好处:

  • 节省了调度的耗时,Pod 的位置、资源都不发生变化
  • 节省了分配网络的耗时,Pod 还使用原有的 IP
  • 节省了分配、挂载远程盘的耗时,Pod 还使用原有的 PV(且都是已经在 Node 上挂载好的)
  • 节省了大部分拉取镜像的耗时,因为节点上已经存在了应用的旧镜像,当拉取新版本镜像时只需要下载少数的几层 layer
  • 原地升级 Pod 中某个容器时,其他容器保持正常运行,网络、存储均不受影响

其中,“节省了大部分拉取镜像的耗时” 后,只需要下载新镜像上层的部分 layer 即可。而我们有没有可能把这个镜像拉取时间彻底优化掉呢?答案是肯定的。

7.png

如上图所示,在下个版本中 OpenKruise 的 CloneSet 将支持发布过程自动镜像预热。当用户还在灰度升级第一批 Pod 的时候,Kruise 会提前在后续 Pod 所在节点上把新版本的镜像预热好。这样一来,在后续批次的 Pod 做原地升级时候,新镜像都已经在节点上准备好了,也就节省了真正发布过程中的拉镜像耗时。

当然,这种 “发布+预热” 的模式也只适用于 OpenKruise 的原地升级场景。对于原生 workload 如 Deployment 而言,由于发布时 Pod 是新建出来的,我们无法提前预知到它会被调度到的节点,自然也就没办法提前把镜像预热好了。

原文链接

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

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

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

相关文章

云原生时代,底层性能如何调优?

作者 | 宋慧出品 | CSDN云计算(ID:CSDNcloud)现在,当企业提及数字化转型,上云用云的话题时,言必谈及云原生。在云原生吞噬一切的口号下,云原生被频繁、高热度的讨论之后,其真正的价值…

4米乘以12米CAD图_孙吴镀锌钢管大棚骨架图片4-12米可定尺

孙吴镀锌钢管大棚骨架图片4-12米可定尺泽沃温室大棚管厂家是集生产销售为一体,生产经销大棚管、大棚钢管、热镀锌大棚管、大棚镀锌管、热镀锌带管。温室大棚产品广泛用于温室工程建设、大棚蔬菜基地建设、水果、水稻育秧、药材、种植、畜牧养殖等温室大棚骨架等行业…

Raft成员变更的工程实践

简介: 成员变更是一致性系统实现绕不开的难题,对于提升运维能力以及服务可用性都有很大的帮助。 本文从Raft成员变更理论出发,介绍了Raft成员变更和单步成员变更的问题,其中包括Raft著名的Bug。 对于Raft成员变更的工程实现上需要…

No.1-Apache IoTDB 随笔 - Time Series DBMS 综述

简介: 这是一篇无法一口气读完的、文字过万[正文字数14390]的长文,这是一个无法中途不上厕所就看完的、关于时序数据库的视频[时长111分钟]分享的文字整理.. 大家好,很开心能够和大家一起交流时序数据库的相关的内容 首先还是简单自我介绍一…

overflowhidden把内容遮住了怎么办_图片有水印怎么办?不用PS,有这4招就够了

大家好,我是热衷解决问题的秋小叶!俗话说,文不如表,表不如图!图片是我们在做 PPT 时经常会使用到的高频元素。阿文老师曾经说过:但是,在没有接触到正确的搜图方法前,我们往往会在搜索…

谷歌云试图抢占SAP软件云市场;企业上云迎来“黄金时代”;IBM和SAP帮助金融机构加快采用云技术……...

NEWS本周新闻回顾调查表明80%的企业在云计算方面超支云计算优化服务商Virtana公司委托研究机构Arlington Research公司对350位云计算决策者进行的这项研究发现,82%的受访者表示其所在的公司在云计算方面的支出远远超过他们的需要。Market Research Future&#xff1…

Java设计模式-桥接模式

目录 一、手机操作问题 二、传统方法 三、基本介绍 四、原理类图 五、使用桥接模式解决手机问题 一、手机操作问题 现在对不同手机类型的不同品牌实现操作编程( 比如 : 开机、关机、上网,打电话等) , 如图: 二、传统方法 传统方案解决手机操作问题分…

Elasticsearch生态技术峰会 | Elasticsearch在清博大数据的应用与实践

简介: 开源最大的特征就是开放性,云生态则让开源技术更具开放性与创造性,Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际,我们邀请业界资深人士相聚云端,共话云上Elasticsearch生态与技术…

Elasticsearch生态技术峰会 | Elasticsearch在企查查的应用实践

简介: 开源最大的特征就是开放性,云生态则让开源技术更具开放性与创造性,Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际,我们邀请业界资深人士相聚云端,共话云上Elasticsearch生态与技术…

漫话:为什么计算机用补码存储数据?

作者 | 漫话编程来源 | 漫话编程我们知道,计算机只认识0和1,现实世界中的内容,无论是文字、音频、视频等等想要通过计算机存储、计算或者展示,都需要转换二进制。就像你刚刚唱的旋律,想要存储在计算机中也是要转成二进…

cad多个窗口并排显示_你早该这么做!并排查看Excel工作表其实一个小动作就搞定!...

特别福利:私信发送关键词【福利】,年度最全Office办公资源等你免费领哟~很多人都知道,有时在屏幕上并排查看起两个文件的内容,是一项非常顺畅和方便的操作——省去不少在不同窗口间来回切换的时间!当然,对于…

数据仓库如何实现湖仓一体数据分析?

简介: 随着云计算的普及和数据分析需求的扩大,数据湖数据仓库的湖仓一体分析能力成为下一代数据分析系统的核心能力。相对于数据仓库,数据湖在成本、灵活性、多源数据分析等多方面,都有着非常明显的优势。IDC发布的十项2021年中国…

Java应用全链路启动速度提升至15s,阿里云SAE能力再升级

简介: Java 作为一门面向对象编程语言,在性能方面的卓越表现独树一帜。但在高性能的背后,Java 的启动性能差也令人印象深刻,大家印象中的 Java 笨重、缓慢的印象也大多来源于此,高性能和快启动速度似乎有一些相悖。 近…

到底什么是“无源物联网”?

作者 | 小枣君来源 | 鲜枣课堂继Cat.1之后,2021年的物联网行业,又“喜提”了一个新的“风口”。这个“风口”的名字,叫做“无源物联网”。无源物联网,到底是个啥东东?它和现有的物联网技术之间,有什么区别&…

Gartner魔力象限到底有何“魔力”?

简介: Gartner魔力象限到底有何“魔力”?近日,Gartner发布了一系列最新魔力象限报告,在IT圈掀起了阵阵“龙卷风”,谁跻身全球第一阵营,谁跌出“领导者”象限,权威定调,众说纷纭&…

K8s 原生 Serverless 实践:ASK 与 Knative

简介: K8s 处在一个承上启下的位置,云原生用户使用 K8s 的目的是为了交付和管理应用,也包括灰度发布、扩容缩容等。但是对用户来说,实现这些能力,通过直接操作 K8s API 难免有些复杂。另外节省资源成本和弹性对于用户来…

react安装_前端大牛进阶---gt;React必会教程

一、背景介绍01React 起源于 Facebook 的内部项目,因为该公司对市场上所有 JavaScript MVC 框架,都不满意,就决定自己写一套,用来架设 Instagram 的网站。做出来以后,发现这套东西很好用,就在2013年5月开源…

透过 3.0 Preview 看 Dubbo 的云原生变革

简介: 做过微服务开发的开发者相信对 Dubbo 都不陌生,Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内,Dubbo 的多语言版本在这两年呈现了良好的发展势头,其中&#xff0…

扩展云存储边界,阿里云推出全球首个云定义存储产品

云计算正带来一场消除线上线下存储边界的革命。 9月22日,阿里云宣布云存储服务全面升级,包括性能大幅提升300%、时延降低70%的ESSD云盘;可兼容HDFS的数据湖存储OSS,同时推出一款全新产品“云定义存储”(Cloud Defined…

Go Mysql Driver 集成 Seata-Golang 解决分布式事务问题

简介: 2020 年 4 月,我们开始尝试实现 go 语言的分布式事务框架 Seata-Golang。众所周知,Seata AT 模式以无业务代码侵入的特点,被广大开发者推崇。Java 版 Seata AT 模式通过对 DataSource 数据源进行代理,在 sql 语句…