Location>code7788 >text

K8s Advanced Deployment Update & Rollback

Popularity：951 ℃/2025-05-05 20:59:11

Update Overview

Update refers to the process of modifying the configuration, mirror version, etc. of applications managed by Deployment and applying them to the cluster. By updating the Deployment, you can upgrade application functions, fix vulnerabilities, adjust resource allocation and other operations.

Update trigger conditions

  • Mirror Version Change: A new mirror version is usually used when you need to update the app's features or fix known issues. For example, update from nginx:1.14.2 to nginx:1.16.1.

  • Configuration parameter modification: Adjust the application's environment variables, resource requests and restrictions and other configuration information. For example, increase the memory limit of the container.

  • Pod template changes: Modify metadata such as labels, annotations, etc. in the Pod template.

Deployment update strategy

RollingUpdate

This is the default update policy of Deployment, which enables zero downtime updates. It completes the update by gradually replacing the pods, always keeping a certain number of pods running, ensuring that the service is available throughout the update process.

How RollingUpdate works

  • Create a new ReplicaSet, using the new Pod template.
  • Gradually reduce the number of pods in the old ReplicaSet while increasing the number of pods in the new ReplicaSet.
  • After each new pod is created, the old pod will be terminated only after passing a health check (Readiness Probe).

Implementation method

By definitionstrategyfields are implemented, andstrategyThere are two core fields under the field:

  • maxUnavailable: Defines the maximum number or percentage of unavailable pods allowed during the update process. The default value is 25%.
  • maxSurge: Defines the maximum number or percentage of pods that are allowed to be created that exceed the expected number of replicas during the update process. The default value is 25%.

Recreate

This strategy will first delete all old pods and then create all new pods at once. During the update, the service will be temporarily unavailable, so it is suitable for development environments or tolerate temporary interrupts.

Deployment's RollingUpdate implementation

This is the default update policy of Deployment, which enables zero downtime updates. It completes the update by gradually replacing the pods, always keeping a certain number of pods running, ensuring that the service is available throughout the update process.

Define an old version of the application

First create a Depoyment, define the image of the Pod as nginx:1.14.1, and then upgrade the image version of nginx to nginx:1.16.1

## Define resource files
 [root@master01 ~/deploy]# cat
 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: deployment-nginx
   namespace: default
 spec:
   # Define update policy
   Strategy:
     # Specify the type as RollingUpdate (rolling update)
     type: RollingUpdate
     # This field will be defined when the update policy type is RollingUpdate, otherwise an error will be reported.
     rollingUpdate:
       # Define the maximum number of pods created that exceeds the expected number of replicas. Set to 3 here, indicating that the maximum number of pods will be created.
       maxSurge: 3
       # Define the maximum number of unavailable pods. Set it to 2 here, indicating that the maximum number of unavailable pods is 2
       maxUnavailable: 2
   replicas: 10
   selector:
     matchLabels:
       app: nginx
   template:
     metadata:
       name: pod-nginx
       labels:
         app: nginx
     spec:
       containers:
       - name: container-nginx
         image: nginx:1.14.1
       restartPolicy: Always
 # Create deploy
 [root@master01 ~/deploy]# kubectl apply -f
 /deployment-nginx created

 # Check the corresponding resource creation situation
 [root@master01 ~/deploy]# kubectl get deploy
 NAME READY UP-TO-DATE AVAILABLE AGE
 deployment-nginx 10/10 10 10 6s
 [root@master01 ~/deploy]# kubectl get rs
 NAME DESIRED CURRENT READY AGE
 deployment-nginx-6d84458cd8 10 10 10 11s
 [root@master01 ~/deploy]# kubectl get po | grep deploy
 deployment-nginx-6d84458cd8-2km57 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-dqtsf 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-dtsx7 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-fr5zg 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-hcxz4 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-jm68h 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-nt8zw 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-pjkmd 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-tvxxh 1/1 Running 0 18s
 deployment-nginx-6d84458cd8-x7vls 1/1 Running 0 18s

Update to new version of the application

There are two ways to trigger the update of the Deployment:

  • passkubectl setTo trigger (not recommended)
    grammar:
kubectl set image <type-name> <container-name>=<image:tag>

 Parameter description:
 type-name: Specify the name of the type, the name field in the corresponding metadata, such as deployment/deploy-nginx
 container-name: container name, corresponding to containers name field, such as nginx
 image:tag: indicates the image and version to be updated

Example:

kubectl set image deployment/deploy-nginx container-nginx=nginx:1.16.1
  • Triggered by modifying the resource configuration file (recommended)

We modify its resource configuration file here to trigger

