kubernetes-deployments

Kubernetes令部署应用、管理应用变得简单直白，令大多数操做简化为单个API或单个命令行，包括发布新的应用程序，升级。那么为何咱们还须要部署呢？nginx

自动化Deployment和滚动更新程序。相比于kubectl滚动更新，Deployment API更加快速，具备描述性，实现服务端，还有更多的功能（好比，即便是在滚动更新完成以后，你也能够回滚到以前的版本，）。docker

Deployment是新一代用于Pod管理的对象，与Replication Controller相比，它提供了更加完善的功能，使用起来更加简单方便。api

注：本文进行的相关操做是基于k8s 1.2.2版本执行的。app

Deployment相关操做

建立

咱们可使用下面的yaml文件来建立一个Deployment：ide

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
        track: stable
    spec:
      containers:
      - name: nginx
        image: index.tenxcloud.com/docker_library/nginx:1.7.9
        ports:
        - containerPort: 80

从上面的例子中能够发现Deployment与RC的定义基本相同，须要注意的是apiVersion和kind是有差别的。ui

状态查询

使用kubectl get能够查询Deployment当前状态：spa

$ kubectl get deployment
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           2h

其中DESIRED为指望的Pod数量，CURRENT为当前的数量，UP-TO-DATE为已更新的数量，AVAILABLE为已运行的数量。经过这四个数量咱们能够了解到Deployment目前的状态。Deployment会自动处理直到四个数量达到一致，而在Deployment更新过程当中CURRENT、UP-TO-DATE和AVAILABLE会根据不一样状况发生变化。命令行

更新

Deployment更新分为两种状况：code

rolling-update。只有当Pod template发生变动时，Deployment才会触发rolling-update。此时Deployment会自动完成更新，且会保证更新期间始终有必定数量的Pod为运行状态。
其余变动，如暂停/恢复更新、修改replica数量、修改变动记录数量限制等操做。这些操做不会修改Pod参数，只影响Deployment参数，所以不会触发rolling-update。

经过kubectl edit指令更新Deployment，能够将例子中的nginx镜像版本改为1.9.1来触发一次rolling-update。期间经过kubectl get来查看Deployment的状态，能够发现CURRENT、UP-TO-DATE和AVAILABLE会发生变化。对象

删除

kubectl delete指令能够用来删除Deployment。须要注意的是经过API删除Deployment时，对应的RS和Pods不会自动删除，须要依次调用删除Deployment的API、删除RS的API和删除Pods的API。

特性

使用RS管理Pod

Replica Set（简称RS）是k8s新一代的Pod controller。与RC相比仅有selector存在差别，RS支持了set-based selector（可使用in、notin、key存在、key不存在四种方式来选择知足条件的label集合）。Deployment是基于RS实现的，咱们可使用kubectl get rs命令来查看Deployment建立的RS：

$ kubectl get rs
NAME                          DESIRED   CURRENT   AGE
nginx-deployment-1564180365   3         3         6s
nginx-deployment-2035384211   0         0         36s

由Deployment建立的RS的命名规则为“<Deployment名称>-<pod template摘要值>”。因为以前的操做中咱们触发了一次rolling-update，所以会查看到两个RS。更新先后的RS都会保留下来。

弹性伸缩

与RC相同，只须要修改.spec.replicas就能够实现Pod的弹性伸缩。

从新部署

若是设置Deployment的.spec.strategy.type==Recreate时，更新时会将全部已存在的Pod杀死后再建立新Pod。与RC不一样的是，修改Deployment的Pod template后更新操做将会自动执行，无需手动删除旧Pod。

更完善的rolling-update

与RC相比，Deployment提供了更完善的rolling-update功能：

Deployment不须要使用kubectl rolling-update指令来触发rolling-update，只需修改pod template内容便可。这条规则一样适用于使用API来修改Deployment的场景。这就意味着使用API集成的应用，无须本身实现一套基于RC的rolling-udpate功能，Pod更新全都交给Deployment便可。

Deployment会对更新的可用性进行检查。当使用新template建立的Pod没法运行时，Deployment会终止更新操做，并保留必定数量的旧版本Pod来提供服务。例如咱们更新nginx镜像版本为1.91（一个不存在的版本），能够看到如下结果：

$ kubectl get rs
NAME                          DESIRED   CURRENT   AGE
nginx-deployment-1564180365   2         2         25s
nginx-deployment-2035384211   0         0         36s
nginx-deployment-3066724191   2         2         6s

$ kubectl get pods
NAME                                READY     STATUS             RESTARTS   AGE
nginx-deployment-1564180365-70iae   1/1       Running            0          25s
nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s

此外Deployment还支持在rolling-update过程当中暂停和恢复更新过程。经过设置.spec.paused值便可暂停和恢复更新过程。暂停更新后的Deployment可能会处于与如下示例相似的状态：

$ kubectl get deployment
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         4         2            4           2h

$ kubectl get rs
NAME                          DESIRED   CURRENT   AGE
nginx-deployment-1569886762   2         2         2h
nginx-deployment-2041090608   0         0         2h
nginx-deployment-956404068    2         2         2h

支持多重更新，在更新过程当中能够执行新的更新操做。Deployment会保证更新结果为最后一次更新操做的执行结果。

影响更新的一些参数：

.spec.minReadySeconds参数用来设置确认运行状态的最短等待时间。更新Pod以后，Deployment至少会等待配置的时间再确认Pod是否处于运行状态。也就是说在更新一批Pod以后，Deployment会至少等待指定时间再更新下一批Pod。
.spec.strategy.rollingUpdate.maxUnavailable用来控制不可用Pod数量的最大值，从而在删除旧Pod时保证必定数量的可用Pod。若是配置为1，且replicas为3。则更新过程当中会保证至少有2个可用Pod。默认为1。
.spec.strategy.rollingUpdate.maxSurge用来控制超过时望数量的Pod数量最大值，从而在建立新Pod时限制总量。如配置为1，且replicas为3。则更新过着中会保证Pod总数量最多有4个。默认为1。
后两个参数不能同时为0。

更新回退

除了提供完善的更新功能外，Deployment还支持回退到历史版本（曾经更新过的版本）。Deployment的更新回退是基于RS和revision号来实现的：

在以前的示例中咱们了解到每次更新都会有对应的RS，这些RS用来记录Pod template。使用相同Pod template的更新操做只会建立一个RS。
每一个RS会对应一个revision版本号，revision是一个递增的正整数。
在回退Deployment时指定对应的revision便可完成回退操做，指定0能够回退到上一版本。
经过kubectl rollout history deployment/

参考资料

Deployment用户手册：

http://kubernetes.io/docs/user-guide/deployments/

Replica Set用户手册：

http://kubernetes.io/docs/user-guide/replicasets/

set-based selector：

http://kubernetes.io/docs/user-guide/labels/#label-selectors

Deployment API：

http://kubernetes.io/docs/api-reference/extensions/v1beta1/operations/

canary部署示例：

http://kubernetes.io/docs/user-guide/managing-deployments/#canary-deployments