Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Best Practices for Spring Cloud Applications in Kubernetes: Online Release (Support for Grayscale Release)

Best Practices for Spring Cloud Applications in Kubernetes: Online Release (Support for Grayscale Release)

This article introduces how to perform grayscale release for Spring Cloud applications on EDAS Kubernetes clusters.

By Baiji, Alibaba Cloud Development Engineer

1

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.

Related articles:

In this article, we will introduce how you can perform grayscale release for Spring Cloud applications on Enterprise Distributed Application Service (EDAS) Kubernetes clusters.

Preface

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.

Configuration for Canary Release

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.

2

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.

3

When the new-version deployment package of the application is selected, you need to configure the release policy. The configuration activity involves two tasks:

  • First, set the number of batches, such as the number of grayscale batches, the number of pod instances covered by the grayscale release, and the batch processing mode.
  • Second, set the grayscale rules for application traffic. We can choose to implement grayscale release by traffic content or just a traffic ratio. The following section describes the configuration of these two release policies in detail.

Configure the Release Policies

The following options can be configured for grayscale release:

  • First Batch Grayscale Quantity: After you click the release button, the new version will be released to the number of grayscale instances included in the first batch. To ensure the stability of the application, the number of grayscale instances cannot exceed 50% of the total number of application instances. For example, if the total number of application instances is 7, you can only select up to 3 instances for the first batch of grayscale instances.
  • Remaining Batch: After the grayscale instances are released, the remaining application instances will be released in the specified number of batches.
  • Batch Processing Mode: The mode for processing the remaining batches can be manual or automatic. If you choose the automatic method, the remaining batches will be automatically released after the previous batch is published. You can also set the batch interval for automatic release. For example, if you set the value of the batch interval to 30 minutes, after one batch is released, the next batch will be automatically released after 30 minutes.
  • Batch in Deployment Interval: If a batch has more than one application instance, you must specify the number of instances and the deployment interval in this batch.

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.

4

Set Grayscale Release Rules

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.

5
(Figure 1)

6
(Figure 2)

Grayscale Release by Request Content

You can configure the following parameters to determine the content features of request traffic to be directed to grayscale instances.

  • Protocol Type: You can select Spring Cloud or Dubbo. This article will only focus on the Spring Cloud protocol. The HTTP request path needs to be configured if the grayscale traffic is identified by using the Spring Cloud protocol.
  • Condition Patterns: The conditions are shown in the following list. The available patterns are: meeting all the conditions, and meeting any of the following conditions. The request traffic that fits the specified condition pattern will be deemed grayscale traffic.
  • Condition List: When using Spring Cloud protocol, three types of request content, cookie, header, and parameter, can be used to configure the conditions.

7

Grayscale Release by Traffic Proportion

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.

8

Conduct Grayscale Release to Verify New Application Versions

9

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.

10

Summary and Outlook

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.

EDAS Microservices Container Computing Kubernetes Enterprise Distributed Application Service Spring Cloud Application Monitoring
0 0 0
Share on

Read previous post:

Alibaba Cloud Launches New Enterprise Containers at KubeCon 2020

Read next post:

KubeVela: One of the Hottest Golang Cloud Native and Open Source Project!

Alibaba Cloud Native Community

480 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

480 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All