一、功能
Deployment为Pod和Replica Set提供声明式更新。你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
注意：您不该手动管理由 Deployment 创建的 Replica Set，否则您就篡越了 Deployment controller 的职责！
1. 创建
创建一个 deployment （以 Nginx 为例）
kubectl create deploy nginx-deploy --image=nginx:1.7.9或执行
kubectl create -f xxx.yaml --record
# --record 会在 annotation 中记录当前命令创建或升级了资源，后续可以查看做过哪些变动操作。查看部署信息
kubectl get deployments查看 rs
kubectl get rs查看 pod 以及展示标签，可以看到是关联的那个 rs
kubectl get pods --show-labels2. 滚动更新
只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作
修改 nginx 版本号
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
或者通过 kubectl edit deployment/nginx-deployment 进行修改查看滚动更新的过程
kubectl rollout status deploy <deployment_name>查看部署描述，最后展示发生的事件列表也可以看到滚动更新过程
kubectl describe deploy <deployment_name>通过 kubectl get deployments 获取部署信息，UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目
通过 kubectl get rs 可以看到增加了一个新的 rs
通过 kubectl get pods 可以看到所有 pod 关联的 rs 变成了新的
多个滚动更新并行
假设当前有 5 个 nginx:1.7.9 版本，你想将版本更新为 1.9.1，当更新成功第三个以后，
你马上又将期望更新的版本改为 1.9.2，那么此时会立马删除之前的三个，并且立马开启更新 1.9.2 的任务
3. 回滚
有时候你可能想回退一个Deployment，例如，当Deployment不稳定时，比如一直crash looping。
默认情况下，kubernetes会在系统中保存前两次的Deployment的rollout历史记录，以便你可以随时会退（你可以修改revision history limit来更改保存的revision数）。
案例：
更新 deployment 时参数不小心写错，如 nginx:1.9.1 写成了 nginx:1.91
kubectl set image deployment/nginx-deploy nginx=nginx:1.91监控滚动升级状态，由于镜像名称错误，下载镜像失败，因此更新过程会卡住
kubectl rollout status deployments nginx-deploy结束监听后，获取 rs 信息，我们可以看到新增的 rs 副本数是 2 个
kubectl get rs通过 kubectl get pods 获取 pods 信息，我们可以看到关联到新的 rs 的 pod，状态处于 ImagePullBackOff 状态
为了修复这个问题，我们需要找到需要回退的 revision 进行回退
通过 kubectl rollout history deployment/nginx-deploy可以获取 revison 的列表
通过 kubectl rollout history deployment/nginx-deploy --revision=2 可以查看详细信息
确认要回退的版本后，可以通过 kubectl rollout undo deployment/nginx-deploy 可以回退到上一个版本
也可以回退到指定的 revision
kubectl rollout undo deployment/nginx-deploy --to-revision=2再次通过 kubectl get deployment 和 kubectl describe deployment 可以看到，我们的版本已经回退到对应的 revison 上了
可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison，如果设置为 0，则不允许 deployment 回退了。
4. 扩容缩容
通过 kube scale 命令可以进行自动扩容/缩容，以及通过 kube edit 编辑 replcas 也可以实现扩容/缩容
扩容与缩容只是直接创建副本数，没有更新 pod template 因此不会创建新的 rs
5. 暂停与恢复
由于每次对 pod template 中的信息发生修改后，都会触发更新 deployment 操作，那么此时如果频繁修改信息，就会产生多次更新，
而实际上只需要执行最后一次更新即可，当出现此类情况时我们就可以暂停 deployment 的 rollout
通过 kubectl rollout pause deployment <name> 就可以实现暂停，直到你下次恢复后才会继续进行滚动更新
尝试对容器进行修改，然后查看是否发生更新操作了
kubectl set image deploy <name> nginx=nginx:1.17.9
kubectl get po通过以上操作可以看到实际并没有发生修改，此时我们再次进行修改一些属性，
如限制 nginx 容器的最大cpu为 0.2 核，最大内存为 128M，最小内存为 64M，最小 cpu 为 0.1 核
kubectl set resources deploy <deploy_name> -c <container_name> --limits=cpu=200m,memory=128Mi --requests=cpu100m,memory=64Mi通过格式化输出 kubectl get deploy <name> -oyaml，可以看到配置确实发生了修改，再通过 kubectl get po 可以看到 pod 没有被更新
那么此时我们再恢复 rollout，通过命令 kubectl rollout deploy <name>
恢复后，我们再次查看 rs 和 po 信息，我们可以看到就开始进行滚动更新操作了
kubectl get rs
kubectl get po二、配置文件 （以 Nginx 为例）
apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
labels: # 标签
app: nginx-deploy # 具体的 key: value 配置形式
name: nginx-deploy # deployment 的名字
namespace: default # 所在的命名空间
spec:
replicas: 1 # 期望副本数
revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
selector: # 选择器，用于找到匹配的 RS
matchLabels: # 按照标签匹配
app: nginx-deploy # 匹配的标签key/value
strategy: # 更新策略
rollingUpdate: # 滚动更新配置
maxSurge: 25% # 进行滚动更新时，更新的个数最多可以超过期望副本数的个数/比例
maxUnavailable: 25% # 进行滚动更新时，最大不可用比例更新比例，表示在所有副本数中，最多可以有多少个不更新成功
type: RollingUpdate # 更新类型，采用滚动更新
template: # pod 模板
metadata: # pod 的元信息
labels: # pod 的标签
app: nginx-deploy
spec: # pod 期望信息
containers: # pod 的容器
- image: nginx:1.7.9 # 镜像
imagePullPolicy: IfNotPresent # 拉取策略
name: nginx # 容器名称
restartPolicy: Always # 重启策略
terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间