Workflow Deploy Strategy

Zadig workflow supports MSE grayscale release, blue-green release, canary release, batch grayscale release, Istio release and other release strategies. The following introduces relevant concepts and specific usage.

# MSE Grayscale Release

# Concept Introduction

MSE grayscale release is a full-link grayscale capability provided by Alibaba Cloud MSE. It can achieve full-link traffic control without modifying the business code.

Advantages

• No intrusive business code
• Simply create grayscale service resources to reduce costs

Notes

• Only supports Java applications, see Full Link Grayscale Component Support(opens new window) for details
• Supports production environment only

# How It Works

MSE Grayscale Release Task

1. Copy a YAML based on services in a benchmark environment
2. Automatically add suffix -mse-<Gray Scale Mark> for resource name metadata.name in YAML
3. Automatically add necessary labels for MSE full-link grayscale release to resources in YAML
4. Users can set grayscale image and replica count, and can directly modify other fields in the rendered YAML (labels used during grayscale process cannot be deleted)
5. Generate grayscale version resources based on the final YAML

Offline MSE Grayscale Service Task

Find and delete related labels set by grayscale resources

# How to Use

# Pre-Operations

MSE full-link grayscale scenarios need to be based on gateway capacity building. MSE components need to be installed in the cluster and appropriate gateways selected according to your situation. Take the cloud-native gateway that comes with MSE as an example:

• Install MSE Components, refer to Install ack-onepilot(opens new window)
• Install MSE Ingress Cloud Native Gateway, refer to Create MSE Cloud Native Gateway(opens new window), Access Container Services through MSE Ingress(opens new window)

# Things to Note

1. Before executing the MSE Grayscale release task, the namespace involved in the grayscale process needs to be labeled with mse-enable tags, command as follows:
   kubectl label namespace <NAMESPACE> mse-enable=enabled
2. The workload type of the grayscale service is Deployment, and the following selector and template.metadata.labels need to be added:
   zadigx-release-version: original

# Configure Workflow

Add the "MSE Grayscale Release" task to the workflow.

Parameter Description:

• Benchmark Environment: Select the benchmark environment, and the grayscale release task will add relevant resources required for grayscale release based on the services in the benchmark environment YAML
• Gray Scale Environment: The environment where grayscale release will be performed
• Image Repository: The image registry where the grayscale image is located
• Gray Scale Mark: Set grayscale marks, and resources with these grayscale marks will be automatically deleted during subsequent offline MSE grayscale service
• Status Detection: If enabled, the grayscale release task will poll the grayscale service operation status, and the task status will be successful after the service is running normally

Add the "Offline MSE Grayscale Service" task to the workflow and configure the grayscale environment.

# Perform MSE Grayscale Release

Start the workflow and perform MSE grayscale release tasks to modify grayscale marks, grayscale images, replica count, and grayscale service YAML configuration.

You can view the specific process of grayscale release. After the grayscale task is executed, you can view the status and basic information of the grayscale service in the environment.

# Offline MSE Grayscale Service

After the grayscale service is verified correctly, start the workflow and execute the offline MSE grayscale service task. Select the grayscale mark that needs to be offline to automatically remove the corresponding grayscale service.

# Blue-Green Release

# Concept Introduction

Blue-green release is a strategy to upgrade services with minimal downtime. The two versions of the environment that need to be maintained are called "Blue Environment" and "Green Environment". Generally, the current production traffic points to the green environment, and a new version is deployed on the blue environment and used as a test environment for a short time.

Advantages

• Simple, fast, easy to understand and implement
• Compared with other deployment strategies, the risk is smaller.

Notes

• Double resources may incur more costs.
• Current transactions and sessions will be lost when switching from one version to another.
• Database compatibility (schema changes, backward compatibility).

# How It Works

1. Deploy the blue environment by copying the current workload, setting a new image, and creating a blue service pointing to it.
2. After the blue environment is deployed, execute the user's verification tasks.
3. Start the blue-green release by setting a new image for the green workload.
4. After the release process is completed or interrupted, delete the blue environment, blue service, and blue workload.

# How to Use

# Usage Conditions

The workload of the service to be updated must meet the following conditions:

1. The workload must have a corresponding service, and the workload's labels must include all service selector labels.
2. The type of workload is Deployment.

# Configuring Blue-Green Release

1. Create a new workflow. Visit Workflow -> New Workflow, select the "Blue-Green Release" workflow template to create a new workflow.

2. Configure the blue-green environment deployment task. Select the "Deploy Blue-Green Environment" task and configure it.

Parameter Description:

• Environment: Choose a production environment
• K8s Service Configuration: Add services that require blue-green deployment

Supports modifying the default configuration of K8s Service, and will take effect on the blue service when performing blue-green deployment.

3. Configure the verification task to ensure the blue environment meets the requirements for production. Select the "Check" task and configure it.

4. Configure the approval task.

