Deployment
Deployment 操作
当你使用 kubectl create deployment 时，你正在部署一个名为 Deployment 的对象。与其他对象一样，Deployment 也可以使用 YAML 或 JSON 文件（即 manifests）创建。如果你想改变对象的任何配置，例如 pod，你可以使用 kubectl apply，通过 manifest，甚至通过 kubectl edit。通常情况下，当您对 Deployment 进行更改时，会创建一个新版本的 ReplicaSet，它将成为资产并导致其前身被禁用。较早版本的 ReplicaSets 将被保留，从而在发生故障时可以回滚。
标签对于集群的管理是很重要的，因为有了标签就可以搜索或选择集群中的资源，使你能够以小类来组织，从而方便你的搜索和组织你的豆荚和集群资源。标签不是 API 服务器的功能，它们是以键值格式存储在元数据中的。
生命周期管理
创建
比如一个简单的 Nginx 应用可以定义为：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
然后通过如下操作进行创建：
$ kubectl create -f https://raw.githubusercontent.com/kubernetes-client/python/master/examples/nginx-deployment.yaml --record
deployment "nginx-deployment" created
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
# 等待一段时间
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
可以看到 Deployment 已经创建了 3 个 replica，所有的 replica 都已经是最新的了（包含最新的 pod template），可用的（根据 Deployment 中的.spec.minReadySeconds 声明，处于已就绪状态的 pod 的最少个数）。执行 kubectl get rs 和 kubectl get pods 会显示 Replica Set（RS）和 Pod 已创建。
# ReplicaSet 的名字总是<Deployment的名字>-<pod template的hash值>。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-2035384211 3 3 0 18s
扩容
您可以使用以下命令扩容 Deployment：
$ kubectl scale deployment nginx-deployment --replicas 10
deployment "nginx-deployment" scaled
假设您的集群中启用了 horizontal pod autoscaling，您可以给 Deployment 设置一个 autoscaler，基于当前 Pod 的 CPU 利用率选择最少和最多的 Pod 数。
$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment "nginx-deployment" autoscaled
RollingUpdate Deployment 支持同时运行一个应用的多个版本。或者 autoscaler 扩 容 RollingUpdate Deployment 的时候，正在中途的 rollout（进行中或者已经暂停的），为了降低风险，Deployment controller 将会平衡已存在的活动中的 ReplicaSet（有 Pod 的 ReplicaSet）和新加入的 replica。这被称为比例扩容。
譬如正在运行中含有 10 个 replica 的 Deployment。maxSurge=3，maxUnavailable=2：
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 10 10 10 10 50s
# 更新了错误的镜像
$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
deployment "nginx-deployment" image updated
# 启动了一个包含 ReplicaSet nginx-deployment-1989198191 的新的 rollout，但是它被阻塞
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 5 5 0 9s
nginx-deployment-618515232 8 8 8 1m
autoscaler 将 Deployment 的 repllica 数目增加到了 15 个。Deployment controller 需要判断在哪里增加这 5 个新的 replica。如果我们没有谁用比例扩容，所有的 5 个 replica 都会加到一个新的 ReplicaSet 中。如果使用比例扩容，新添加的 replica 将传播到所有的 ReplicaSet 中。大的部分加入 replica 数最多的 ReplicaSet 中，小的部分加入到 replica 数少的 ReplciaSet 中。0 个 replica 的 ReplicaSet 不会被扩容。在我们上面的例子中，3 个 replica 将添加到旧的 ReplicaSet 中，2 个 replica 将添加到新的 ReplicaSet 中。rollout 进程最终会将所有的 replica 移动到新的 ReplicaSet 中，假设新的 replica 成为健康状态。
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
更新
Kubernetes 提供了多种升级方案，Recreate 即删除所有已存在的 pod,重新创建新的; RollingUpdate 即滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用 Pod 数量，最小升级间隔时间等等。Deployment 的 rollout 当且仅当 Deployment 的 pod template（例如.spec.template）中的 label 更新或者镜像更改时被触发。其他更新，例如扩容 Deployment 不会触发 rollout。
# 让 nginx pod 使用nginx:1.9.1的镜像来代替原来的nginx:1.7.9的镜像
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
我们可以使用 edit 命令来编辑 Deployment，修改 .spec.template.spec.containers[0].image，将 nginx:1.7.9 改写成 nginx:1.9.1。
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited
# 查看 rollout 的状态
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
# 查看关联的 ReplicaSet 信息
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 0 6s
nginx-deployment-2035384211 0 0 0 36s
我们通过执行 kubectl get rs 可以看到 Deployment 更新了 Pod，通过创建一个新的 ReplicaSet 并扩容了 3 个 replica，同时将原来的 ReplicaSet 缩容到了 0 个 replica。执行 get pods 只会看到当前的新的 pod。
Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的 Pod 数量少一个是 up 状态（最多一个不可用）。Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的 Pod 数量多一个的 Pod 是 up 的（最多 1 个 surge）。
回滚
有时候您可能想回退一个 Deployment，例如，当 Deployment 不稳定时，比如一直 crash looping。默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便您可以随时回退（您可以修改 revision history limit 来更改保存的 revision 数）。
只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如.spec.template）被更改，例如更新 template 中的 label 和容器镜像时，就会创建出一个新的 revision。其他的更新，比如扩容 Deployment 不会创建 revision，因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退。
# 检查下 Deployment 的 revision
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION CHANGE-CAUSE
1 kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml--record
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
因为我们创建 Deployment 的时候使用了–record 参数可以记录命令，我们可以很方便的查看每次 revision 的变化。查看单个 revision 的详细信息：
$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
QoS Tier:
cpu: BestEffort
memory: BestEffort
Environment Variables: <none>
No volumes.
同样可以通过 rollout 命令来回退版本：
# 回退当前的 rollout 到之前的版本
$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back
# 使用 --revision参数指定某个历史版本
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back
可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为 0，Deployment 就不允许回退了。
暂停和恢复
您可以在发出一次或多次更新前暂停一个 Deployment，然后再恢复它。这样您就能在 Deployment 暂停期间进行多次修复工作，而不会发出不必要的 rollout。例如使用刚刚创建 Deployment：
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 1m
[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m
使用以下命令暂停 Deployment：
$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" paused
然后更新 Deplyment 中的镜像：
$ kubectl set image deploy/nginx nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
注意新的 rollout 启动了：
$ kubectl rollout history deploy/nginx
deployments "nginx"
REVISION CHANGE-CAUSE
1 <none>
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 2m
您可以进行任意多次更新，例如更新使用的资源：
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updated
Deployment 暂停前的初始状态将继续它的功能，而不会对 Deployment 的更新产生任何影响，只要 Deployment是暂停的。
最后，恢复这个 Deployment，观察完成更新的 ReplicaSet 已经创建出来了：
$ kubectl rollout resume deploy nginx
deployment "nginx" resumed
过滤与选择
根据标签过滤
当我们创建 Deployments 时，我们添加了以下标签：
labels:
run: nginx
dc: UK
---
labels:
run: nginx
dc: Netherlands
Labels 是用来组织集群的，让我们列出我们的 Pods 寻找 Labels。首先让我们用 dc=UK 和 dc=Netherlands 这两个标签进行搜索。
$ kubectl get pods -l dc=UK
NAME READY STATUS RESTARTS AGE
primeiro-deployment-68c9dbf8b8-kjqpt 1/1 Running 0 3m
$ kubectl get pods -l dc=Netherlands
NAME READY STATUS RESTARTS AGE
segundo-deployment-59db86c584-cf9pp 1/1 Running 0 4m
如果你想要更个性化的输出，我们可以列举如下：
kubectl get pod -L dc
NAME READY STATUS RESTARTS AGE DC
primeiro-deployment-68c9... 1/1 Running 0 5m UK
segundo-deployment-59db ... 1/1 Running 0 5m Netherlands