Rolling upgrade with kubernetes

Rolling update can make the service upgrade almost seamlessly and smoothly, that is, the update of the application can be completed without stopping the external service.

The difference between replication controller and deployment

replication controller

Replication Controller is a core content of Kubernetes. After the application is hosted on Kubernetes, it needs to ensure that the application can run continuously. Replication Controller is the key to this guarantee. The main functions are as follows:

Ensure the number of pods: It will ensure that the specified number of pods are running in Kubernetes. If there are less than the specified number of pods, the Replication Controller will create new ones, otherwise it will delete the redundant ones to keep the number of pods unchanged.
Make sure pods are healthy: When pods are unhealthy, run wrong, or fail to provide services, Replication Controller will also kill unhealthy pods and recreate new ones.
Elastic scaling: During peak or low-peak business hours, the Replication Controller can dynamically adjust the number of pods to improve resource utilization. At the same time, configure the corresponding monitoring function (Hroizontal Pod Autoscaler), which will automatically obtain the overall resource usage of the Pod associated with the Replication Controller from the monitoring platform on a regular basis to achieve automatic scaling.
Rolling upgrade: Rolling upgrade is a smooth upgrade method. Through the strategy of gradual replacement, the stability of the overall system is ensured. When the upgrade is initialized, problems can be discovered and solved in time to avoid the continuous expansion of problems.

Deployment

Deployment is also a core content of Kubernetes, and its main responsibility is also to ensure the number and health of pods. 90% of the functions are exactly the same as Replication Controller, which can be regarded as a new generation of Replication Controller. However, it has new features beyond Replication Controller:

All functions of Replication Controller: Deployment inherits all functions of Replication Controller described above.
Event and Status View: You can view the detailed progress and status of the Deployment's upgrade.
Rollback: When problems are found when upgrading pod images or related parameters, you can use the rollback operation to roll back to the last stable version or a specified version.
Version record: Every operation on Deployment can be saved for subsequent possible rollback.
Pause and Start: For each upgrade, it is possible to pause and start at any time.
Various upgrade schemes: Recreate: delete all existing pods and recreate new ones; RollingUpdate: rolling upgrade, a strategy of gradual replacement, and support more additional parameters during rolling upgrade, such as setting the maximum number of unavailable pods, the minimum upgrade interval, etc.

Common commands for deployment

View deployment status

kubectl rollout status deployment/review-demo  --namespace=scm
kubectl describe deployment/review-demo  --namespace=scm

or this way of writing

kubectl rollout status deployments review-demo --namespace=scm
kubectl describe deployments review-demo  --namespace=scm

upgrade

kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1 --namespace=scm

kubectl edit deployment/review-demo --namespace=scm

Edit the value of .spec.template.spec.containers[0].image

Terminate upgrade

kubectl rollout pause deployment/review-demo --namespace=scm

continue to upgrade

kubectl rollout resume deployment/review-demo --namespace=scm

rollback

kubectl rollout undo deployment/review-demo --namespace=scm

View deployments version

kubectl rollout history deployments --namespace=scm

roll back to the specified version

kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm

Upgrade history

kubectl describe deployment/review-demo  --namespace=scm
Name:     review-demo
Namespace:    scm
CreationTimestamp:  Tue, 31 Jan 2017 16:42:01 +0800 Labels: app=review-demo Selector: app=review-demo Replicas: 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 1 max unavailable, 1 max surge OldReplicaSets: <none> NewReplicaSet: review-demo-2741031620 (3/3 replicas created) Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 1 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 2 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 2 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 1 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 3 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 0

deployment file

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: review-demo
 namespace: scm  labels:  app: review-demo spec:  replicas: 3 # minReadySeconds: 60 #滚动升级时60s后认为该pod就绪  strategy:  rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间  maxSurge: 1 #滚动升级时会先启动1个pod  maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数  template:  metadata:  labels:  app: review-demo  spec:  terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号，可以用来正确、优雅地关闭应用,默认为30秒  containers:  - name: review-demo  image: library/review-demo:0.0.1-SNAPSHOT  imagePullPolicy: IfNotPresent  livenessProbe: #kubernetes认为该pod是存活的,不存活则需要重启  httpGet:  path: /health  port: 8080  scheme: HTTP  initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds  timeoutSeconds: 5  successThreshold: 1  failureThreshold: 5  readinessProbe: #kubernetes认为该pod是启动成功的  httpGet:  path: /health  port: 8080  scheme: HTTP  initialDelaySeconds: 30 ## equals to minimum startup time of the application  timeoutSeconds: 5  successThreshold: 1  failureThreshold: 5  resources: # keep request = limit to keep this container in guaranteed class  requests:  cpu: 50m  memory: 200Mi  limits:  cpu: 500m  memory: 500Mi  env:  - name: PROFILE  value: "test"  ports:  - name: http  containerPort: 8080

Description of several important parameters

maxSurge and maxUnavailable

maxSurge: 1 means that one pod will be started first during
the rolling upgrade maxUnavailable: 1 means the maximum number of Unavailable pods allowed during the rolling upgrade
Since the replicas is 3, the entire upgrade, the number of pods is between 2-4

terminationGracePeriodSeconds

k8s will send a SIGTERM signal to the application, which can be used to shut down the application gracefully and gracefully. The default is 30 seconds.

If you need to shut down more gracefully, you can use the configuration declaration of the pre-stop lifecycle hook provided by k8s, which will be executed before sending SIGTERM.

livenessProbe与readinessProbe

livenessProbe是kubernetes认为该pod是存活的，不存在则需要kill掉，然后再新启动一个，以达到replicas指定的个数。

readinessProbe是kubernetes认为该pod是启动成功的，这里根据每个应用的特性，自己去判断，可以执行command，也可以进行httpGet。比如对于使用java web服务的应用来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接连接上等等。对于spring boot应用，默认的actuator带有/health接口，可以用来进行启动成功的判断。

其中readinessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最少时间，livenessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最大时间+若干秒。

这几个参数配置好了之后，基本就可以实现近乎无缝地平滑升级了。对于使用服务发现的应用来说，readinessProbe可以去执行命令，去查看是否在服务发现里头应该注册成功了，才算成功。

doc

http://www.cnblogs.com/ilinuxer/p/6637214.html