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

This article mainly explains "how Kubernetes implements the canary release of front and rear applications". The explanation in the article is simple and clear and easy to learn and understand. Please follow the editor's train of thought to study and learn "how to achieve canary release of front and rear applications in Kubernetes".

1. Deployment rolling update strategy to achieve canary release

Simple canary publishing can be realized by setting the maximum number of nodes that can exceed expectations and the maximum number of unavailable nodes by using Deployment's rolling update strategy maxSurge and maxUnavailable.

The maximum number of nodes that can exceed the expected number of nodes in rollingUpdate.maxSurge, 10% or 5 absolute

Maximum number of unavailable nodes in rollingUpdate.maxUnavailable, percentage or absolute value

ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: demo-deployment namespace: defaultspec: replicas: 10 selector: matchLabels: name: hello-deployment strategy: type: RollingUpdate rollingUpdate: maxSurge: 10% maxUnavailable: 0 template: metadata: labels: name: demo-deployment spec: containers:-name: webserver image: nginx:1.14 ports:-containerPort:80

This solution is only suitable for canary release of a single application, but it is not suitable for front-end and front-end applications. There may be situations where the normal version of the front-end calls the back-end canary version, or the front-end canary version calls the normal back-end version. As a result, Pass dropped this plan and found another way.

2. Ingress-Nginx is configured with Ingress Annotations to realize canary release.

Ingress-Nginx supports configuring Ingress Annotations to implement canary publishing in different scenarios. 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

Obviously, canary-weight is also a random strategy, which will also cause the normal version of the front end to call the back-end canary version, so Pass drops this strategy.

Canary-by-cookie and canary-by-header-value are suitable for back-end canary release implementation, while canary-by-cookie is suitable for front-end canary release implementation.

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: demo-canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "canary" nginx.ingress.kubernetes.io/canary-by-cookie: "canary" spec: rules:-host: demo-api.fulu.com http: paths:-backend: serviceName : demo-api-canary servicePort: 80

The frontend sets the value canary=always of cookie according to the user tag or manually in the browser. If the frontend code detects this cookie, it passes the request header of canary=always to the backend, so that the normal version of the frontend can access the normal version of the backend, or the canary version of the frontend accesses the canary version of the backend without version confusion.

2.1 process

If this is the first release, it must be a normal version.

If you release the canary version, first check whether there are ingress, service and deployment with the-canary suffix, if so, replace the image of the canary version, and if not, create ingress, service and deployment with the-canary suffix.

If the normal version is released, first check for ingress, service, and deployment with the-canary suffix, and if so, delete them first, and then replace the images of the normal version.

2.2 Code

Front-end code modification

Take React as an example, modify the axios request interceptor to get whether to access the canary version from cookie, and if so, pass the canary version request header to the backend service.

Import cookie from 'react-cookies'axios.interceptors.request.use ((config) = > {/ / Canary version const canaryCookie = cookie.load (' canary') if (canaryCookie! = = undefined) {config.headers.canary = canaryCookie} return config}, (error) = > {return Promise.reject (error)})

Back-end code modification

Take .net as an example to transparently transmit canary request headers to other Api services through agents.

Public class CanaryHttpMessageHandler: DelegatingHandler {private readonly IHttpContextAccessor _ httpContextAccessor; private const string Canary = "canary"; public CanaryHttpMessageHandler (IHttpContextAccessor httpContextAccessor) {_ httpContextAccessor = httpContextAccessor;} protected override async Task SendAsync (HttpRequestMessage request, CancellationToken cancellationToken) {var headers = _ httpContextAccessor?.HttpContext?.Request?.Headers If (headers! = null & & headers.ContainsKey (Canary)) {/ / transparent request header canary var canary = headers [Canary] .ToString ()? ""; if (! string.IsNullOrWhiteSpace (canary)) request.Headers.TryAddWithoutValidation (Canary, canary);} return await base.SendAsync (request, cancellationToken);}}

Front-end Chrome testing

Visit the front-end website F12 using a Chrome browser and enter [xss_clean] = 'canary =' in Console

Always' manually sets the cookie value for canary.

You can see the settings in Cookies, when visiting the front-end website is a grayscale version.

If you delete the cookie of canary, the normal version of the frontend website will be accessed at this time.

Back-end Postman testing

Use Postman to access the backend interface and enter canary = always in the request header. The access to the backend service is in grayscale.

If you delete the request header of canary, the access to the backend service will be the normal version.

Thank you for your reading. the above is the content of "how to achieve canary release of front and back-end applications in Kubernetes". After the study of this article, I believe you have a deeper understanding of how to achieve canary release of front and back-end applications in Kubernetes, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.