kubernetes 滾動升級
Kubernetes 中采用ReplicaSet（簡稱RS）來管理Pod。如果當前集群中的Pod實例數少於目標值，RS 會拉起新的Pod，反之，則根據策略刪除多余的Pod。Deployment正是利用了這樣的特性，通過控制兩個RS里面的Pod，從而實現升級。
滾動升級是一種平滑過渡式的升級，在升級過程中，服務仍然可用。
創建deployment
kubectl create deploy nginx-test --image=nginx:1.14
scale 副本數量
kubectl scale deployment nginx-test --replicas 10
如果集群支持 horizontal pod autoscaling 的話，還可以為Deployment設置自動擴展：
kubectl autoscale deployment nginx-test --min=10 --max=15 --cpu-percent=80
需要注意的是,horizontal pod autoscaling(HPA)作用於Replication Controller 對象時,再對其使用rolling update會變成無效操作,因為RC在滾動更新時,是通過創建新的RC對象來替代舊的對象,但是HPA無法自動綁定到新創建的RC對象上
更新 deployment
更新鏡像
kubectl set image deployment/nginx-test nginx=nginx:1.15
回滾到上一個版本：
kubectl rollout undo deployment/nginx-test
也可以使用 --revision參數指定某個歷史版本：
kubectl rollout undo deployment/nginx-test --to-revision=2
歷史記錄
kubectl rollout history deployment/nginx-test
創建 Deployment 的時候使用了--record參數可以記錄命令，我們可以很方便的查看每次 revision 的變化。查看單個revision 的詳細信息：
kubectl rollout history deployment nginx-test --revision=1
驗證發布
kubectl rollout status deploy/nginx-test
回滾發布
kubectl rollout undo deployments/nginx-test
想回滾到指定版本呢？答案是k8s完美支持，並且還可以通過資源文件進行配置保留的歷史版次量
kubectl rollout undo deployment/nginx-test --to-revision=<版次>
原理
k8s分批次有序地進行着滾動更新，直到把所有舊的副本全部更新到新版本。實際上，k8s是通過兩個參數來精確地控制着每次滾動的pod數量：
-
maxSurge 滾動更新過程中運行操作期望副本數的最大pod數，但不能為0；也可以為百分數(eg：10%)。默認為25%。
-
maxUnavailable 滾動更新過程中不可用的最大pod數，但不能為0；也可以為百分數(eg：10%)。默認為25%。
重要參數 maxSurge與maxUnavailable
-
maxSurge: 1 表示滾動升級時會先啟動1個pod
-
maxUnavailable: 1 表示滾動升級時允許的最大Unavailable的pod個數
-
由於replicas為3,則整個升級,pod個數在2-4個之間
剖析部署概況
-
DESIRED 最終期望處於READY狀態的副本數
-
CURRENT 當前的副本總數
-
UP-TO-DATE 當前完成更新的副本數
-
AVAILABLE 當前可用的副本數
滾動過程是通過控制兩個副本集來完成的
kubernetes autoscale自動伸縮
使用 autoscaler 自動設置在kubernetes集群中運行的pod數量（水平自動伸縮）。
指定Deployment、ReplicaSet或ReplicationController，並創建已經定義好資源的自動伸縮器。使用自動伸縮器可以根據需要自動增加或減少系統中部署的pod數量。
$ autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
示例
使用默認的自動伸縮策略，指定目標CPU使用率，使其Pod數量在2到10之間。
kubectl autoscale deployment/nginx-test --min=2 --max=10
使其Pod的數量介於1和5之間，CPU使用率維持在80％。
kubectl autoscale deploy/nginx-test --max=5 --cpu-percent=80
autoscale 字段說明
| 名稱 | Shorthand | 默認值 | 使用說明 |
|---|---|---|---|
| allow-missing-template-keys | true | 如果值為真，則忽略模板中的任何錯誤。僅僅能夠應用到golang和jsonpath輸出格式。 | |
| cpu-percent | -1 | The target average CPU utilization (represented as a percent of requested CPU) over all the pods. If it’s not specified or negative, a default autoscaling policy will be used. | |
| dry-run | false | If true, only print the object that would be sent, without sending it. | |
| filename | f | [] | Filename, directory, or URL to files identifying the resource to autoscale. |
| generator | horizontalpodautoscaler/v1 | The name of the API generator to use. Currently there is only 1 generator. | |
| max | -1 | The upper limit for the number of pods that can be set by the autoscaler. Required. | |
| min | -1 | The lower limit for the number of pods that can be set by the autoscaler. If it’s not specified or negative, the server will apply a default value. | |
| name | The name for the newly created object. If not specified, the name of the input resource will be used. | ||
| output | o | Output format. One of: json | |
| record | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | |
| recursive | R | false | Process the directory used in -f, –filename recursively. Useful when you want to manage related manifests organized within the same directory. |
| save-config | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | |
| template | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview]. |