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

Author | Baijing Aliyun Development engineer

Introduction: in the first three articles, we introduced the development and deployment of the application, so after the application is successfully launched on the cloud, I have to face the topic of application management. In this article, let's take a look at how to do online release, and it can be grayscale.

Related articles are recommended:

Preface to "Best practices for SpringCloud applications on Kubernetes-Development articles", "Best practices for SpringCloud applications on Kubernetes-deployment articles (Development and deployment)" and "Best practices for SpringCloud applications on Kubernetes-deployment articles (tools deployment)"

When the new version is launched, it is risky to upgrade the old application to the new version directly, no matter in terms of product stability or user acceptance of the new version. Our general practice is to ensure that the new and old versions are online at the same time, and first switch a small part of the traffic to the application of the new version, and observe the application requests of the new version during this period. After confirming that there is no problem with the new version, gradually switch a larger proportion of the traffic to the new version. The core of this process is that the inflow and forwarding rules of traffic can be configured. EDAS's canary publishing capability provides the ability of multiple versions to be online at the same time, and provides flexible configuration rules to allocate traffic to different versions.

Spring Cloud micro-service applications deployed in EDAS Kubernetes clusters can be verified on a small scale by Canary release when the new version is released, and then fully upgraded after verification.

Canary release configuration

First of all, go to the application deployment page of EDAS and release the application that we want to deploy and upgrade. Here we choose Canary (grayscale) to release. It should be noted that the flow control for grayscale publishing is currently effective only for Dubbo and Spring Cloud applications that are not ingress applications. The so-called ingress application is the first application node that receives external traffic. And if your application uses native K8s features or configurations such as HPA, Rancher, Istio, or features and configurations that rely on Deployment.Metadata.Name or Deployment.Metadata.Uid, do not use grayscale publishing or batch publishing. Otherwise, these K8s native features or configurations will be abnormal after the application is deployed.

On the release page, you can choose the new version of the application deployment package to be released by uploading the JAR package or filling in the JAR package address.

After selecting the new version of the application deployment package to release, the next step is to configure the release strategy. This is divided into two parts:

The first part can set the release batch, such as setting the release grayscale batch, the number of pod instances in the first batch, and the processing method between batches, etc.; the second part can configure the traffic grayscale rules, and we can choose to carry out grayscale by traffic content or simply according to the proportion of traffic. The following will describe the configuration of these two publishing strategies in detail. Set publishing policy

The configurations we can make here in the batch release are:

The first batch of grayscale number: after clicking publish, the first batch of instances with the number of grayscale will be released in a new version. In order to ensure the stability of the application, the number of the first batch of grayscale instances cannot exceed 50% of the total number of application instances. For example, if the current number of instances is 7, a maximum of 3 can be selected as the first batch of grayscale instances; remaining batches: after the first grayscale release is completed, the remaining application instances will be released in accordance with the batches specified here Batch-to-batch processing: the processing mode between the remaining batches can be manual or automatic. If automatic is selected, the remaining batches will be released automatically after the completion of the previous batch release, and the batch interval for automatic release can also be configured. For example, configure each batch to automatically release the next batch 30 minutes after the release is completed. Intra-batch deployment interval: within each batch, if the number of application instances to be released in this batch is greater than 1, this configuration specifies the intra-batch instance deployment interval.

In the following example, we now have 7 pod application instances, and select the first batch of 2 instances for grayscale upgrade. After the grayscale release of the first 2 instances is completed, the remaining 5 instances are released in 3 batches. The processing mode between the three batches is automatic release, and the next batch release is automatically carried out 30 minutes after the completion of the current batch release. At the same time, because there are two instances in batch 2 and batch 2, the deployment interval between the two instances in the selected batch is 60 seconds. Our release strategy configuration information can be previewed on the right side of the release page.

Set grayscale rules

Currently, it supports setting grayscale rules according to content grayscale and proportional grayscale. Grayscale according to the request content supports the request content to meet the specified grayscale rule conditions of the traffic as grayscale traffic into the grayscale instance, for example, select the user ID module 100 less than or equal to 40 as the grayscale traffic into the grayscale instance for processing, while the user ID module 100 greater than 40 still enters the non-grayscale instance for processing, as shown in figure 1. Grayscale by traffic ratio means that a specified proportion of the request traffic is processed as grayscale traffic into the grayscale instance, for example, 40% of the traffic is specified as grayscale traffic, as shown in figure 2.

(figure 1)

(figure 2)

Perform grayscale according to the requested content

Grayscale according to the request content can be configured with the parameters specified below to determine which request content characteristics of traffic will enter into the grayscale instance as grayscale traffic.

Protocol type: you can choose Spring Cloud and Dubbo. Here we mainly introduce Spring Cloud protocol. Under the Spring Cloud protocol, the HTTP request path needs to be configured; the condition mode: for the list of conditions configured below, the configurable condition mode is that both the following conditions and any of the following conditions are met. Requests that meet the conditional mode will be used as grayscale traffic. List of conditions: Cookie, Header and Parameter can be conditionally configured under Spring Cloud protocol.

Scale grayscale

Proportional grayscale sets the proportion of traffic, and then the requested traffic is forwarded to the current grayscale packet for processing.

Release in grayscale and verify that the new version of the application meets expectations

After the release configuration is configured, you can start the grayscale release. EDAS will first deploy the new version of the application in the specified grayscale group, and you can check the deployment progress and status on the change details page. If you find a problem with the new version during the grayscale release, you can also terminate the changes and roll back the application.

In the grayscale release process, the application can be monitored to monitor whether the grayscale traffic is in line with expectations, and the application status can be compared between the new and old versions. After the gray traffic verification of the current batch is completed, click start the next batch on the change details page to complete the subsequent batch release. If you find a problem with the application of the new version during the verification process, you can click on the upper right corner of the change details page to roll back immediately. Confirm the impact of the rollback in the pop-up immediate rollback dialog box, and then click rollback.

For information about how to monitor grayscale traffic, you can refer to the EDAS document "Monitoring grayscale traffic".

After the grayscale release, check whether the deployment package is the newly deployed application version on the basic information page. Check whether the running status of the application instance is running properly on the instance deployment information page.

Conclusion and its follow-up

In this chapter, we introduce how to publish the Spring Cloud application on the EDAS Kubernetes cluster in grayscale. In the grayscale publishing process, we can flexibly configure the release strategy, grayscale rules, monitor the traffic and application status during the release process, and provide operations such as termination and rollback to maximize the smooth version upgrade of the application. In the next article, we will describe in detail how to monitor the application during the release process.

"Alibaba Cloud Native focus on micro services, Serverless, containers, Service Mesh and other technology areas, focus on cloud native popular technology trends, cloud native large-scale landing practice, to be the official account of cloud native developers."

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.