公众号「架构成长指南」，专注于生产实践、云原生、分布式系统、大数据技术分享。
在过去的几年中，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。
滚动部署
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平台去做这些事情。