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

This article shows you how to use Nginx Ingress to achieve canary release, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Nginx Ingress needs to be deployed as an Ingress Controller in the cluster, and a unified traffic entry is exposed. For more information, please see deploying Nginx Ingress on TKE.

In which publishing scenarios can Nginx Ingress be used?

What scenarios can be used to implement canary release using Nginx Ingress? This mainly depends on what strategy is used for traffic segmentation. Currently, Nginx Ingress supports three traffic segmentation strategies based on Header, Cookie and service weight, based on which the following two publishing scenarios can be implemented.

Scenario 1: give the new version of gray to some users

Suppose you run a set of Service A services that provide 7-tier services online, and then develop a new version of Service A' that you want to go online, but you don't want to replace the original Service A directly. You want to have a small number of users in grayscale first, and then gradually launch the new version when it is stable enough for a period of time, and finally smoothly take off the old version. At this time, you can use Nginx Ingress's policy of traffic segmentation based on Header or Cookie to publish. Businesses use Header or Cookie to identify different types of users. We configure Ingress to enable requests with specified Header or Cookie to be forwarded to the new version, while others are still forwarded to the old version, so that the new version will be grayscale to some users:

Scenario 2: cut a certain proportion of the traffic to the new version

Suppose you run a set of Service B services that provide 7-tier services online, and then fix some problems. You need a new version of Service B online in grayscale, but you don't want to replace the original Service B directly. Instead, you should first cut 10% of the traffic to the new version, wait for a period of time to be stable, and then gradually increase the traffic proportion of the new version until the old version is completely replaced, and finally slide down the old version. In order to achieve a certain proportion of the traffic to the new version:

Notes and instructions

We can achieve canary publishing by specifying some annotation supported by Nginx Ingress for Ingress resources. We need to create two Ingress for the service, one is a normal Ingress, and the other is an Ingress with nginx.ingress.kubernetes.io/canary: "true", a fixed annotation. Let's call it Canary Ingress, which generally represents a new version of the service. Combined with another annotation for traffic segmentation strategy, canary publishing in multiple scenarios can be realized. Here is a detailed description of these annotation:

Nginx.ingress.kubernetes.io/canary-by-header: if the request header contains the header name specified here and the value is always, the request will be forwarded to the corresponding backend service defined by the Ingress; if the value is never, it will not be forwarded and can be used to roll back to the old version; if it is other values, the annotation will be ignored.

Nginx.ingress.kubernetes.io/canary-by-header-value: this can be used as a supplement to canary-by-header, allowing the value of the specified request header to be customized to other values, not only always or never;. When the value of the request header hits the custom value here, the request will be forwarded to the corresponding backend service defined by the Ingress, and if it is other values, the annotation will be ignored.

Nginx.ingress.kubernetes.io/canary-by-header-pattern: this is similar to the canary-by-header-value above, except that it uses regular expression pairs to match the value of the request header, rather than fixing just one value; note that if it exists with canary-by-header-value, the annotation will be ignored.

Nginx.ingress.kubernetes.io/canary-by-cookie: this is similar to canary-by-header, except that this is used for cookie, and also supports only always and never values.

Nginx.ingress.kubernetes.io/canary-weight: indicates the percentage of traffic allocated by Canary Ingress. Values range from 0 to 100. For example, if set to 10, it means that 10% of the traffic is allocated to the corresponding backend service of Canary Ingress.

The above rules are evaluated in order of priority, as follows: canary-by-header-> canary-by-cookie-> canary-weight

Note: when Ingress is marked as Canary Ingress, all non-Canary comments except nginx.ingress.kubernetes.io/load-balance and nginx.ingress.kubernetes.io/upstream-hash-by are ignored.

Hands-on practice

Here are some examples to get you started with Nginx Ingress's canary release in a TKE cluster.

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 two versions of the service

Here, take a simple nginx as an example, deploy a v1 version first:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-v1spec: replicas: 1 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")' }-apiVersion: v1kind: Servicemetadata: name: nginx-v1spec: type: ClusterIP ports:-port: 80 protocol: TCP name: http selector: app: nginx version: v1

