小榄网站开发,宁波怎样优化关键词,定制版网站建设费用,贵州省住房和城乡建设厅网站首页简介#xff1a; OpenKruise 是阿里云开源的云原生应用自动化管理套件#xff0c;也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀#xff0c;是阿里内部生产环境大规模应用的基于 Kubernetes 之…简介 OpenKruise 是阿里云开源的云原生应用自动化管理套件也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。 作者 | 王思宇酒祝 来源 | 阿里巴巴云原生公众号
前言
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 两个容器 正常来说对于小规模集群中调度、分配/挂载远程盘、分配网络等操作耗时较小对于大规模集群需要做一定优化但都还在可控的范围内。然而对于拉镜像的耗时在大规模弹性的集群中则尤为棘手即使采用了 P2P 等技术手段来优化对于一个较大的业务镜像还是可能需要较长的时间来拉取与用户所期望的扩容、发布速度不符。
而我们如果能做到将 sidecar 容器的镜像、以及业务容器的基础镜像提前在节点上拉取好则 Pod 创建过程可以大幅缩短其中拉镜像的耗时甚至能优化 70% 以上 而 Kubernetes 自身是没有提供任何面向镜像的操作能力的围绕 Kubernetes 的生态来看目前也没有比较成熟的规模化镜像预热产品。这是我们在 OpenKruise 中提供镜像预热的原因并且这套镜像预热能力已经在阿里巴巴内部的云原生环境大面积落地在后文的实践中也会简单介绍我们的基本用法。
OpenKruise 是如何实现镜像预热的
OpenKruise 实现镜像预热的原理要先从它的运行架构看起 从 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 来执行镜像的拉取任务即可 如上图所示我们在 NodeImage 中能指定要拉取的镜像名、tag、拉取的策略比如单次拉取的超时、失败重试次数、任务的 deadline、TTL 时间等等。
有了 NodeImage我们也就拥有了最基本的镜像预热能力了不过还不能完全满足大规模场景的预热需求。在一个有 5k 个节点的集群中要用户去一个个更新 NodeImage 资源来做预热显然是不够友好的。因此Kruise 还提供了一个更高抽象的自定义资源 ImagePullJob 如上图所示在 ImagePullJob 中用户可以指定一个镜像要在哪些范围的节点上批量做预热以及这个 job 的拉取策略、生命周期等。一个 ImagePullJob 创建后会被 kruise-manager 中的 imagepulljob-controller 接收到并处理将其分解并写入到所有匹配节点的 NodeImage 中以此来完成规模化的预热。
整体的流程如下 而有了镜像预热能力后我们怎么去使用它或者说什么场景下需要来使用呢接下来我们介绍下镜像预热在阿里巴巴中的几种常见使用方式。
常见的镜像预热使用方式有哪些
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 有几个特征 不配置 selector 规则即默认整个集群维度预热 存量的节点上统一预热后续新增导入的节点上也会立即自动做预热 采用 Never 的 completionPolicy 策略来长期运行 Never 策略表明这个 job 持续做预热不会结束除非被删除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 有几个特征
不配置 selector默认整个集群维度预热这一点与基础镜像类似 采用 Always 策略一次性预热 所有节点做一次预热整个 job 预热超时时间 30minjob 完成后过 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 有几个特征
采用 Never 策略长期预热指定 selector 预热范围是匹配 resource-poolserverless 标签的节点
当然这里只是以资源池为例用户可以根据自身的场景来定义在哪些节点上预热某种镜像。
版本前瞻原地升级与预热的结合
最后再来介绍下 OpenKruise 的下个版本v0.9.0中我们会基于当前的镜像预热实现怎样的增强能力呢
之前对 OpenKruise 了解过的同学一定知道我们提供的一大特性就是 “原地升级”即打破了 Kubernetes 原生 workload 发布时必须将 Pod 删除、重建的模式支持在原 Pod 上只更新其中某个容器的镜像。对原地升级原理感兴趣的同学可以读这篇文章《揭秘如何为 Kubernetes 实现原地升级》。
由于原地升级避免了 Pod 删除、重建的过程它本身已经能为我们带来了如下的好处
节省了调度的耗时Pod 的位置、资源都不发生变化节省了分配网络的耗时Pod 还使用原有的 IP节省了分配、挂载远程盘的耗时Pod 还使用原有的 PV且都是已经在 Node 上挂载好的节省了大部分拉取镜像的耗时因为节点上已经存在了应用的旧镜像当拉取新版本镜像时只需要下载少数的几层 layer原地升级 Pod 中某个容器时其他容器保持正常运行网络、存储均不受影响
其中“节省了大部分拉取镜像的耗时” 后只需要下载新镜像上层的部分 layer 即可。而我们有没有可能把这个镜像拉取时间彻底优化掉呢答案是肯定的。 如上图所示在下个版本中 OpenKruise 的 CloneSet 将支持发布过程自动镜像预热。当用户还在灰度升级第一批 Pod 的时候Kruise 会提前在后续 Pod 所在节点上把新版本的镜像预热好。这样一来在后续批次的 Pod 做原地升级时候新镜像都已经在节点上准备好了也就节省了真正发布过程中的拉镜像耗时。
当然这种 “发布预热” 的模式也只适用于 OpenKruise 的原地升级场景。对于原生 workload 如 Deployment 而言由于发布时 Pod 是新建出来的我们无法提前预知到它会被调度到的节点自然也就没办法提前把镜像预热好了。
原文链接
本文为阿里云原创内容未经允许不得转载。