# Modify the configuration file
 [root@master01 ~/deploy]# cat
 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: deployment-nginx
   namespace: default
 spec:
   # Define update policy
   Strategy:
     # Specify the type as RollingUpdate (rolling update)
     type: RollingUpdate
     # This field will be defined when the update policy type is RollingUpdate, otherwise an error will be reported.
     rollingUpdate:
       # Define the maximum number of pods created that exceeds the expected number of replicas. Set to 3 here, indicating that the maximum number of pods will be created.
       maxSurge: 3
       # Define the maximum number of unavailable pods. Set it to 2 here, indicating that the maximum number of unavailable pods is 2
       maxUnavailable: 2
   replicas: 10
   selector:
     matchLabels:
       app: nginx
   template:
     metadata:
       name: pod-nginx
       labels:
         app: nginx
     spec:
       containers:
       - name: container-nginx
         # Update the image version to 1.16.1
         image: nginx:1.16.1
       restartPolicy: Always

 # Reapply it
 [root@master01 ~/deploy]# kubectl apply -f
 /deployment-nginx configured

Check out the changes in Pod and ReplicaSet

Check out the changes in Pod

# When I first checked the pod, I found that there were 13 pods in total.
 # The number of copies we define is 10, and the value of maxSurge is 3
 # The number of available pods is 8 (that is, the number of unavailable pods is 2, corresponding to the maxUnavailable setting)
 # Through the AGE field, the old version of the Pod still exists
 [root@master01 ~/deploy]# kubectl get po | grep deploy
 NAME READY STATUS RESTARTS AGE
 deployment-nginx-6d84458cd8-2km57 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-dqtsf 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-fr5zg 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-hcxz4 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-jm68h 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-pjkmd 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-tvxxh 1/1 Running 0 17m
 deployment-nginx-6d84458cd8-x7vls 1/1 Running 0 17m
 deployment-nginx-d8898b99d-5pxt8 0/1 ContainerCreating 0 7s
 deployment-nginx-d8898b99d-7z4pf 0/1 ContainerCreating 0 7s
 deployment-nginx-d8898b99d-gttz8 0/1 ContainerCreating 0 7s
 deployment-nginx-d8898b99d-j55fp 0/1 ContainerCreating 0 7s
 deployment-nginx-d8898b99d-jfpdt 0/1 ContainerCreating 0 7s


 # Finally check the pod, and find that the final number of pods is 10, and all updates are successful (viewed through the AGE field)
 [root@master01 ~/deploy]# kubectl get po | grep deploy
 NAME READY STATUS RESTARTS AGE
 deployment-nginx-d8898b99d-2szcx 1/1 Running 0 18s
 deployment-nginx-d8898b99d-5pxt8 1/1 Running 0 37s
 deployment-nginx-d8898b99d-7k44g 1/1 Running 0 17s
 deployment-nginx-d8898b99d-7z4pf 1/1 Running 0 37s
 deployment-nginx-d8898b99d-gttz8 1/1 Running 0 37s
 deployment-nginx-d8898b99d-j55fp 1/1 Running 0 37s
 deployment-nginx-d8898b99d-jfpdt 1/1 Running 0 37s
 deployment-nginx-d8898b99d-kdf7x 1/1 Running 0 16s
 deployment-nginx-d8898b99d-lvpsw 1/1 Running 0 19s
 deployment-nginx-d8898b99d-zfxkf 1/1 Running 0 15s

Check out the changes in ReplicaSet:

# Found two rs resources, where deployment-nginx-6d84458cd8 is an old version of rs, and its number of copies is 0
 # deployment-nginx-d8898b99d is a new version of rs, and its number of copies is 10. This can verify that deploy rolling updates are implemented based on rs.
 [root@master01 ~/deploy]# kubectl get rs
 NAME DESIRED CURRENT READY AGE
 deployment-nginx-6d84458cd8 0 0 0 25m
 deployment-nginx-d8898b99d 10 10 10 8m46s

Deployment Recreate implementation

This strategy will first delete all old pods and then create all new pods at once. During the update, the service will be temporarily unavailable, so it is suitable for development environments or tolerate temporary interrupts.

Define an old version of the application

First create a Depoyment, define the image of the Pod as tomcat:8.0, and then upgrade the image version of tomcat to tomcat:9.0

## Define resource files
 [root@master01 ~/deploy]# cat
 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: deployment-tomcat
   namespace: default
 spec:
   # Define update policy
   Strategy:
     # Specify the type as Recreate (recreate)
     type: Recreate
   replicas: 10
   selector:
     matchLabels:
       app: tomcat
   template:
     metadata:
       name: pod-tomcat
       labels:
         app: tomcat
     spec:
       containers:
       - name: container-tomcat
         image: tomcat:8.0
       restartPolicy: Always

 # Apply it:
 [root@master01 ~/deploy]# kubectl apply -f
 /deployment-tomcat created

View pod

