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

How to implement simple blue-green publishing and grayscale publishing in TKE cluster? in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Introduction of principle

We usually deploy the business using the workloads that come with Kubernetes, such as Deployment and StatefulSet. Each workload manages a set of Pod. Take Deployment as an example:

Usually, a corresponding Service,Service is created for each workload to match the back-end Pod through selector, and other services or externally can access the services provided by the back-end Pod by accessing the Service. To expose to the public, you can directly set the Service type to LoadBalancer,LB plug-in will automatically create a CLB (Tencent Cloud load balancer) as the traffic entry.

How to achieve blue and green release? Take Deployment as an example. Two different versions of Deployment are deployed in the cluster. Their Pod has a common label, but one label has a different value, which is used to distinguish different versions. Service uses selector to select the Pod of one version of Deployment, and changes the corresponding Deployment of the Service backend by changing the value of the label that determines the service version in the selector of Service, so that the service can be directly switched from one version to another, that is, blue-green release:

How to achieve grayscale publishing? Although we usually create a Service for each workload, Kubernetes does not restrict that the Service must correspond to the workload one by one, because the Service matches the backend Pod through selector. As long as the Pod of different workloads can be selected by the same selector, we can achieve the effect of a Service corresponding to multiple versions of the workload. Adjusting the number of copies of different versions of the workload is equivalent to adjusting the weight of different versions of services. Achieve grayscale publishing:

Use YAML to create resources

The examples in this article will use yaml to deploy workloads and create Service, which can be done in two ways.

Method 1: click YAML in the upper right corner of the TKE or EKS console to create resources, and then paste the yaml of the example in this article:

Method 2: save the yaml of the example as a file, and then use kubectl to specify the yaml file to create, such as: kubectl apply-f xx.yaml.

Deploy multi-version workloads

To achieve blue-green or grayscale publishing, we first need to deploy multiple versions of workloads in the cluster. Here, take a simple nginx as an example, deploy the first version:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-v1spec: replicas: 3 selector: matchLabels: app: nginx version: v1 template: metadata: labels: app: nginx version: v1spec: containers:-name: nginx image: "openresty/openresty:centos" ports:-name: http protocol: TCP containerPort: 80 volumeMounts :-mountPath: / usr/local/openresty/nginx/conf/nginx.conf name: config subPath: nginx.conf volumes:-name: config configMap: name: nginx-v1---apiVersion: v1kind: ConfigMapmetadata: labels: app: nginx version: v1 name: nginx-v1data: nginx.conf: |-worker_processes 1 Events {accept_mutex on; multi_accept on; use epoll; worker_connections 1024;} http {ignore_invalid_headers off; server {listen 80; location / {access_by_lua 'local header_str = ngx.say ("nginx-v1")' }}}

Deploy the second version:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-v2spec: replicas: 3 selector: matchLabels: app: nginx version: v2 template: metadata: labels: app: nginx version: v2spec: containers:-name: nginx image: "openresty/openresty:centos" ports:-name: http protocol: TCP containerPort: 80 volumeMounts :-mountPath: / usr/local/openresty/nginx/conf/nginx.conf name: config subPath: nginx.conf volumes:-name: config configMap: name: nginx-v2---apiVersion: v1kind: ConfigMapmetadata: labels: app: nginx version: v2 name: nginx-v2data: nginx.conf: |-worker_processes 1 Events {accept_mutex on; multi_accept on; use epoll; worker_connections 1024;} http {ignore_invalid_headers off; server {listen 80; location / {access_by_lua 'local header_str = ngx.say ("nginx-v2")' }}}

You can see the deployment on the console:

Achieve blue and green release

Create a LoadBalancer-type Service exposure service for our deployed Deployment, and specify a v1 version of the service:

ApiVersion: v1kind: Servicemetadata: name: nginxspec: type: LoadBalancer ports:-port: 80 protocol: TCP name: http selector: app: nginx version: v1

Test access:

$for i in {1.. 10}; do curl EXTERNAL-IP; done; # replace EXTERNAL-IP with Service's CLB IP address nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1

It is all the response of v1 version. Now we cut to v2 version, modify the selector of Service, and let it select the service of v2 version. If you change it in the console, find the corresponding Service first, and click Edit YAML:

Modify the selector section:

Selector: app: nginx version: v2

Or you can modify it directly with kubectl:

Kubectl patch service nginx-p'{"spec": {"selector": {"version": "v2"}}'

Test the access again:

$for i in {1.. 10}; do curl EXTERNAL-IP; done; # replace EXTERNAL-IP with Service's CLB IP address nginx-v2nginx-v2nginx-v2nginx-v2nginx-v2nginx-v2nginx-v2nginx-v2nginx-v2nginx-v2

It is all the response of v2 version, and the blue and green release has been realized successfully.

Realize grayscale publishing

Compared with the blue-green release, we delete the version tag from the selector and let Service select the Pod of both versions of the Deployment for the service that does not use the v1 version for the Deployment:

ApiVersion: v1kind: Servicemetadata: name: nginxspec: type: LoadBalancer ports:-port: 80 protocol: TCP name: http selector: app: nginx

Test access:

$for i in {1.. 10}; do curl EXTERNAL-IP; done; # replace EXTERNAL-IP with Service's CLB IP address nginx-v1nginx-v1nginx-v2nginx-v2nginx-v2nginx-v1nginx-v1nginx-v1nginx-v2nginx-v2

As you can see, half is a v1 response and the other half is a v2 response. Now let's adjust the copies of the v1 and v2 versions of Deployment, adjusting the v1 version to 1 copy and the v2 version to 4 copies.

You can operate through the console:

You can also operate through kubectl:

Kubectl scale deployment/nginx-v1-replicas=1kubectl scale deployment/nginx-v2-replicas=4

Then do the access test again:

$for i in {1... 10}; do curl EXTERNAL-IP; done; # replace EXTERNAL-IP with Service's CLB IP address nginx-v2nginx-v1nginx-v2nginx-v2nginx-v2nginx-v2nginx-v1nginx-v2nginx-v2nginx-v2 $for i in {1... 10}; do curl EXTERNAL-IP; done; # replace EXTERNAL-IP with Service's CLB IP address nginx-v2nginx-v1nginx-v2nginx-v2nginx-v2nginx-v2nginx-v1nginx-v2nginx-v2nginx-v2

As you can see, v1 version is returned only 2 times out of 10 visits, and the response ratio of v1 to v2 is the same as the number of copies, which is 1:4. Grayscale publishing is achieved by controlling the number of copies of different versions of the service.

This is the answer to the question on how to achieve simple blue-green and grayscale publishing in the TKE cluster. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.