Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to achieve grayscale release based on KubeSphere based on Ingress-Nginx. Many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

In the grayscale publishing example of Bookinfo microservice, KubeSphere implements grayscale publishing of Bookinfo microservice sample application based on Istio. Some users said that their project has not been on Istio, how to achieve grayscale release?

In Ingress-Nginx (version 0.21.0), a new Canary feature has been introduced, which can be used to configure multiple back-end services for gateway entrances, and a specified annotation can be used to control the distribution of traffic among multiple back-end services. KubeSphere upgraded the Project Gateway (Ingress Controller) version to 0.24.1 in version 2.0.2 to support grayscale publishing based on Ingress-Nginx.

The editor will directly introduce and demonstrate grayscale publishing based on KubeSphere using Application routing (Ingress) and Project Gateway (Ingress Controller).

Note: the sample yaml source files and codes used in this article have been uploaded to GitHub, and you can clone them locally for easy reference.

Introduction to Ingress-Nginx Annotation

KubeSphere implements the gateway of the project based on Nginx Ingress Controller, which acts as the external traffic entrance of the project and the reverse proxy of each service in the project. Ingress-Nginx supports configuring Ingress Annotations to achieve grayscale publishing and testing in different scenarios, which can meet business scenarios such as canary release, blue-green deployment and AameB testing.

Nginx Annotations supports the following four Canary rules:

Nginx.ingress.kubernetes.io/canary-by-header: traffic segmentation based on Request Header, suitable for grayscale publishing and A _ hand B testing. When Request Header is set to always, the request will be sent all the way to the Canary version; when Request Header is set to never, the request will not be sent to the Canary entry; for any other Header value, Header will be ignored and the request will be compared with other canary rules by priority.

Nginx.ingress.kubernetes.io/canary-by-header-value: the value of the Request Header to match, which is used to tell Ingress to route the request to the service specified in Canary Ingress. When Request Header is set to this value, it will be routed to the Canary portal. This rule allows users to customize the value of Request Header, which must be used with the previous annotation (that is, canary-by-header).

Nginx.ingress.kubernetes.io/canary-weight: traffic segmentation based on service weight, suitable for blue-green deployment. The weight range is 0-100 to route the request to the service specified in Canary Ingress by percentage. A weight of 0 means that the canary rule does not send any requests to the service entered by the Canary. A weight of 100 means that all requests will be sent to the Canary entry.

Nginx.ingress.kubernetes.io/canary-by-cookie: traffic segmentation based on Cookie, suitable for grayscale publishing and A _ hand B testing. The cookie used to notify Ingress to route the request to the service specified in the Canary Ingress. When the cookie value is set to always, it will be routed to the Canary entry; when the cookie value is set to never, the request will not be sent to the Canary entry; for any other value, cookie will be ignored and the request will be compared with other canary rules in priority.

Note: the canary rule is sorted as follows in order of priority:

Canary-by-header-> canary-by-cookie-> canary-weight

The above four annotation rules can be divided into the following two categories:

Weight-based Canary rules

Canary rules based on user request

Step 1: create a project and Production version of the application

1.1. Create an enterprise space (workspace) and project (namespace) in KubeSphere, which can be referred to as getting started with multi-tenant management. A sample project has been created below.

1.2. To create applications quickly, you can create workloads and services in a project by editing yaml, or by using the toolbox in the lower right corner of KubeSphere to open web kubectl and use the following command and yaml file to create a Production version of the application and expose it to outside the cluster. Create the Production version of deployment and service as follows.

$kubectl appy-f production.yaml-n ingress-demodeployment.extensions/production createdservice/production created

The yaml file used is as follows:

Production.yaml

ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: productionspec: replicas: 1 selector: matchLabels: app: production template: metadata: labels: app: productionspec: containers:-name: production image: mirrorgooglecontainers/echoserver:1.10 ports:-containerPort: 8080 env:-name: NODE_NAME valueFrom: fieldRef: FieldPath: spec.nodeName-name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name-name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace-name: POD_IP valueFrom: fieldRef: FieldPath: status.podIP---apiVersion: v1kind: Servicemetadata: name: production labels: app: productionspec: ports:-port: 80 targetPort: 8080 protocol: TCP name: http selector: app: production

1.3. Create a Production version of Application routing (Ingress).

$kubectl appy-f production.ingress-n ingress-demoingress.extensions/production created

The yaml file used is as follows:

Production.ingress

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: production annotations: kubernetes.io/ingress.class: nginxspec: rules:-host: kubesphere.io http: paths:-backend: serviceName: production servicePort: 80 step 2: access the Production version of the application

2.1. At this point, under KubeSphere UI's enterprise space demo-workspace, you can see all the resources under the ingress-demo project.

Deployment

