滚动更新和回滚部署在 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平台去做这些事情。

热门相关:韩娱之影帝   都市捉妖人   苍穹龙骑   你好,墨先生   你好,墨先生