滚动升级

示例yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deploy

labels:

k8s-app: nginx-demo

spec:

selector:

matchLabels:

app: nginx

replicas: 3

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:1.7.9

ports:

- containerPort: 80

现在我们将刚刚保存的yaml文件中的nginx镜像修改为nginx:1.13.3，然后在spec下面添加滚动升级策略：

minReadySeconds: 5

strategy:

# indicate which strategy we want for rolling update

type: RollingUpdate

rollingUpdate:

maxSurge: 1

maxUnavailable: 1

最终yaml文件示例：

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deploy

labels:

k8s-app: nginx-demo

spec:

minReadySeconds: 5

strategy:

# indicate which strategy we want for rolling update

type: RollingUpdate

rollingUpdate:

maxSurge: 1

maxUnavailable: 1

selector:

matchLabels:

app: nginx

replicas: 3

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:1.7.9

ports:

- containerPort: 80

minReadySeconds:

Kubernetes在等待设置的时间后才进行升级

如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了

如果没有设置该值，在某些极端情况下可能会造成服务不正常运行

maxSurge:

升级过程中最多可以比原先设置多出的POD数量

例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

maxUnavaible:

升级过程中最多有多少个POD处于无法提供服务的状态

当maxSurge不为0时，该值也不能为0

例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。

然后执行命令：

$ kubectl apply -f nginx-deployment.yaml

deployment "nginx-deploy" configured

然后我们可以使用rollout命令：

查看状态：

$ kubectl rollout status deployment/nginx-deploy

Waiting for rollout to finish: 1 out of 3 new replicas have been updated..

deployment "nginx-deploy" successfully rolled out

暂停升级

$ kubectl rollout pause deployment

继续升级

$ kubectl rollout resume deployment

升级结束后，继续查看rs的状态：

$ kubectl get rs

NAME DESIRED CURRENT READY AGE

nginx-deploy-2078889897 0 0 0 47m

nginx-deploy-3297445372 3 3 3 42m

nginx-deploy-431080787 0 0 0 1h

根据AGE我们可以看到离我们最近的当前状态是：3，和我们的yaml文件是一致的，证明升级成功了。用describe命令可以查看升级的全部信息：

Name: nginx-deploy

Namespace: default

CreationTimestamp: Wed, 18 Oct 2017 16:58:52 +0800

Labels: k8s-app=nginx-demo

Annotations: deployment.kubernetes.io/revision=3

kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1beta1","kind":"Deployment","metadata":{"annotations":{},"labels":{"k8s-app":"nginx-demo"},"name":"nginx-deploy","namespace":"defa...

Selector: app=nginx

Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable

StrategyType: RollingUpdate

MinReadySeconds: 0

RollingUpdateStrategy: 25% max unavailable, 25% max surge

Pod Template:

Labels: app=nginx

Containers:

nginx:

Image: nginx:1.13.3

Port: 80/TCP

Environment:

Mounts:

Volumes:

Conditions:

Type Status Reason

---- ------ ------

Progressing True NewReplicaSetAvailable

Available True MinimumReplicasAvailable

OldReplicaSets:

NewReplicaSet: nginx-deploy-3297445372 (3/3 replicas created)

Events:

FirstSeen LastSeen Count From SubObjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

50m 50m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-2078889897 to 1

45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-2078889897 to 0

45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 1

39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 2

39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 2

38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 1

38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 3

38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 0

回滚Deployment

我们已经能够滚动平滑的升级我们的Deployment了，但是如果升级后的POD出了问题该怎么办？我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment就为我们提供了回滚机制。

首先，查看Deployment的升级历史：

$ kubectl rollout history deployment nginx-deploy

deployments "nginx-deploy"

REVISION CHANGE-CAUSE

1

2

3 kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true

从上面的结果可以看出在执行Deployment升级的时候最好带上record参数，便于查看历史版本信息。

默认情况下，所有通过kubectl xxxx --record都会被kubernetes记录到etcd进行持久化，这无疑会占用资源，最重要的是，时间久了，当你kubectl get rs时，会有成百上千的垃圾RS返回给你，那时你可能就眼花缭乱了。

上生产时，我们最好通过设置Deployment的.spec.revisionHistoryLimit来限制最大保留的revision number，比如15个版本，回滚的时候一般只会回滚到最近的几个版本就足够了。其实rollout history中记录的revision都和ReplicaSets一一对应。如果手动delete某个ReplicaSet，对应的rollout history就会被删除，也就是还说你无法回滚到这个revison了。

rollout history和ReplicaSet的对应关系，可以在kubectl describe rs $RSNAME返回的revision字段中得到，这里的revision就对应着rollout history返回的revison。

同样我们可以使用下面的命令查看单个revison的信息：

$ kubectl rollout history deployment nginx-deploy --revision=3

deployments "nginx-deploy" with revision #3

Pod Template:

Labels: app=nginx

pod-template-hash=3297445372

Annotations: kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml --record=true

Containers:

nginx:

Image: nginx:1.13.3

Port: 80/TCP

Environment:

Mounts:

Volumes:

假如现在要直接回退到当前版本的前一个版本：

$ kubectl rollout undo deployment nginx-deploy

deployment "nginx-deploy" rolled back

当然也可以用revision回退到指定的版本：

$ kubectl rollout undo deployment nginx-deploy --to-revision=2

deployment "nginx-deploy" rolled back

现在可以用命令查看Deployment现在的状态了。