Blue-green deployment

Note

Blue-green deployment tickets are mutually exclusive for each application service. You cannot use two deployment tickets to publish the same application service simultaneously. These tickets are also mutually exclusive with standard deployment tickets.

Prerequisites

An application service is created. When you configure the deployment and scheduling policy for the service, set the deployment grouping strategy to All in one group or Quick grouping.

For information about the limitations of grouping strategies, see the following table.

Deployment grouping strategy	Blue-green deployment support	Description
One pod per group	×	Grayscale validation for blue-green deployments is controlled by a spanner, not by the percentage of upgraded pods within the application service.
Group by deployment unit	×	If the traffic ratio is 100:0, traffic cannot be directed to the region with 0 traffic when grouping by deployment unit.
All in one group	√	/
Quick grouping	√	/
All in one group (Beta unit mode)	×	/
Concurrent mode by deployment unit percentage	×	/

Create a blue-green deployment ticket

1. Log on to the LHC console.

2. In the navigation pane on the left, click O&M > Deployment Ticket.

3. On the Deployment dashboard, click Create Deployment Ticket.

4. Configure the basic information.

   • Title: The title of the deployment.

   • Type: Select one of the following types: Blue-green Deployment (Ingress Application) or Blue-green Deployment (Deployment Unit Dimension).

     Note

     • Blue-green Deployment (Ingress Application): This applies to applications that use an Ingress and have unified access configured. During the deployment, a new version is deployed with the same number of pods as the current version. After validation is complete, the old pods are revoked. This process temporarily doubles the consumption of application service resources.

     • Blue-green Deployment (Deployment Unit Dimension): This applies to non-unitized application services. During the deployment, the Ingress traffic to one deployment unit is cut off. Then, a full deployment is performed on that deployment unit. After the deployment, you can use grayscale traffic diversion for validation. After validation is complete, the next deployment unit is deployed.

   • Namespace: Select the namespace of the application service that you want to publish.

   • Application Service Deployment List: In the Available Application Services list, select the application services that you want to deploy and click Add to move them to the Selected Application Services list.

     Note

     • If an application service has multiple committed versions, select the version to publish. The latest version is selected by default.

     • The previous deployment of the application service selected for the blue-green deployment ticket must have been successful. This ensures that a complete blue version is online.

     • The unified access configuration for the selected version cannot be different from the currently running version.

     • The two versions in the blue-green deployment ticket cannot have topology changes, such as changing from Cell A to Cell B. A change in the number of replicas is not considered a topology change.

   • Traffic Diversion Application Service: This parameter appears only when the deployment type is Blue-green Deployment (Deployment Unit Dimension). Select the application service to use for traffic diversion.

     Note

     • The previous deployment of the traffic diversion application service must have been successful.

     • The version of the traffic diversion application service cannot add or remove unified access or deployment units.

     • The traffic diversion application service must have a non-unitized Ingress.

     • The traffic diversion application service must have the same deployment units as the application service selected in the Application Service Deployment List.

   • Deployment Unit Publish Order: This parameter appears only when the deployment type is Blue-green Deployment (Deployment Unit Dimension). You can manually change the publish order of the deployment units.

5. Click Next to go to the advanced configuration step.

   Set application service dependencies: If you select two or more application services, you can specify the dependencies between them. If the services have no dependencies, you can skip this step.

   In the Depends on column, enter the name of the service on which an application service depends. You can select multiple services. Add dependencies one by one.

   For example, if appservice1 depends on appservice2, enter appservice2 in the Depends on column for appservice1. The same logic applies to dependencies on multiple services.

   Important

   Application services cannot have circular dependencies. For example, Application Service A cannot depend on Application Service B if Application Service B also depends on Application Service A.

6. Click Next to review the deployment configuration.

7. On the Preview page, confirm that the information is correct and click Create. You are automatically redirected to the Deployment Ticket Details page. Click Publish All to start the deployment.

