滚动更新和回滚部署在 Kubernetes 中的工作原理
公众号「架构成长指南」,专注于生产实践、云原生、分布式系统、大数据技术分享。
在过去的几年中,Kubernetes
在生产环境中被广泛使用,它通过其声明式 API 提供了大量解决方案,用于编排容器。
Kubernetes
的一个显著特性是其具有弹性的能力,能够执行滚动更新和回滚部署,而能够完成这些滚动更新和回滚,主要是由Deployment
来实现的,下面就讲解下Deployment
的相关知识
Deployment
Deployment
是 Kubernetes 中处理工作负载(应用程序)的机制之一。它由 Kubernetes的Deployment Controller
管理.。
在 Kubernetes 中,控制器是一个控制环,它负责观察集群的状态,然后根据需要做出或请求做出更改。每个控制器都试图让当前集群状态更接近所需的状态。
在这里的部署中,我们希望实现的状态其实是 pod 的状态,在 K8s 中一切都是声明式的,因此所需的状态会作为规范写入部署清单文件中。
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
如果pod实例出现故障或更新(状态改变),Kubernetes会对yaml中声明状态和实际状态之间的差异做出响应,进行修正,即与定义的部署状态相匹配。
Deployment的内部工作原理
Deployment
是对 ReplicaSet
的抽象。在内部,部署创建了一个ReplicaSet
,而 ReplicaSet
则在集群上创建了一组 Pod。因此,ReplicaSet
其实实在管理我们的 Pod
的副本。
总之,控制器会读取Deployment
配置声明,将 pod 配置转发给 ReplicaSet
,然后用适当的副本创建Pod
。
Deployment > ReplicaSet > Pods
滚动部署
Kubernetes
承诺零停机时间,其背后的原理之一就是滚动部署。通过滚动部署,Kubernetes
可以保证在部署更新 pod 时不会中断 pod 的流量
示例
下面让我们亲自操作一下Kubernetes
,来看看这些部署策略。
Create Deployment
在前面的章节中,写过一个Kubernetes
的部署手册,如果没有Kubernetes
集群的同学,请进行参考
最佳实践-使用RKE快速部署K8S集群
$ kubectl create deployment test-nginx --image=nginx:1.18-alpine
如前所述,部署会创建一个ReplicaSet
,然后是Pod
。您可以使用
$ kubectl get deploy,rs,po -l app=test-nginx
可以检查Deployment
是否创建了ReplicaSet
。
$ kubectl describe <replica-set-name>
同时我们还可以看一下是否是ReplicaSet
创建了pod
$ kubectl describe <pod-name>
扩容 Deployment
让我们将部署扩展到 3 个 nginx pod 实例。
$ kubectl scale deploy test-nginx --replicas=3
现在,我们的集群上已经有了多个pod实例了,下面让我们试试部署策略。
滚动更新部署
假设我们在使用nginx的1.18-alpine
版本遇到了一些问题,而1.19-alpine
版本解决了这些问题,因此我们需要让pod更新为新版本镜像。
通过更新当前 pod 的镜像(状态变更),Kubernetes 将进行新的部署。
$ kubectl set image deploy test-nginx nginx=nginx:1.19-alpine
设置新镜像后,我们可以看到旧的 pod 被终止,新的 pod 被创建。
我们可以看到Kubernetes
在更新过程中,在为新 pod 创建完整的副本之前,最后一个旧 pod 不会被终止。旧 pod 也会有一个宽限期,确保其服务的流量在一定时间内不会断开,直到请求可以安全地路由到新创建的 pod。
虽然这么说但是有时候
Kubernetes
认为的pod启动就绪,并不是我们期望的启动并就绪,这个地方需要结合自身系统进行判断,后面的文章会进行讲解
可以看到nginx的版本已经更新完成
回滚部署版本
假设新的nginx更新后比上一个版本问题更多,而我们现在意识到旧版本的还是更靠谱,这时候需要回滚到之前的nginx版本
但该怎么做?你可能已经注意到,现在有两个ReplicaSets
。这与我们前面的说明部署模式是一样的,我们更新部署,它就会创建一个新的ReplicaSet
,从而创建新的Pod
。
Kubernetes
默认最多保留 10 个 ReplicaSet
的历史记录,我们可以在部署规范中使用revisionHistoryLimit
来更新这一数字。
这些历史记录将作为滚动跟踪,最新版本的才是目前使用的。
到目前为止,我们已经对部署 test-nginx 做了两次更改,因此部署历史记录应该是两次。
$ kubectl get rs|grep test-nginx
$ kubectl rollout history deploy test-nginx
$ kubectl rollout history deploy test-nginx --revision=1
可以看到revision=1
对应的是1.18-alpine
,下面让我们回滚到上一个版本即1.18-alpine
$ kubectl rollout undo deploy test-nginx --to-revision=1
与 滚动更新部署
一样,回滚部署
也会终止当前 pod,并用包含来自 Revision 1
的 Pod 替换它们。
如果再次查看部署历史,就会发现修订版 1 已被用于创建最新的 pod,并标记为修订版 3。
在多个修订版中重复维护同一规范是没有意义的,所以Kubernetes
删除了修订版 1,因为我们已经有了同一规范的最新修订版 3。
现在我们已经回滚到了1.18-alpine
版本,通过describe
部署可以进行验证。
$ kubectl describe deploy test-nginx
总结
通过 Kubernetes,我们可以利用这些策略轻松控制应用程序的部署。以上只是对滚动和回滚更新部署工作原理的简单介绍。在实际工作中,我们很少手动完成所有这些步骤,我们一般会交给 CI/CD平台去做这些事情。