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