外贸网站seo优化,老区建设网站,云霄网站建设,近期时事热点作者 | 王思宇#xff08;酒祝#xff09; 阿里云技术专家
参与阿里巴巴云原生文末留言互动#xff0c;即有机会获得赠书福利及作者答疑#xff01;
概念介绍
原地升级一词中#xff0c;“升级”不难理解#xff0c;是将应用实例的版本由旧版替换为新版。那么如何结合…
作者 | 王思宇酒祝 阿里云技术专家
参与阿里巴巴云原生文末留言互动即有机会获得赠书福利及作者答疑
概念介绍
原地升级一词中“升级”不难理解是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢
我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用包括 foo、bar 两个容器在 Pod 中。其中foo 容器第一次部署时用的镜像版本是 v1我们需要将其升级为 v2 版本镜像该怎么做呢
如果这个应用使用 Deployment 部署那么升级过程中 Deployment 会触发新版本 ReplicaSet 创建 Pod并删除旧版本 Pod。如下图所示在本次升级过程中原 Pod 对象被删除一个新 Pod 对象被创建。新 Pod 被调度到另一个 Node 上分配到一个新的 IP并把 foo、bar 两个容器在这个 Node 上重新拉取镜像、启动容器。
如果这个应该使用 StatefulSet 部署那么升级过程中 StatefulSet 会先删除旧 Pod 对象等删除完成后用同样的名字在创建一个新的 Pod 对象。如下图所示值得注意的是尽管新旧两个 Pod 名字都叫 pod-0但其实是两个完全不同的 Pod 对象uid也变了。StatefulSet 等到原先的 pod-0 对象完全从 Kubernetes 集群中被删除后才会提交创建一个新的 pod-0 对象。而这个新的 Pod 也会被重新调度、分配IP、拉镜像、启动容器。
而所谓原地升级模式就是在应用升级过程中避免将整个 Pod 对象删除、新建而是基于原有的 Pod 对象升级其中某一个或多个容器的镜像版本在原地升级的过程中我们仅仅更新了原 Pod 对象中 foo 容器的 image 字段来触发 foo 容器升级到新版本。而不管是 Pod 对象还是 Node、IP 都没有发生变化甚至 foo 容器升级的过程中 bar 容器还一直处于运行状态。
总结这种只更新 Pod 中某一个或多个容器版本、而不影响整个 Pod 对象、其余容器的升级方式被我们称为 Kubernetes 中的原地升级。
收益分析
那么我们为什么要在 Kubernetes 中引入这种原地升级的理念和设计呢
首先这种原地升级的模式极大地提升了应用发布的效率根据非完全统计数据在阿里环境下原地升级至少比完全重建升级提升了 80% 以上的发布速度。这其实很容易理解原地升级为发布效率带来了以下优化点
节省了调度的耗时Pod 的位置、资源都不发生变化节省了分配网络的耗时Pod 还使用原有的 IP节省了分配、挂载远程盘的耗时Pod 还使用原有的 PV且都是已经在 Node 上挂载好的节省了大部分拉取镜像的耗时因为 Node 上已经存在了应用的旧镜像当拉取新版本镜像时只需要下载很少的几层 layer。
其次当我们升级 Pod 中一些 sidecar 容器如采集日志、监控等时其实并不希望干扰到业务容器的运行。但面对这种场景Deployment 或 StatefulSet 的升级都会将整个 Pod 重建势必会对业务造成一定的影响。而容器级别的原地升级变动的范围非常可控只会将需要升级的容器做重建其余容器包括网络、挂载盘都不会受到影响。
最后原地升级也为我们带来了集群的稳定性和确定性。当一个 Kubernetes 集群中大量应用触发重建 Pod 升级时可能造成大规模的 Pod 飘移以及对 Node 上一些低优先级的任务 Pod 造成反复的抢占迁移。这些大规模的 Pod 重建本身会对 apiserver、scheduler、网络/磁盘分配等中心组件造成较大的压力而这些组件的延迟也会给 Pod 重建带来恶性循环。而采用原地升级后整个升级过程只会涉及到 controller 对 Pod 对象的更新操作和 kubelet 重建对应的容器。
技术背景
在阿里巴巴内部绝大部分电商应用在云原生环境都统一用原地升级的方式做发布而这套支持原地升级的控制器就位于 OpenKruise 开源项目中。
也就是说阿里内部的云原生应用都是统一使用 OpenKruise 中的扩展 workload 做部署管理的而并没有采用原生 Deployment/StatefulSet 等。 那么 OpenKruise 是如何实现原地升级能力的呢在介绍原地升级实现原理之前我们先来看一些原地升级功能所依赖的原生 Kubernetes 功能
背景 1Kubelet 针对 Pod 容器的版本管理
每个 Node 上的 Kubelet会针对本机上所有 Pod.spec.containers 中的每个 container 计算一个 hash 值并记录到实际创建的容器中。
如果我们修改了 Pod 中某个 container 的 image 字段kubelet 会发现 container 的 hash 发生了变化、与机器上过去创建的容器 hash 不一致而后 kubelet 就会把旧容器停掉然后根据最新 Pod spec 中的 container 来创建新的容器。
这个功能其实就是针对单个 Pod 的原地升级的核心原理。
背景 2Pod 更新限制
在原生 kube-apiserver 中对 Pod 对象的更新请求有严格的 validation 校验逻辑
// validate updateable fields:
// 1. spec.containers[*].image
// 2. spec.initContainers[*].image
// 3. spec.activeDeadlineSeconds
简单来说对于一个已经创建出来的 Pod在 Pod Spec 中只允许修改 containers/initContainers 中的 image 字段以及 activeDeadlineSeconds 字段。对 Pod Spec 中所有其他字段的更新都会被 kube-apiserver 拒绝。
背景 3containerStatuses 上报
kubelet 会在 pod.status 中上报 containerStatuses对应 Pod 中所有容器的实际运行状态
apiVersion: v1
kind: Pod
spec:containers:- name: nginximage: nginx:latest
status:containerStatuses:- name: nginximage: nginx:mainlineimageID: docker-pullable://nginxsha256:2f68b99bc0d6d25d0c56876b924ec20418544ff28e1fb89a4c27679a40da811b
绝大多数情况下spec.containers[x].image 与 status.containerStatuses[x].image 两个镜像是一致的。
但是也有上述这种情况kubelet 上报的与 spec 中的 image 不一致spec 中是 nginx:latest但 status 中上报的是 nginx:mainline。
这是因为kubelet 所上报的 image 其实是从 CRI 接口中拿到的容器对应的镜像名。而如果 Node 机器上存在多个镜像对应了一个 imageID那么上报的可能是其中任意一个
$ docker images | grep nginx
nginx latest 2622e6cca7eb 2 days ago 132MB
nginx mainline 2622e6cca7eb 2 days ago
因此一个 Pod 中 spec 和 status 的 image 字段不一致并不意味着宿主机上这个容器运行的镜像版本和期望的不一致。
背景 4ReadinessGate 控制 Pod 是否 Ready
在 Kubernetes 1.12 版本之前一个 Pod 是否处于 Ready 状态只是由 kubelet 根据容器状态来判定如果 Pod 中容器全部 ready那么 Pod 就处于 Ready 状态。
但事实上很多时候上层 operator 或用户都需要能控制 Pod 是否 Ready 的能力。因此Kubernetes 1.12 版本之后提供了一个 readinessGates 功能来满足这个场景。如下
apiVersion: v1
kind: Pod
spec:readinessGates:- conditionType: MyDemo
status:conditions:- type: MyDemostatus: True- type: ContainersReadystatus: True- type: Readystatus: True
目前 kubelet 判定一个 Pod 是否 Ready 的两个前提条件
Pod 中容器全部 Ready其实对应了 ContainersReady condition 为 True如果 pod.spec.readinessGates 中定义了一个或多个 conditionType那么需要这些 conditionType 在 pod.status.conditions 中都有对应的 status: true 的状态。
只有满足上述两个前提kubelet 才会上报 Ready condition 为 True。
实现原理
了解了上面的四个背景之后接下来分析一下 OpenKruise 是如何在 Kubernetes 中实现原地升级的原理。
1. 单个 Pod 如何原地升级
由“背景 1”可知其实我们对一个存量 Pod 的 spec.containers[x] 中字段做修改kubelet 会感知到这个 container 的 hash 发生了变化随即就会停掉对应的旧容器并用新的 container 来拉镜像、创建和启动新容器。
由“背景 2”可知当前我们对一个存量 Pod 的 spec.containers[x] 中的修改仅限于 image 字段。
因此得出第一个实现原理**对于一个现有的 Pod 对象我们能且只能修改其中的 spec.containers[x].image 字段来触发 Pod 中对应容器升级到一个新的 image。
2. 如何判断 Pod 原地升级成功
接下来的问题是当我们修改了 Pod 中的 spec.containers[x].image 字段后如何判断 kubelet 已经将容器重建成功了呢
由“背景 3”可知比较 spec 和 status 中的 image 字段是不靠谱的因为很有可能 status 中上报的是 Node 上存在的另一个镜像名相同 imageID。
因此得出第二个实现原理判断 Pod 原地升级是否成功相对来说比较靠谱的办法是在原地升级前先将 status.containerStatuses[x].imageID 记录下来。在更新了 spec 镜像之后如果观察到 Pod 的 status.containerStatuses[x].imageID 变化了我们就认为原地升级已经重建了容器。
但这样一来我们对原地升级的 image 也有了一个要求不能用 image 名字tag不同、但实际对应同一个 imageID 的镜像来做原地升级否则可能一直都被判断为没有升级成功因为 status 中 imageID 不会变化。
当然后续我们还可以继续优化。OpenKruise 即将开源镜像预热的能力会通过 DaemonSet 在每个 Node 上部署一个 NodeImage Pod。通过 NodeImage 上报我们可以得知 pod spec 中的 image 所对应的 imageID然后和 pod status 中的 imageID 比较即可准确判断原地升级是否成功。
3. 如何确保原地升级过程中流量无损
在 Kubernetes 中一个 Pod 是否 Ready 就代表了它是否可以提供服务。因此像 Service 这类的流量入口都会通过判断 Pod Ready 来选择是否能将这个 Pod 加入 endpoints 端点中。
由“背景 4”可知从 Kubernetes 1.12 之后operator/controller 这些组件也可以通过设置 readinessGates 和更新 pod.status.conditions 中的自定义 type 状态来控制 Pod 是否可用。
因此得出第三个实现原理可以在 pod.spec.readinessGates 中定义一个叫 InPlaceUpdateReady 的 conditionType。
在原地升级时
先将 pod.status.conditions 中的 InPlaceUpdateReady condition 设为 False这样就会触发 kubelet 将 Pod 上报为 NotReady从而使流量组件如 endpoint controller将这个 Pod 从服务端点摘除再更新 pod spec 中的 image 触发原地升级。
原地升级结束后再将 InPlaceUpdateReady condition 设为 True使 Pod 重新回到 Ready 状态。
另外在原地升级的两个步骤中第一步将 Pod 改为 NotReady 后流量组件异步 watch 到变化并摘除端点可能是需要一定时间的。因此我们也提供优雅原地升级的能力即通过 gracePeriodSeconds 配置在修改 NotReady 状态和真正更新 image 触发原地升级两个步骤之间的静默期时间。
4. 组合发布策略
原地升级和 Pod 重建升级一样可以配合各种发布策略来执行
partition如果配置 partition 做灰度那么只会将 replicas-partition 数量的 Pod 做原地升级maxUnavailable如果配置 maxUnavailable那么只会将满足 unavailable 数量的 Pod 做原地升级maxSurge如果配置 maxSurge 做弹性那么当先扩出来 maxSurge 数量的 Pod 之后存量的 Pod 仍然使用原地升级priority/scatter如果配置了发布优先级/打散策略会按照策略顺序对 Pod 做原地升级。
总结
如上文所述OpenKruise 结合 Kubernetes 原生提供的 kubelet 容器版本管理、readinessGates 等功能实现了针对 Pod 的原地升级能力。
而原地升级也为应用发布带来大幅的效率、稳定性提升。值得关注的是随着集群、应用规模的增大这种提升的收益越加明显。正是这种原地升级能力在近两年帮助了阿里巴巴超大规模的应用容器平稳迁移到了基于 Kubernetes 的云原生环境而原生 Deployment/StatefulSet 是完全无法在这种体量的环境下铺开使用的。欢迎加入钉钉交流群23330762
- 赠书福利 - 6 月 19 日 1200 前在【阿里巴巴云原生公众号】留言区提出你的疑问精选留言点赞第 1 名将免费获得此书届时我们还会请本文作者针对留言点赞前 5 名的问题进行答疑
课程推荐
为了更多开发者能够享受到 Serverless 带来的红利这一次我们集结了 10 位阿里巴巴 Serverless 领域技术专家打造出最适合开发者入门的 Serverless 公开课让你即学即用轻松拥抱云计算的新范式——Serverless。
点击即可免费观看课程https://developer.aliyun.com/learning/roadmap/serverless “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践做最懂云原生开发者的公众号。” 原文链接 本文为云栖社区原创内容未经允许不得转载。