Deploy another v2 version:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-v2spec: replicas: 1 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")' }-apiVersion: v1kind: Servicemetadata: name: nginx-v2spec: type: ClusterIP ports:-port: 80 protocol: TCP name: http selector: app: nginx version: v2

You can see the deployment on the console:

Create an Ingress to expose the service and point to the v1 version of the service:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: nginx annotations: kubernetes.io/ingress.class: nginxspec: rules:-host: canary.example.com http: paths:-backend: serviceName: nginx-v1 servicePort: 80 path: /

Visit and verify:

$curl-H "Host: canary.example.com" http://EXTERNAL-IP # EXTERNAL-IP is replaced by Nginx Ingress's own exposed IPnginx-v1 traffic segmentation based on Header

Create a Canary Ingress, specify the v2 version of the back-end service, and add some annotation to forward only the request with the request header named Region with the value of cd or sz to the current Canary Ingress, and simulate the new gray version to users in Chengdu and Shenzhen:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "Region" nginx.ingress.kubernetes.io/canary-by-header-pattern: "cd | sz" name: nginx-canaryspec: rules:-host: canary.example.com http: paths:-backend: serviceName: nginx -v2 servicePort: 80 path: /

Test access:

$curl-H "Host: canary.example.com"-H "Region: cd" http://EXTERNAL-IP # EXTERNAL-IP replaced with IPnginx-v2 $curl-H "Host: canary.example.com"-H "Region: bj" http://EXTERNAL-IPnginx-v1$ curl-H "Host: canary.example.com"-H "Region: cd" http://EXTERNAL-IPnginx-v2$ curl-H "Host: canary.example.com" http://EXTERNAL-IPnginx-v1 exposed by Nginx Ingress itself

As you can see, only requests with header Region of cd or sz are answered by the v2 version service.

Traffic Segmentation based on Cookie

It is similar to the previous Header, but the value cannot be customized with Cookie. Here, taking the simulated grayscale users in Chengdu as an example, only the request with the cookie named user_from_cd is forwarded to the current Canary Ingress. First delete the previous Canary Ingress for Header-based traffic segmentation, and then create the following new Canary Ingress:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-cookie: "user_from_cd" name: nginx-canaryspec: rules:-host: canary.example.com http: paths:-backend: serviceName: nginx-v2 servicePort: 80 path: /

Test access:

$curl-s-H "Host: canary.example.com"-- cookie "user_from_cd=always" http://EXTERNAL-IP # EXTERNAL-IP replaced with IPnginx-v2 $curl-s-H "Host: canary.example.com" exposed by Nginx Ingress itself-- cookie "user_from_bj=always" http://EXTERNAL-IPnginx-v1$ curl-H "Host: canary.example.com" http://EXTERNAL-IPnginx-v1

As you can see, only requests with a cookie user_from_cd of always are answered by the v2 version of the service.

Traffic Segmentation based on Service weight

Canary Ingress based on service weight is simple. It directly defines the proportion of traffic to be imported. Here, take importing 10% traffic to v2 version as an example (if any, delete the previous Canary Ingress first):

ApiVersion: extensions/v1beta1kind: Ingressmetadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "10" name: nginx-canaryspec: rules:-host: canary.example.com http: paths:-backend: serviceName: nginx-v2 servicePort: 80 path: /

Test access:

$for i in {1.. 10}; do curl-H "Host: canary.example.com" http://EXTERNAL-IP; done;nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v1nginx-v2nginx-v1nginx-v1nginx-v1

As you can see, there is only a 1/10 chance that the service will respond to the v2 version of the service, which is in line with the setting of 10% service weight.

Existing defects

Although we have implemented canary releases in several different poses using Nginx Ingress, there are still some drawbacks:

Only one Canary Ingress for the same service can be defined, so the back-end service supports up to two versions.

The domain name must be configured in Ingress, otherwise it will have no effect.

Even if the traffic is completely cut to the Canary Ingress, the old service must still exist, otherwise it will report an error.

This article comprehensively summarizes the canary publishing usage of Nginx Ingress. Although Nginx Ingress has limited ability and some defects in canary publishing, it can basically cover some common scenarios. If Nginx Ingress is used in the cluster and the publishing requirements are not complex, you can consider using this solution.

The above content is how to use Nginx Ingress to achieve canary publishing, have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, 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.