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]. |