View blue-green deployment ticket details

After the deployment ticket is created, you are automatically redirected to the Deployment Ticket Details page. On this page, you can view the execution details of the deployment. The following sections describe the details for the Blue-green Deployment (Ingress Application) and Blue-green Deployment (Deployment Unit Dimension) types.

Note

• If the deployment ticket fails during initialization, you cannot continue the deployment. Hover over Failure Reason to view the details, or click Re-initialize.

• The blue version in a blue-green deployment ticket is the current online version.

Blue-green Deployment (Ingress Application)

• Pre-tasks

  • Execute service configuration changes: If a container service has a new or modified Service configuration, a task is executed to apply the Service configuration. Otherwise, this task is skipped.

  • Publish log configuration: If a log configuration is configured for the container service, a pre-task is executed to create or update the log configuration. Otherwise, this task is skipped.

• Application service

  If the application service has unified access, you can configure the traffic ratio between the blue and green zones.

  Note

  You can set a traffic ratio for the blue and green zones only if the application service has unified access configured. This lets you adjust traffic during the green version deployment. For more information about how to configure unified access for an application service, see Configure unified access.

  • To customize the traffic ratio, click Configure in the application service section. In the dialog box, enter the traffic ratio for the blue and green zones.

    

  • If you do not customize the traffic ratio, the ratio is set to Blue zone:Green zone = 100:0 (%). When the post-tasks are executed, all traffic is directed to the green zone.

• Post-tasks

  • Switch traffic to the green zone: During a blue-green deployment for an application service, a post-task is executed to switch traffic to the green zone.

  • Clean up invalid service configurations: If a container service has a deleted Service configuration, a task is executed to clean up the Service. Otherwise, this task is skipped.

  • Publish log configuration: If the container service has no log configuration or the log configuration is canceled, a post-task is executed to delete the log configuration. Otherwise, this task is skipped.

• Post-tasks (Rollback)

  Roll back log configuration: If the application service is rolled back to a state with no resources and its log configuration has been applied, a task is executed to roll back the log configuration. Otherwise, this task is skipped.

Blue-green Deployment (Deployment Unit Dimension)

• Publish order

  For this type of deployment, the Ingress traffic to one deployment unit is cut off, and then a full deployment is performed on that deployment unit. The overall publish order is as follows:

  Cut off traffic >> Deploy unit >> Switch traffic >> Resume traffic

  Note

  • The number of times Deploy unit and Switch traffic are executed depends on the actual number of deployment units.

  • After a deployment unit is deployed, you must perform grayscale traffic diversion. Then, click OK to switch the traffic and continue the deployment of the next unit.

  The entire deployment ticket uses the All in one group method to determine the traffic switching and publishing order based on the deployment units. As shown in the figure above, the traffic is cut off and the application is published in the order of gz00a > rz00a > gz00c.

• Grayscale traffic diversion

  During the deployment process, click Grayscale Traffic Diversion to adjust the traffic weight for specific deployment units.

  Note

  If the traffic weight of a deployment unit is 0, traffic loss may occur after the traffic is switched.

  

Other operations

• After a blue-green deployment ticket is created, you can click Cancel to stop the deployment. The procedure is the same as for a standard deployment. For more information, see Cancel a deployment.

  Note

  After a blue-green deployment ticket is canceled, multiple running versions may exist simultaneously. The extra versions are automatically purged during the next user-initiated deployment.

• When you configure the deployment and scheduling policy for an application service, if the Beta Confirmation feature is enabled, click Beta Confirmation during the application deployment to continue the group deployment. The procedure is the same as for a standard deployment. For more information, see Beta confirmation.

• If a blue-green deployment fails, you can click Retry or Rollback. The procedure is the same as for a standard deployment. For more information, see Retry or roll back a deployment.

• During or after the deployment, you can view pod events to check the scheduling and running status of the pods. The procedure is the same as for a standard deployment. For more information, see View pod events.