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

最近更新于0001-01-01