Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to achieve blue and green release based on Kubernetes. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Preface

The software world is faster than ever. In order to remain competitive, new software versions need to be launched as soon as possible without interrupting active user access and affecting 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 in order to keep the application providing services smoothly during the upgrade, it is very important to choose the right release strategy. The editor will explain how to update the image using blue and green updates in Kubernetes.

Principle

The blue-green release is that version 1 and version 2 will exist at the same time, and you can decide which version to use by controlling Service, also known as red-black deployment. Unlike rolling updates, version 2 (green) is deployed with version 1 (blue). After testing that the new version meets the requirements, the Service object is updated to send traffic to the new version by replacing the version label in label selector. The update process is shown in the following figure

Practice using Kubernetes native way to upgrade application preparation

Image

Bebullish/demo:v1bebullish/demo:v2

Deployment-v1

ApiVersion: apps/v1kind: Deploymentmetadata: name: demo-dp-v1spec: selector: matchLabels: app: demo version: v1 replicas: 3 template: metadata: labels: app: demo version: v1spec: containers:-name: demo image: bebullish/demo:v1 ports:-containerPort: 8080

Deployment-v2

ApiVersion: apps/v1kind: Deploymentmetadata: name: demo-dp-v2spec: selector: matchLabels: app: demo version: v2 replicas: 3 template: metadata: labels: app: demo version: v2spec: containers:-name: demo image: bebullish/demo:v2 ports:-containerPort: 8080

Service

ApiVersion: v1kind: Servicemetadata: name: demo-servicespec: selector: app: demo version: v1 # Control traffic towards type: LoadBalancer ports:-port: 80 targetPort: 8080 protocol: TCP by changing version

Save the above deployment-v1 and service as a yaml file, use the kubectl apply-f command to create the yaml resource, wait for the creation to succeed, and then use kubectl get svc to get the EXTERNAL-IP.

test

If you test with a browser, you will find that the same pod name is returned for each call, because the request made by the browser contains keepAlive, so you need to use curl to ensure that each request is recreated.

Curl-X GET http://${EXTERNAL-IP}

Upgrade

Save the above deployment-v2 as a yaml file, use the kubectl apply-f command to create yaml resources, and execute the command before switching traffic to view the image update process.

While true; do curl-X GET http://${EXTERNAL-IP}; done

After waiting for the deployment-v2 to be created successfully, switch the traffic by changing the version value of service to v2

Kubectl edit service demo-service View Log

Request traffic

Conclusion

First of all, it can be found that the program remains available all the time during the update process. After the v2 version is successfully deployed, all requests are still v1 version. When the traffic is switched, the v2 version log appears immediately, and the v1 version log does not appear. It means that the traffic is switched at one time. If you need to roll back, you only need to switch the traffic back to v1 version.

Use CODING CD to upgrade application creation service

Service

ApiVersion: v1kind: Servicemetadata: name: demo-servicespec: selector: createBy: demo-service # the tag entered here will be added to the corresponding ReplicaSet type: LoadBalancer ports:-port: 80 targetPort: 8080 protocol: TCP

Note here that the service should not match any resources after it is created, that is, the endpoint is empty, and label createBy: demo-service will be added to the ReplicaSet when the deployment process is executed later, which determines the direction of the traffic.

You can see the demo-service after the deployment is successful

Configuration product

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

Configure yaml and bind artifacts

ReplicaSet

ApiVersion: apps/v1kind: ReplicaSetmetadata: name: demo-rsspec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers:-image: docker.io/bebullish/demo name: demo ports:-containerPort: 8080

Select deployment (Manifest) in the stage, and enter the above yaml file (currently, only ReplicaSet is supported in the release policy option). Here, you need to delete the version of the image and configure the product before selecting the product to be bound. After this configuration, the version is passed in dynamically each time it is executed.

Blue-green (red-black) release configuration

Check below to let the CODING deployment console manage ingress traffic, then select the namespace where demo-service is located (I am under the namespace marlon here), select demo-service, select Red/Black (Blue/Green) for policy, and save it.

Release product

Select the application and deployment process and enter version v1.

View the result

After waiting for a short while, you can see the published resources in the deployment console.

Update the mirror version

Execute the release again, and enter the version v2.

Renewal principle

The blue-green release based on CODING CD is slightly different from the general blue-green release. As soon as the v2 version of pod is ready, it will receive traffic immediately, and when all v2 version pod is ready, v1 version pod will be disabled, and all traffic will be sent to v2 version to complete the update.

Note: in the blue and green press conference based on CODING CD, both v1 version and v2 version get traffic, depending on the ready probe of pod. Once v2 version pod is ready, it will get traffic, so it is necessary to design a reasonable ready probe to minimize the time difference between v1 version and v2 version.

The above is the release of blue and green based on Kubernetes shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.