Create a Canary Release Task
This section describes how to create a canary release task.
Prerequisites
-
You need to join a project and have the Service Mesh Management permission in the project. For more information, see Project Members and Project Roles.
-
The KubeSphere Service Mesh extension must be installed and enabled on the KubeSphere platform.
-
Prepare the new version of the container image in advance and upload it to the container image service. Ensure the network connection between the container image service and KubeSphere is normal.
Steps
Refer to Parameter Description to set the parameters for the canary release task.
-
Log in to the KubeSphere web console with a user who has Service Mesh Management permissions and enter your workspace.
-
Click Canary Release > Canary Release in the left navigation pane.
-
Select a project from the drop-down list in the upper left corner of the page.
-
Hover over the Blue-Green Deployment, Canary Release, or Traffic Mirroring area based on the type of canary release task you need, and then click Create.
-
On the Basic Information tab, set the name for the canary release task, and then click Next.
-
On the Service Settings tab, select the application and service for the canary release, and then click Next.
-
On the New Version Settings tab, set the service version number, pod replica count, and container for the new version, and then click Next.
-
On the Strategy Settings tab, set the traffic forwarding strategy and release strategy for the canary release task, and then click Create.
After the canary release task is created, it will be displayed on the Release Tasks tab of the Canary Release page.
Parameter Description
The following describes how to set the parameters for a canary release task.
-
Basic Information
Set the task name. The name can only contain lowercase letters, numbers, and hyphens (-), must start and end with a lowercase letter or number, and can be up to 253 characters long.
-
Service Settings
Select the composed app and service for the canary release.
-
Click the drop-down list to select a composed app.
-
Click Select on the right side of the service that requires the canary release.
Note Canary release only supports composed apps, not template-based apps.
-
-
New Version Settings
Set the service version number, pod replica count, and container for the new version.
Parameter Description New Version
The service version number for the new version. The new version number can only contain lowercase letters and numbers, with a maximum length of 16 characters.
Replicas
The pod replica count for the new version. Click
/
to increase/decrease the number of pod replicas.Add Container
Create containers to run in the pod. You can create multiple containers in a pod.
-
Click Add Container to create a container.
-
Hover over a created container, then click
on the right to edit the container’s settings. -
Hover over a created container, then click
on the right to delete the container. -
Directly entering the container image URL in the text box can replace the old version’s container image while keeping other container settings unchanged.
-
-
New Version Settings > Add Container > Container Settings
Set the image, name, type, and resources for the container.
Parameter Description Image
The image required to create the container.
-
Enter the name (e.g., nginx:latest) or path (e.g., docker.io/nginx:latest) of the image, then press Enter to search for the image.
-
If you only enter the image name, it will be pulled from Docker Hub by default. To use a private image service, you need to create a Secret containing the private image service information, then select the private image service from the left side of the Image text box.
-
Click
to browse images in the current image service.
Container Name
The name of the container. The name can only contain lowercase letters, numbers, and hyphens (-), must start and end with a lowercase letter or number, and can be up to 63 characters long.
Container Type
The type of container.
-
Init Container: A container that performs initialization work for the main application container. The main application container will only start after all init containers have completed successfully. If an init container fails, the system will set the pod’s status to failed.
-
Main Container: The container that runs the application. It is generally recommended to run only one main container per pod.
CPU Request
The CPU resources reserved for the container, in cores.
CPU Limit
The upper limit of CPU resources allowed for the container, in cores.
Memory Request
The memory resources reserved for the container, in MiB.
Memory Limit
The upper limit of memory resources allowed for the container, in MiB.
-
-
New Version Settings > Add Container > Port Settings
Set the container port. Click Use Default Image Port to set the container port to the default port of the image. Click Add Port to set multiple ports for the container.
Parameter Description Protocol
The actual protocol that the application in the container listens on. To use the application governance features provided by KubeSphere, ensure that the protocol selected here is consistent with the actual protocol that the application in the container listens on.
Name
The name of the port. To use the application governance features provided by KubeSphere, use the lowercase protocol name as the prefix of the port name (e.g., http-).
Container Port
The actual port number that the application in the container listens on.
-
New Version Settings > Add Container > Image Pull Policy
Configure whether to pull images from the image service when creating or updating a pod.
Parameter Description Prefer Local Image
When creating or updating a pod, prioritize using the image files stored on the node by the container runtime.
Always Pull Image
When creating or updating a pod, always attempt to pull the image from the image service.
Use Local Image Only
When creating or updating a pod, use only the images stored on the node by the container runtime. If the required image does not exist locally, pod creation will fail.
-
New Version Settings > Add Container > Health Check
Check the health status of containers. Before using this feature, you need to configure your container’s application to return health check results.
KubeSphere supports the following health check types:
Parameter Description Liveness Probe
Checks if the container is alive. If the liveness probe fails, the system will attempt to restart the container.
Readiness Probe
Checks if the container is ready. If the readiness probe fails, the system will prevent access to the pod where the container resides via services.
Startup Probe
Checks if the container has started. If the startup probe fails, the system will disable other probes for the container and attempt to restart the container.
KubeSphere supports the following check methods:
Parameter Description HTTP Request
Sends an HTTP GET request to the pod’s virtual IP address. The check is successful if the response status code is 2XX or 3XX.
Command
Runs a command inside the container. The check is successful if the command’s exit code is 0.
TCP Port
Attempts to establish a TCP connection to the specified container port. The check is successful if the connection is established.
-
New Version Settings > Add Container > Health Check > Add Probe
Create probes to perform liveness, readiness, or startup checks on containers.
-
Click Add Probe to create a probe.
-
Hover over a created probe, then click
on the right to edit the probe’s settings. -
Hover over a created probe, then click
on the right to delete the probe.
Parameter Description Path
The protocol (HTTP or HTTPS) for the HTTP request, the path of the request target relative to the pod’s virtual IP address, and the port number for the request. Available only when the health check method is HTTP Request.
Command
The command to be executed inside the container. You can use commas (,) to separate the command and its arguments. Available only when the health check method is Command.
Port
The container port number for TCP checks. Available only when the health check method is TCP Port.
Initial Delay
The delay time, in seconds, after the container starts before the probe is initiated.
Timeout
The probe timeout period, in seconds. After the probe times out, the check is considered a failure. The value must be an integer, with a minimum value of 0.
Check Interval
The time interval, in seconds, between check executions. The value must be an integer, with a minimum value of 1.
Success Threshold
The minimum number of consecutive successful checks required after a failure for the check to be considered successful again. The minimum value is 1. For liveness and startup probes, this value must be 1.
Failure Threshold
The minimum number of consecutive failed checks required after a success for the check to be considered failed again. The minimum value is 1.
-
-
New Version Settings > Add Container > Lifecycle Management
Set the actions that need to be executed after a container starts or before it terminates, for environment checks or graceful termination. Before using this feature, you need to configure your container’s application so that it can return the execution result of the action.
Parameter Description Post-start Action
The action to be executed after the container starts. If this action fails, the system will attempt to restart the container.
Pre-stop Action
The action to be executed before the container terminates. This action follows these rules:
-
If the pre-stop action fails, the system will terminate the container immediately.
-
The default value for the container’s graceful termination period is 30s. If the pre-stop action is still executing when the graceful termination period is reached, the system will provide a one-time grace period of 2s.
-
After the grace period ends, regardless of whether the pre-stop action has finished executing, the system will terminate the container.
KubeSphere supports the following execution methods for post-start and pre-stop actions:
Parameter Description HTTP Request
Send an HTTP GET request to the pod’s virtual IP address. If the response status code is 2XX or 3XX, the action is considered successful.
Command
Run a command inside the container. If the command’s exit code is 0, the action is considered successful.
TCP Port
Attempt to establish a TCP connection to the specified container port. If the connection is successfully established, the action is considered successful.
-
-
New Version Settings > Add Container > Lifecycle Management > Add Action
Create post-start or pre-stop actions for containers.
-
Click Add Action to create an action.
-
Hover over a created action, then click
on the right to edit the action’s settings. -
Hover over a created action, then click
on the right to delete the action.
Parameter Description Path
The protocol (HTTP or HTTPS), the path of the request target relative to the pod’s virtual IP address, and the port number for the HTTP request. Available only when the action execution method is HTTP Request.
Command
The command to be run inside the container. You can use commas (,) to separate the command and its arguments. Available only when the action execution method is Command.
Port
The container port number for TCP checks. Available only when the action execution method is TCP Port.
-
-
New Version Settings > Add Container > Startup Command
Set the command to be executed inside the container when it starts.
Parameter Description Command
The name of the command to be executed.
Arguments
The arguments for the command to be executed. You can use commas (,) to separate multiple arguments.
-
New Version Settings > Add Container > Environment Variables
Set environment variables for the container.
-
Click Add Environment Variable to set multiple environment variables.
-
Click Batch Reference to create environment variables using data from a ConfigMap or Secret. The ConfigMap or Secret must belong to the same project as the container to be referenced by the container. After the container is created, the values of the environment variables will not change dynamically with updates to the ConfigMap or Secret settings.
-
Click
on the right side of a created environment variable to delete it.
Parameter Description Key
The name of the environment variable.
Value
The value of the environment variable.
Resource
The name of the ConfigMap or Secret. Only available when referencing a ConfigMap or Secret.
Key in Resource
The key within the ConfigMap or Secret. The value corresponding to this key will be used as the value of the environment variable. Only available when referencing a ConfigMap or Secret.
-
-
New Version Settings > Add Container > Pod Security Context
Set the permissions of container processes in the Linux system.
Parameter Description Access Control
Access permissions for container processes.
-
Privileged Mode: Runs the container process as the root user on the host.
-
Allow Privilege Escalation: Allows the container process to acquire more privileges than its parent process. This option is enabled by default when Privileged Mode is enabled.
-
Read-only Root Filesystem: Sets the root directory of the container’s filesystem to read-only.
Users and User Groups
The user and user group that run the container process entry point.
-
Run as non-root only: Check whether the container will run as the root user before starting the container. If the container will run as the root user, the container will not be started. When this feature is enabled, the system will ignore the Privileged Mode setting.
-
User: The UID that executes the container process entry point. Defaults to the UID specified in the image metadata.
-
User Group: The GID that executes the container process entry point. Defaults to the default GID of the container runtime.
SELinux Context
The SELinux label for the container process, including Level, Role, Type, and User. For more information, refer to the SELinux official documentation.
Capabilities
Additional permissions added to or removed from container processes in the Linux system. Refer to the Linux official documentation for a list of Linux process capabilities.
-
When adding or removing capabilities for container processes, you need to remove the CAP_ prefix from the capability name. For example, entering SYS_TIME in the Remove text box removes the CAP_SYS_TIME capability from the container process.
-
Click Add to set multiple capability addition or removal instructions.
-
-
New Version Settings > Add Container > Sync Host Timezone
Selecting the checkbox to the left of Synchronize Host Timezone will synchronize the timezone of the container with that of the host.
-
Strategy Settings
Set the business traffic forwarding strategy for the canary release task.
-
For Blue-Green Deployment, click Take Over on the right side of the new or old version to forward all business traffic to that version.
-
For Canary Release tasks, you can choose to specify the traffic distribution ratio between the new and old versions, or forward requests to the new or old version based on request parameters.
Parameter Description Specify Traffic Distribution
Drag the slider to set the percentage of business traffic received by the new and old versions.
Specify Request Parameters
Forward requests with parameters meeting specific conditions to the new version, and other requests to the old version.
Note Traffic Mirroring tasks send a copy of the business traffic to the new version for testing without actually exposing the new version, so there is no need to set a business traffic forwarding policy.
-
-
Strategy Settings > Release Strategy
Parameter Description Immediate Switch
Immediately switch all traffic to the corresponding version.
Switch After Ready
Automatically switch traffic after the corresponding version’s pods are ready.
Pause Switch
Actively pause traffic switching, maintaining the current traffic distribution state.