[root@master01 ~/deploy]# kubectl get po
NAME                                 READY   STATUS    RESTARTS   AGE
deployment-tomcat-85c65466c5-7vsms   1/1     Running   0          84s
deployment-tomcat-85c65466c5-bh9v9   1/1     Running   0          84s
deployment-tomcat-85c65466c5-bvhs9   1/1     Running   0          84s
deployment-tomcat-85c65466c5-czdsb   1/1     Running   0          84s
deployment-tomcat-85c65466c5-glq5m   1/1     Running   0          84s
deployment-tomcat-85c65466c5-k6xk7   1/1     Running   0          84s
deployment-tomcat-85c65466c5-mw8wz   1/1     Running   0          84s
deployment-tomcat-85c65466c5-tqtzb   1/1     Running   0          84s
deployment-tomcat-85c65466c5-wftgj   1/1     Running   0          84s
deployment-tomcat-85c65466c5-xxv2p   1/1     Running   0          84s

Update to new version of the application

Modify resource configuration file

[root@master01 ~/deploy]# cat
 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: deployment-tomcat
   namespace: default
 spec:
   # Define update policy
   Strategy:
     # Specify the type as Recreate (recreate)
     type: Recreate
   replicas: 10
   selector:
     matchLabels:
       app: tomcat
   template:
     metadata:
       name: pod-tomcat
       labels:
         app: tomcat
     spec:
       containers:
       - name: container-tomcat
         # Mirror version updated to 9.0
         image: tomcat:9.0
       restartPolicy: Always

 # Reapply the resource file
 [root@master01 ~/deploy]# kubectl apply -f
 /deployment-tomcat configured

Check out the changes in ReplicaSet and Pod

View Pod

# Found that all the pods are in the ContainerCreating state, and none are in Ready. Verify that Recreate deletes all the pods and then recreates them.
 [root@master01 ~/deploy]# kubectl get po
 NAME READY STATUS RESTARTS AGE
 deployment-tomcat-7ddf96c4d8-4dcmh 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-4w8dd 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-8z95r 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-9dgph 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-9wgr4 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-kt7nw 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-lrgfm 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-mpmb9 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-vvbtb 0/1 ContainerCreating 0 6s
 deployment-tomcat-7ddf96c4d8-w8knq 0/1 ContainerCreating 0 6s

View ReplicaSet

[root@master01 ~/deploy]# kubectl get rs
NAME                           DESIRED   CURRENT   READY   AGE
deployment-tomcat-7ddf96c4d8   10        10        10      27s
deployment-tomcat-85c65466c5   0         0         0       4m

Rollback Overview

Rollback refers to the operation of restoring the Deployment to a previous stable version when problems occur during the update process (such as application crashes, functional abnormalities, etc.). Kubernetes records the history of each update of the Deployment, so that you can roll back to the specified version at any time.

Rollback can also be understood as an update of Deployment. Rollback will also update the pod according to the relevant configuration in our resource configuration file.

Rollback operation

  • View update history: Usekubectl rollout history deployment <deployment-name>The command checks the update history of the Deployment, and each update will have a corresponding version number (Revision).

  • Roll back to the previous version: Usekubectl rollout undo deployment <deployment-name>The command rolls the Deployment to the previous stable version.

  • Roll back to the specified version: Usekubectl rollout undo deployment <deployment-name> --to-revision=<revision-number>The command rolls the Deployment to the specified version number.

  • Verify the rollback result: Usekubectl rollout status <deployment-name>The command checks the status after the rollback to ensure that the rollback operation is successful.

Rollback example

As an example above, roll back the version to 8.0

View the Deployment to be rolled back

[root@master01 ~/deploy]# kubectl get deploy
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
deployment-tomcat   10/10   10           10          9m46s

View historical version

existkubectl rollout historyIn the output of the command, the larger the version number, the newer the version

[root@master01 ~/deploy]# kubectl rollout history deploy/deployment-tomcat
 /deployment-tomcat
 #version #reason for change
 REVISION CHANGE-CAUSE
 1 <none> #Old version
 2 <none> #New version

Roll back to the specified version

[root@master01 ~/deploy]# kubectl rollout undo deployment deployment-tomcat --to-revision=1
/deployment-tomcat rolled back

View the rollback results

[root@master01 ~/deploy]# kubectl rollout status deploy deployment-tomcat
deployment "deployment-tomcat" successfully rolled out

View Pod

[root@master01 ~/deploy]# kubectl get po
NAME                                 READY   STATUS    RESTARTS   AGE
deployment-tomcat-85c65466c5-5xbcn   1/1     Running   0          42s
deployment-tomcat-85c65466c5-7tb56   1/1     Running   0          42s
deployment-tomcat-85c65466c5-dpklc   1/1     Running   0          42s
deployment-tomcat-85c65466c5-k8sd6   1/1     Running   0          42s
deployment-tomcat-85c65466c5-m5kqt   1/1     Running   0          42s
deployment-tomcat-85c65466c5-rlvrz   1/1     Running   0          42s
deployment-tomcat-85c65466c5-szczs   1/1     Running   0          42s
deployment-tomcat-85c65466c5-vt89t   1/1     Running   0          42s
deployment-tomcat-85c65466c5-xrct9   1/1     Running   0          42s
deployment-tomcat-85c65466c5-xtpt6   1/1     Running   0          42s
<Previous Next>