RollingUpdate using kubernetes’ deployment

  kubernetes

Order

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

The difference between replication controller and deployment

replication controller

Replication Controller is one of the core contents of Kubernetes. After the application is hosted in Kubernetes, it is necessary to ensure that the application can run continuously. Replication Controller is the key of this guarantee. Its main functions are as follows:

  • Ensure pod Quantity: It will ensure that a specified number of PODs are running in Kubernetes. If the number of PODs is less than the specified number , Replication Controller will create a new one, otherwise, it will delete the surplus to ensure the number of PODs remains unchanged.

  • Ensure pod Health: When pod is unhealthy, running incorrectly, or unable to provide services, Replication Controller will also kill the unhealthy pod and create a new one.

  • Resilient scaling: during peak or low business periods, Replication Controller can dynamically adjust the number of pod to improve the utilization rate of resources. At the same time, configuring the corresponding monitoring function (Hroizontal Pod Autoscaler) will automatically obtain the overall resource usage of Replication Controller’s associated pod from the monitoring platform on a regular basis to achieve automatic scaling.

  • Rolling upgrade: Rolling upgrade is a smooth upgrade method, which ensures the stability of the overall system through a gradual replacement strategy. Problems can be found and solved in time during the initia li zation of upgrade to prevent the problems from expanding.

Deployment

Deployment is also a core content of Kubernetes. Its main responsibility is also to ensure the quantity and health of pod. 90% of its 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 the functions of Replication Controller: Deployment inherits all the functions of Replication Controller described above.

  • Event and Status View: You can view the detailed progress and status of the Deployment upgrade.

  • Rollback: When problems are found when upgrading pod image or related parameters, you can use rollback operation to roll back to the previous stable version or the specified version.

  • Version record: every Deployment operation can be saved for possible subsequent rollback.

  • Pause and Start: For each upgrade, you can pause and start at any time.

  • Various upgrade schemes: Recreate: delete all existing pod and create new ones; RollingUpdate: a strategy of rolling upgrade and gradual replacement. At the same time, when rolling upgrade, more additional parameters are supported, such as setting the maximum number of unavailable pod, 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

Or ..

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

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

Termination of upgrade

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

Continue 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

Rollback 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 a pod will be started first during rolling upgrade.
MaxUnavailable: 1 indicates the maximum number of PODs allowed for rolling upgrade.
Since replicas is 3, the number of pod is between 2 and 4 for the whole upgrade.

terminationGracePeriodSeconds

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

If more graceful shutdown is required, the configuration statement of pre-stop lifecycle hook provided by k8s can be used and will be executed before SIGTERM is sent.

LivenessProbe and readinessProbe

LivenessProbe is kubernetes thinks that the pod is alive. If it does not exist, it needs to be kill, and then a new one is started to reach the number specified by replicas.

ReadinessProbe is kubernetes’ belief that the pod was successfully started. here, according to the characteristics of each application, you can judge for yourself. you can execute command or httpGet. For example, for applications that use java web services, tomcat can not simply provide services to the outside world upon successful startup, but also wait for spring container initialization, database connection, etc. For spring boot applications, the default actuator has a /health interface, which can be used to judge the success of the boot.

In which readinessprobe.initialdelaysseconds can be set as the minimum time required for the system to start up completely, livenesprobe.initialdelaysseconds can be set as the maximum time required for the system to start up completely+several seconds.

After these parameters are configured, almost seamless and smooth upgrade can be basically realized. For applications that use service discovery, readinessProbe can execute commands to see if the registration in service discovery should be successful before it is considered successful.

doc