preface

The software world is moving faster than ever. To remain competitive, new software versions need to be launched as quickly as possible without disrupting active user access and impacting the user experience. More and more enterprises have migrated their applications to Kubernetes.

There are several different ways to publish an application in Kubernetes, so it is important to choose the right publishing strategy in order to keep the application running smoothly during the upgrade. This article will explain how to update an image in Kubernetes using rolling updates.

The principle of

The policy is defined as Deployment of the RollingUpdate. Rolling update deploys a new version of the application step by step by replacing each instance. Until all instances are replaced, the new version and the old version may exist at the same time.

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0			Determines the maximum number of POD instances that can be exceeded beyond the number of copies expected in the configuration
      maxUnavailable: % 25	Determines how many POD instances can be allowed to be unavailable during a rolling upgrade relative to the desired number of copies
Copy the code

The following figure shows the update policy execution results

practice

Upgrade the application using Kubernetes native mode

To prepare

image

bebullish/demo:v1
bebullish/demo:v2
Copy the code

deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-dp
spec:
  selector:
    matchLabels:
      app: demo
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: demo
    spec: 
      containers:
      - name: demo
        image: bebullish/demo:v1
        ports:
        - containerPort: 8080
Copy the code

service

apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  selector:
    app: demo
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
Copy the code

Save the above deployment and service as a YAML file, use kubectl apply -f to create the YAML resource, wait for the successful creation, use kubectl get SVC to obtain the external-IP.

test

Curl curl curl curl curl curl curl curl curl curl curl curl

curl -X GET http://${EXTERNAL-IP}
Copy the code

upgrade

Before the upgrade, run the command to view the image update process

while true; do curl -X GET http://${EXTERNAL-IP} ; done
Copy the code

Update image

kubectl set image deployment demo-dp demo=bebullish/demo:v2
Copy the code

See the log

The request flow

conclusion

First of all, it can be found that during the update process, the program is always available. After the appearance of v2 version, the log of V1 version will also appear, indicating that V1 and V2 versions exist at the same time during this period. When all the POD of V2 version is in the ready state, As you can see, all requests are v2 versions.

Upgrade applications using CODING CD

Configure products

To use an official docker image, you need to start with docker.io

Configure YAML and bound artifacts

deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-dp
spec:
  selector:
    matchLabels:
      app: demo
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: demo
    spec: 
      containers:
      - name: demo
        image: docker.io/bebullish/demo
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 30           Delay detection for 30 seconds to better observe the update process
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 30           Delay detection for 30 seconds to better observe the update process
          periodSeconds: 5
      terminationGracePeriodSeconds: 1      The pod is forcibly killed after being in Terminating state
Copy the code

In the Manifest phase, select the deployment (Manifest) and enter the yamL file above (mainly adding ready probes and live probes), where the version of the image needs to be removed and the artifacts configured before the artifacts to bind are selected. After this configuration, the version is passed in dynamically each time it is executed.

Release products

Select the application and deployment process and enter version V1.

View the results

After a short wait, you can see the published resources in the deployment console.

Updating the Image Version

Publish again and enter version v2.

The update process

You can see that at this point, one pod of v2 version is starting, while all the PODS of V1 version are ready.

One pod of V2 version is ready and a new one is being started. Meanwhile, one pod of V1 version has been shut down and the other two pods are still ready.

Two of the V2 pods are ready and the last one is being started. Meanwhile, two of the V1 pods have been shut down and the other one is still ready.

All pod versions of V2 are ready, and all POD versions of V1 have been shut down. At this point, a rolling update is over.

conclusion

Using Kubernetes native way to achieve rolling update is more simple and convenient, but also prone to error (manual), recommend using the CD function provided by Coding.net, configuration once, permanent use. Not only can you directly observe the POD update process, but also provides a very rich CD function, recommended use oh ~

Refer to the article

Kuerbenetes

CODING continuous deployment

[Tencent cloud native] cloud said new, cloud research new technology, cloud travel new live, cloud appreciation information, scan code to pay attention to the public account of the same name, timely access to more dry goods!!