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

This article will explain in detail how to achieve rolling release based on Kubernetes, the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge 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 for the application to provide services smoothly during the upgrade, it is very important to choose the right publishing strategy. The editor will explain how to update the image using scrolling updates in Kubernetes.

Principle

The policy is defined as the Deployment of RollingUpdate. Rolling updates gradually deploy new versions of applications by replacing instances one by one, and there will be both new and old versions until all instances are replaced.

Spec: replicas: 4 strategy: type: RollingUpdate rollingUpdate: maxSurge: 0 # determines the maximum number of pod instances allowed to exceed in addition to the expected number of replicas in the configuration maxUnavailable:% 25 # determines how many pod instances are allowed to be unavailable relative to the expected number of replicas during a rolling upgrade

The implementation result of the above update policy is shown in the following figure

Practice using Kubernetes native way to upgrade application preparation

Image

Bebullish/demo:v1bebullish/demo:v2

Deployment

ApiVersion: apps/v1kind: Deploymentmetadata: name: demo-dpspec: selector: matchLabels: app: 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

Service

ApiVersion: v1kind: Servicemetadata: name: demo-servicespec: selector: app: demo type: LoadBalancer ports:-port: 80 targetPort: 8080 protocol: TCP

Save the above deployment 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

Execute the command before upgrading to view the image update process

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

Update Mirror

Kubectl set image deployment demo-dp demo=bebullish/demo:v2 View Log

Request traffic

Conclusion

First of all, it can be found that during the update process, the program remains available all the time, and after the v2 version appears, there will also be a v1 version log, indicating that v1 and v2 versions exist at the same time. When the v2 version of pod is all ready, you can see that all requests are v2 version.

Use CODING CD to upgrade application configuration artifacts

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

Configure yaml and bind artifacts

Deployment

ApiVersion: apps/v1kind: Deploymentmetadata: name: demo-dpspec: selector: matchLabels: app: 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 In order to better observe the update process periodSeconds: 5 livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 30 # delay 30 seconds detection, in order to better observe the update process periodSeconds: 5 terminationGracePeriodSeconds: 1 # how long after being in the Terminating state, force to kill pod

Select deployment (Manifest) in the phase, and enter the above yaml file (mainly adding ready probe and survival probe). Here, you need to delete the mirrored version and configure the product before you need to bind the product. After this configuration, the version is passed in dynamically each time it is executed.

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.

Update process

You can see that at this time one of the v2 version of pod is starting, while the v1 version of pod is all ready.

One of the v2 versions of pod is ready and another new pod is being launched, while one pod of the v1 version has been turned off, while the other two pod are still in the ready state.

Two of the v2 pod are ready and the last new pod is being started, while two pod of the v1 version have been turned off and the other pod is still in the ready state.

The v2 version of pod is all ready, and the v1 version of pod has been shut down, so a rolling update is over.

It is more simple and convenient to use Kubernetes native method to implement scrolling updates, but it is also prone to errors (manual). It is recommended to use the CD feature provided by coding.net. Configure it once and use it permanently. You can not only observe the pod update process intuitively, but also provide very rich CD functions.

On how to achieve rolling release based on Kubernetes to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.