By Baiji, Alibaba Cloud Development Engineer
The first three articles of this series discussed the development and deployment of applications. The remaining articles in this series will continue to discuss the management of applications after they are migrated to the cloud. This article will focus on how to carry out online release with support for grayscale release.
In this article, we will introduce how you can perform grayscale release for Spring Cloud applications on Enterprise Distributed Application Service (EDAS) Kubernetes clusters.
During the release of a new version, it is quite risky to directly upgrade an application from the current version to the new version, regardless of the stability or user reaction to the new version. The routine practice is to put the new version of an application in production, keep the current version, and redirect a small part of the traffic to the new version. During this process, all requests sent to the new version are monitored. After you confirm that the new version works, an increasing percentage of the traffic is channeled to the new version. The key to this process is the ability to configure the inbound traffic forwarding rules. The canary release feature provided by Enterprise Distributed Application Service (EDAS) allows multiple versions to remain online at the same time and provides flexible configuration rules to allocate traffic among the versions.
The Spring Cloud micro-application is deployed in an EDAS Kubernetes cluster. To launch a new version of the micro-application, a canary deployment will be carried out first to verify the new version on a small scale. After the new version is verified, a full upgrade will be performed.
First, go to the EDAS application deployment page, and publish the application to be deployed and upgraded. In this example, we choose the canary (grayscale) release method. Note that throttling for a grayscale rollout is, for the moment, only applicable to Dubbo and Spring Cloud applications that are non-entry applications. An entry application is the first application node to receive external traffic. Do not choose the grayscale release or phased release if your applications use HPA, Rancher, Istio, or Kubernetes-native functions or configurations that depend on features and configurations of Deployment.Metadata.Name or Deployment.Metadata.Uid.
Otherwise, the Kubernetes-native features or configurations of the application may experience exceptions after the grayscale release.
On the release page, you can select and publish an application deployment package for the new version by uploading the JAR package or entering the JAR package address.
When the new-version deployment package of the application is selected, you need to configure the release policy. The configuration activity involves two tasks:
The following options can be configured for grayscale release:
Here is an example. We have seven pod application instances. The first batch consists of two grayscale instances. After the first batch is released, the remaining five instances can be released in three batches. We choose the automatic mode for the three batches and set the batch interval to 30 minutes. The next batch is automatically released 30 minutes after the current batch is completed. In addition, two out of the remaining batches have two instances respectively. You can set the deployment interval between the two instances to 60 seconds. On the right side of the release page, you can preview the configured release policies.
The grayscale release can be carried out by request content or by traffic proportion. When a grayscale release is carried out by request content, the traffic that matches the specified grayscale conditions will be regarded as grayscale traffic and directed to the grayscale instances. For example, assuming your application has 100 user IDs, you can set the rules so that traffic from users with IDs of 40 or less is directed to the grayscale instances, and the traffic from user ID greater than 40 is directed to non-grayscale instances, as shown in Figure 1. When a grayscale release is carried out by traffic proportion, a specified percentage of request traffic will be deemed grayscale traffic and directed to the grayscale instances. For example, you can specify 40% of the total request traffic as grayscale traffic, as shown in Figure 2.
You can configure the following parameters to determine the content features of request traffic to be directed to grayscale instances.
You can set a traffic percentage as the grayscale proportion to forward the specified percentage of request traffic to the grayscale instance group for processing.
After the release configuration is completed, you can proceed with the grayscale release. EDAS will first deploy the new version of the application in the specified grayscale release group. You can go to the Change Details page to view the deployment progress and status. If any issues are found with the new version during the grayscale release, you can terminate the change and roll back the application.
During a grayscale release, you can monitor the application to determine whether the grayscale traffic meets your expectations and compare the application status between the new and old versions. After the grayscale traffic from the current batch is verified, click Start the Next Batch on the Change Details page to complete the remaining batches. If any issues are found with the new version during the verification process, you can click Rollback in the upper-right corner of the Change Details page. In the Rollback dialog box, check the impact of rollback and then click Rollback.
After a grayscale release is completed, check whether the deployment package shown on the Basic Information page is the new version. On the instance information page, check whether the status of the application instances is normal.
This article introduces how to perform grayscale release for Spring Cloud applications on EDAS Kubernetes clusters. During a grayscale release, you can flexibly configure the release policies and grayscale rules, monitor the traffic and application status during the process, and terminate and roll back the release. This will guarantee the smooth upgrade of an application to the new version. In the upcoming articles, we will discuss how to monitor applications during the release process in detail.
Alibaba Cloud Launches New Enterprise Containers at KubeCon 2020
KubeVela: One of the Hottest Golang Cloud Native and Open Source Project!
376 posts | 41 followersFollow
Alibaba Developer - January 20, 2022
SeanLiu - April 17, 2020
Alibaba Cloud Community - November 25, 2021
Alibaba Cloud Native Community - March 2, 2023
Alibaba Cloud Native Community - February 22, 2023
Alibaba Cloud Native - May 11, 2022
376 posts | 41 followersFollow
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.Learn More
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resourcesLearn More
MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.Learn More
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.Learn More
More Posts by Alibaba Cloud Native Community