5. Configure the blue-green release task. Select the "Blue-Green Release" task and configure it.

Parameter Description:

• Select "Deploy Blue-Green Environment" Task: Select the pre-development task of blue-green environment

6. Click the "Save" button for the workflow to complete the workflow configuration.

# Executing Blue-Green Release

• Execute the workflow, select the service component that needs to be updated, specify the image, and modify the K8s Service configuration as needed.

• The workflow is completed and executed according to the set tasks. Click on the task to view the specific process of blue-green deployment and blue-green release.

• You can view the blue-green service details in the environment.

# Canary Release

# Concept Introduction

In the production environment, a part of the actual traffic is used to test a new version, test the performance and behavior of the new version, and discover problems of the new version in the actual environment as soon as possible while ensuring the overall stable operation of the system.

Advantages

• The lowest risk relative to all other deployment strategies (reduce business risk).
• Production testing is performed using real users and use cases.
• Run and compare the two service versions side by side.
• It saves resources compared to blue-green releases, and does not require two production environments.

Notes

• Monitoring and basic components (APM, logs, infrastructure, end users, etc.) required for production testing.
• Database compatibility (schema changes, backward compatibility).

# How It Works

1. Deploy the canary, copy the current workload, set the replica, set the new image, point to the same service.
2. After canary deployment is complete, perform user verification tasks.
3. Start executing canary release and delete the newly created workload.
4. Roll to upgrade the current workload to the new image.
5. Canary is deleted if the release process is completed or interrupted

# How to Use

# Usage Conditions

The workload of the service to be updated must meet the following conditions:

1. The workload needs to have a service corresponding to it, and the labels of the workload contain the selector labels of all services.
2. The workload currently only supports the deployment type.

# Configuring Canary Release

1. Create a new workflow. Visit Workflow -> New Workflow, select the "Canary Release" workflow template to create a new workflow.

2. Configure the canary deployment task. Select the "Canary Deployment" task and configure it.

Parameter Description:

• Image Repository: The repository where the instance image is stored
• Cluster: Cluster information
• Namespace: The K8s namespace where the instance is located
• Instance List: This task can select the updated instance list
  • Instance Number(%): The number of canary replicas, such as the original replica count is 100, and the configured instance number is 10%, then 10 canaries will be deployed, with 10% of online traffic going to the canary version.

3. Configure the verification task to ensure the canary version meets the requirements for production. Select the "Check" task and configure it.

4. Configure the approval task.

5. Configure the canary release task. Select "Canary Release" and configure it.

6. Click the "Save" button for the workflow to complete the workflow configuration.

# Executing Canary Release

• Click the "Execute" button to select the instance and image to be updated.

• The workflow completes the deployment of canary and verification tasks, waiting for manual approval. At this time, 1 canary instance has been deployed in the environment, as shown below.

• Manual approval and completion of canary release. At this time the environment has been updated to the canary version, as shown below.

# Batch Gray-scale Release

There are many ways to implement gray-scale releases. In addition to canary releases, Zadig also supports batch gray-scale releases. Based on actual conditions, online services are upgraded in multiple stages. For example, the first gray-scale release might be 20%, with 20% of production traffic directed to the new version. By monitoring online traffic, a second gray-scale release of 40% can be performed, and after no issues are detected, a full rollout is made.

# How It Works

First Grayscale Task

1. Initialize the original deployment, and the system automatically adds the annotation required by the grayscale process.
   • <origin-deployment-name>-gray-release-image: Record the image name before release
   • <origin-deployment-name>-gray-release-container: Record the container name before release
   • <origin-deployment-name>-gray-release-replica: Record the number of replicas before release
2. Create grayscale deployment <origin-deployment-name>-zadig-gray, set the number of replicas to round up (original number of replicas * percentage), set the image to a new image, wait for deployment ready.
3. Adjust the number of original deployment replicas: original replica count - new deployment replica count, wait for deployment ready.

Intermediate State Grayscale Task

1. Set the new version deployment number of replicas to round up (original number of replicas * percentage), wait for deployment ready.
2. Set the number of grayscale deployment replicas to original replicas - new deployment replica count, wait for deployment ready.

100% Grayscale Task

1. Set the original deployment: image is set to the new version, replica count is the original replica count, wait for deployment ready.
2. Delete grayscale deployment

# How to Use

# Configuring Gray-scale Release

1. Edit the workflow and add the "Grayscale Release" task: Click "+ Task", select the "Grayscale Release" task and configure First Grayscale Task.

Parameter Description:

• Grayscale Task Type: Select First Grayscale Task.
• Container Name: A container that can be grayscale. When executing a workflow, several of the containers can be selected from the configured range for grayscale.
• Grayscale Percentage: Control the actual number of grayscale replicas, the value of original replica count * grayscale percentage is rounded upward.

2. Add more grayscale phases and configure Non-First Grayscale Task tasks.

Parameter Description:

