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