Author: xidianwangtao@gmail.com
摘要: Kubernetes Deployment滚动更新机制不同于ReplicationController rolling update,Deployment rollout还提供了滚动进度查询,滚动历史记录,回滚等能力,无疑是使用Kubernetes进行应用滚动发布的首选。本博文,将带你聊聊那些容易被大家忽略或者误解的特性。
定义Deployment时与rolling update的相关项
以下面的frontend Deployment为例,重点关注.spec.minReadySeconds
,.spec.strategy.rollingUpdate.maxSurge
,.spec.strategy.rollingUpdate. maxUnavailable
。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: frontend
spec:
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3
maxUnavailable: 2
replicas: 25
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google-samples/gb-frontend:v4
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
# If your cluster config does not include a dns service, then to
# instead access environment variables to find service host
# info, comment out the 'value: dns' line above, and uncomment the
# line below:
# value: env
ports:
- containerPort: 80
.spec.minReadySeconds
: 新创建的Pod状态为Ready持续的时间至少为.spec.minReadySeconds
才认为Pod Available(Ready)。.spec.strategy.rollingUpdate.maxSurge
: specifies the maximum number of Pods that can be created over the desired number of Pods. The value cannot be 0 if MaxUnavailable is 0. 可以为整数或者百分比,默认为desired Pods数的25%. Scale Up新的ReplicaSet时,按照比例计算出允许的MaxSurge,计算时向上取整(比如3.4,取4)。.spec.strategy.rollingUpdate.maxUnavailable
: specifies the maximum number of Pods that can be unavailable during the update process. The value cannot be 0 if maxSurge is 0.可以为整数或者百分比,默认为desired Pods数的25%. Scale Down旧的ReplicaSet时,按照比例计算出允许的maxUnavailable,计算时向下取整(比如3.6,取3)。
因此,在Deployment rollout时,需要保证Available(Ready) Pods数不低于 desired pods number - maxUnavailable
; 保证所有的Pods数不多于 desired pods number + maxSurge
。
滚动更新的流程
Note: A Deployment’s rollout is triggered if and only if the Deployment’s pod template (that is, .spec.template) is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
我们继续以上面的Deployment为例子,并考虑最常用的情况–更新image(发布新版本):
kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record
set image之后,导致Deployment’s Pod Template发生变化,就会触发rollout。我们只考虑RollingUpdate策略(Kubernetes还支持ReCreate更新策略)。通过kubectl get rs -w
来watch ReplicaSet的变化。
[root@master03 ~]# kubectl get rs -w
NAME DESIRED CURRENT READY AGE
frontend-3114648124 25 25 25 14m
frontend-3099797709 0 0 0 1h
frontend-3099797709 0 0 0 1h
frontend-3099797709 3 0 0 1h
frontend-3114648124 23 25 25 17m
frontend-3099797709 5 0 0 1h
frontend-3114648124 23 25 25 17m
frontend-3114648124 23 23 23 17m
frontend-3099797709 5 0 0 1h
frontend-3099797709 5 3 0 1h
frontend-3099797709 5 5 0 1h
frontend-3099797709 5 5 1 1h
frontend-3114648124 22 23 23 17m
frontend-3099797709 5 5 2 1h
frontend-3114648124 22 23 23 17m
frontend-3114648124 22 22 22 17m
frontend-3099797709 6 5 2 1h
frontend-3114648124 21