Service

Ingress

2.2. To access the Production version of the application, you need to make sure that the gateway is enabled for the current project, and the gateway is opened under public network access. The type is NodePort.

2.3. Visit the Production version of the application as follows.

$curl kubesphere.io:30205Hostname: production-6b4bb8d58d-7r889Pod Information: node name: ks-allinone pod name: production-6b4bb8d58d-7r889 pod namespace: ingress-demo pod IP: 10.233.87.165Server values: server_version=nginx: 1.12.2-lua: 10010Request Information: client_address=10.233.87.225 method=GET real path=/ query= request_version=1.1 Request_scheme=http request_uri= http://kubesphere.io:8080/Request Headers: accept=*/* host=kubesphere.io:30205 user-agent=curl/7.29.0apiVersion: extensions/v1beta1 x-forwarded-for=192.168.0.88 x-forwarded-host=kubesphere.io:30205 x-forwarded-port=80 x-forwarded-proto=http x-original-uri=/ x-real-ip=192.168. 0.88 x-request-id=9596df96e994ea05bece2ebbe689a2cc x-scheme=httpRequest Body:-no body in request- step 3: create a Canary version

Refer to the production.yaml file of the above Production version, and then create a Canary version of the application, including a Canary version of deployment and service (for quick demonstration, you only need to replace the keyword production in the deployment of production.yaml and service with canary, which may involve business code changes in the actual scenario).

Step 4: Ingress-Nginx Annotation rules are based on weight (Weight)

A typical application scenario for weight-based traffic segmentation is blue-green deployment, which can be achieved by setting the weight to 0 or 100. For example, you can set the Green version as the main section and configure the portal for the Blue version to Canary. Initially, the weight is set to 0, so traffic is not proxied to the Blue version. Once the new version is tested and verified successfully, the weight of the Blue version can be set to 100, that is, all traffic will shift from the Green version to Blue.

4.1. Use the yaml file of the following canary.ingress to create a weight-based version of Canary Application routing (Ingress).

Note: to enable the grayscale publishing mechanism, you first need to set nginx.ingress.kubernetes.io/canary: "true" to enable Canary. The Canary version of the following Ingress example uses annotation rules for traffic segmentation based on weight, and sends 30% of the traffic requests to the Canary version.

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "30" spec: rules:-host: kubesphere.io http: paths:-backend: serviceName: canary servicePort: 80

4.2. Access the domain name of the application.

Note: after the Canary version of the application is split based on the weight (30%), the probability of accessing the Canary version is close to 30%, and the traffic proportion may fluctuate in a small range.

Based on Request Header

4.3. The typical application scenario of traffic segmentation based on Request Header is grayscale release or A _ hand B test scenario. Refer to the following screenshot to add an annotation nginx.ingress.kubernetes.io/canary-by-header to the Canary version of Ingress in KubeSphere: canary (the value of annotation here can be any value), so that the current Ingress implementation can split traffic based on Request Header.

Note: Canary rules are sorted as follows in the order of priority canary-by-header-> canary-by-cookie-> canary-weight, so the original canary-weight rules will be ignored in the following cases.

4.4. Add different Header values to the request to access the domain name of the application again.

Description:

To give two examples, as mentioned at the beginning, when Request Header is set to never or always, the request will not be or will always be sent to the Canary version

For any other Header value, Header is ignored and the request is compared with other Canary rules by priority (the following second request has made the weight based on 30% as the first priority).

4.5. At this point, you can add a nginx.ingress.kubernetes.io/canary-by-header-value: user-value based on the previous annotation (that is, canary-by-header). Used to notify Ingress to route the request to the service specified in the Canary Ingress.

4.6. The domain name of the application is accessed as follows, and when Request Header meets this value, all requests are routed to the Canary version (this rule allows users to customize the value of Request Header).

Based on Cookie

4.7. Similar to Request Header-based annotation regulatory rules. For example, in the Canary B test scenario, you need to allow users in Beijing to access the version. Then when the annotation of cookie is set to nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing", the backend can check the login user request, and set the value of cookie users_from_Beijing to always if the user's access source is from Beijing, so as to ensure that Beijing users only access the Canary version.

Summary

The grayscale release can ensure the stability of the whole system, and the problems of the new version can be tested, found and adjusted at the initial gray level to ensure its influence. This paper demonstrates and illustrates the grayscale publishing based on KubeSphere using application routing (Ingress) and project gateway (Ingress Controller) through several examples, and introduces four kinds of Annotation of Ingress-Nginx in detail. Users who have not yet used Istio can easily realize grayscale publishing and canary publishing with the help of Ingress-Nginx.

After reading the above, do you have any further understanding of how KubeSphere implements grayscale publishing based on Ingress-Nginx? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.