• Grayscale Task Type: Select Non-First Grayscale Task.
• Select First Grayscale Task: Continue to perform grayscale on the basis of the first grayscale task.
• Grayscale Percentage: Control the actual number of grayscale replicas, the value of original replica count * grayscale percentage is rounded upward. In the last grayscale phase, the percentage of grayscale must be 100%.

# Executing Gray-scale Release

• Click the "Execute" button to select the container and its image that need to be gray-scaled.

• The workflow executes according to the set tasks, and the execution status is shown below.

# Grayscale Rollback

If an unexpected interrupt occurs during the grayscale process or needs to roll back to the state before grayscale, you can use the "Grayscale Rollback" task.

# How It Works

1. Adjust deployment, the image corresponding to the container is the image before grayscale, the number of replicas is adjusted to the number of replicas of the previous version, and wait for deployment ready.
2. Clean up grayscale deployment.

# How to Use

# Configure Grayscale Rollback

1. Edit the workflow and add the "Grayscale Rollback" task: Click "+ Task", select the "Grayscale Rollback" task and configure it.

Parameter Description:

• Deployment Name: Only those published by Grayscale can be selected deployment
• Timeout (minutes): The timeout duration for the rollback task

# Perform Grayscale Rollback

• Click the "Execute" button to select the Deployment that needs to be rolled back.

• The workflow executes according to the set tasks, and the execution status is shown below.

# Istio Release

Istio release is a type of grayscale release that uses Istio flow control capabilities to complete the grayscale process.

# How It Works

First Istio Release Task

• Create a deployment named <workload_name>-zadig-copy
• Create a destination rule named <workload_name>-zadig
• If virtual service is provided, modify the routing rules in the provided virtual service and set the subset weight according to the user-provided proportional weight
• If virtual service is not provided, create virtual service named <workload_name>-vs-zadig

Intermediate Status Istio Release Task

• Modify the virtual service in the above rules and configure subset weights according to the new traffic ratio

New Version Traffic 100% Istio Task

• Modify the image name and number of replicas of the target deployment, set the value to the ratio of new image and published replicas, and add the corresponding image name and replica count information on the deployment
• Depending on whether vs is provided, fallback virtual service becomes the original version/delete temporary virtual service created by zadig
• Delete temporary destination rule created by zadig
• Delete temporary deployment created by zadig

# How to Use

# Usage Conditions

The following conditions are required:

1. Istio needs to be installed by yourself in the cluster
2. The updated workload needs to be marked with the pod label of zadig-istio-release-version: original
3. The workload currently only supports the Deployment type

# Configure Istio Release

1. Edit the workflow and add the "Istio Release" task: Click "+ Task", select the "Istio Release" task and configure First Istio Release Task.

Parameter Description:

• Task Type: Select the first Istio Release task
• New Version Replica Percentage: Control the number of new version replicas, the number of new version replicas is the value of original replica count * new version replica percentage rounded upward
• New Version Traffic Percentage: Control the percentage of actual traffic of the new version
• Instance List
  • Workload Name: Need to be updated workload
  • Container Name: The name of the container that needs to be updated
  • Virtual Service Name: Optional, use the Istio Virtual Service name, if not selected, Zadig will create it by itself
  • Virtual Service Host: The Host name used for accessing

2. Add more Istio release phases, configure Non-First Istio Release Task.

Parameter Description:

• Task Type: Select Non-First Istio Release Task
• Select First Istio Release Task: Continue to perform grayscale on the basis of the first Istio release task
• New Version Replica Percentage: Control the number of new version replicas, the number of new version replicas is the value of original replica count * new version replica percentage rounded upward
• New Version Traffic Percentage: Control the percentage of actual traffic in the new version, the last Istio release phase, traffic percentage must be 100%

# Perform Istio Release

• Click the "Execute" button to select the container and its image that need to be gray-scaled.

• The workflow executes according to the set tasks, and the execution status is shown below.

# Istio Release Rollback

If an unexpected interrupt occurs during the Istio release process or needs to roll back to the state before release, you can use the "Istio Release Rollback" task.

# How It Works

• Clean up the name <span v-pre><workload_name></span>-zadig destination rule
• If the specified workload contains the image name and number of replicas from the last application, the image name and number of replicas of the target workload will be rolled back to the version recorded in the annotation.
• In any case, attempt to delete the deployment named <span v-pre><workload_name></span>-zadig-copy

# How to Use

# Configure Grayscale Rollback

1. Edit the workflow and add the "Istio Release Rollback" task: Click "+ Task", select the "Istio Release Rollback" task, and configure it.

Parameter Description:

• Cluster: The cluster where the service to be rolled back is located
• Namespace: The namespace where the service to be rolled back is located
• Container Name: Only select containers that have been published by Istio
• Timeout (minutes): The timeout duration for the rollback task

# Perform Grayscale Rollback

• Click the "Execute" button and select the container that needs to be rolled back.

• The workflow executes according to the set tasks, and the execution status is shown below.