二、Deployment（针对部署的无状态应用）
一）功能
1、创建
# 创建一个 deployment
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-labels
2、滚动更新
只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作，注意：仅仅修改本地的yaml文件是不会滚动更新的。
# 修改 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 --show-labels 获取部署信息，UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目
通过 kubectl get rs --show-labels 可以看到增加了一个新的 rs，旧的 rs 的 READY归0，新的 rs READY = 3
通过 kubectl get pods --show-labels 可以看到所有 pod 关联的 rs 变成了新的
2.1 多个滚动更新并行
假设当前有 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 命令可以进行自动扩容/缩容
kubectl scale --replicas=6 deploy nginx-deploy
通过 kubectl edit deploy nginx-deploy 编辑 replcas参数 也可以实现扩容/缩容
kubectl edit deploy nginx-deploy
扩容与缩容只是直接创建副本数，没有更新 pod template 因此不会创建新的 rs
最后是 1个deploy 可以管理 1个rs 进行扩容/缩容，1个rs 对应多个 pod
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
那么此时我们再恢复 rollout，通过命令
kubectl rollout resume deploy <name>
恢复后，我们再次查看 rs 和 po 信息，我们可以看到就开始进行滚动更新操作了
kubectl get rs
kubectl get po
二）配置文件
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% # 进行滚动更新时，最大 不可用更新比例，表示在所有副本数中，最多 可以有 多少个 不更新成功。比如有10个要更新，最多2.5个没更新成功。
type: RollingUpdate # 更新类型，采用滚动更新
template: # pod 模板
metadata: # pod 的元信息
labels: # pod 的标签
app: nginx-deploy
spec: # pod 期望信息
containers: # pod 的容器
- image: nginx:1.7.9 # 镜像
imagePullPolicy: IfNotPresent # 拉取策略
name: nginx # <font color="red">**容器名称**</font>
restartPolicy: Always # 重启策略
terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间