< img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=3131724&fmt=gif" />

Create Grayscale Release Tasks

This section describes how to create a grayscale release task.

Prerequisites

  • You should join a project and have the Service Mesh Management permission within the project. For more information, refer to "Project Members" and "Project Roles".

  • KubeSphere Service Mesh should have been installed and enabled.

  • Prepare the new version container image in advance and upload it to the container image service, ensuring that the container image service has normal network connectivity with KubeSphere.

Steps

Refer to Parameter Description to set the parameters for the grayscale release task.

  1. Log in to the KubeSphere web console with a user who has the Service Mesh Management permission, and access your project.

  2. Click Service Mesh > Grayscale Release in the left navigation pane.

  3. Select a type for the grayscale release task as needed by hovering over the Blue-Green Deployment, Canary Release, or Traffic Mirroring area, then click Create.

  4. On the Basic Information tab, set the name of the grayscale release task, then click Next.

  5. On the Service Settings tab, select the app and service to be grayscale released, then click Next.

  6. On the New Version Settings tab, set the service version number, number of pod replicas, and containers for the new version, then click Next.

  7. On the Strategy Settings tab, set the traffic distribution strategy for the grayscale release task, then click Create.

    After the grayscale release task is created, it will be displayed in the Release Tasks tab on the Grayscale Release page.

Parameter Description

The following describes how to set the parameters for the grayscale release task.

  • Basic Information

    Set the name of the task. 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 to be grayscale released.

    • Click the dropdown list to select a composed app.

    • Click Select on the right side of the service to be grayscale released.

    Note

    Grayscale release only supports composed apps, not apps based on templates.

  • New Version Settings

    Set the service version number, number of pod replicas, and containers for the new version.

    ParameterDescription

    New Version Number

    The version number of the new version. The new version number can only contain lowercase letters and numbers, and can be up to 16 characters long.

    Replica

    The number of pod replicas for the new version. Click chevron-up/chevron-down to increase/decrease the number of pod replicas.

    Add Container

    Create containers to run within the pod. You can create multiple containers within a pod.

    • Click Add Container to create a container.

    • Hover over a created container, then click pen on the right to edit the container settings.

    • Hover over a created container, then click trash-light on the right to delete the container.

    • Directly enter the URL of the container image in the text box to replace the container image of the old version while keeping other container settings unchanged.

  • New Version Settings > Add Container > Container Settings

    Configure the container’s image, name, type, and resources.

    ParameterDescription

    Image

    The image required to create the container.

    • Enter the image name (e.g., nginx:latest) or path (e.g., docker.io/nginx:latest), then press Enter to search for the image.

    • If you only enter the image name, the image will be pulled from Docker Hub by default. To use a private image registry, you need to create a Secret containing the information for the private image registry, and then select the private image registry on the left side of the Image text box.

    • Click template to browse images in the current image registry.

    Container Name

    The name of the container. The name can only contain lowercase letters, numbers, and hyphens (-). It must start and end with a lowercase letter or number, with a maximum length of 63 characters.

    Container Type

    The type of container.

    • Init Container: A container that performs initialization tasks for the working containers. The working containers will only start after all init containers have successfully completed. If an init container fails, the system sets the status of the pod to failure.

    • Work Container: A container that runs the application. It is generally recommended to have only one work container running in each 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

    Configure the ports for the container. Click Use Default Port of Images to set the container ports to the default ports of the image. Click Add Port to set multiple ports for the container.

    ParameterDescription

    Protocol

    The protocol that the application in the container actually listens to. To use the Application Governance features provided by KubeSphere, ensure that the selected protocol matches the protocol that the application in the container actually listens to.

    Name

    The name of the port. To use the Application Governance features provided by KubeSphere, use the lowercase protocol name as a prefix for the port name (e.g., http-).

    Container Port

    The port number that the application in the container actually listens to.

  • New Version Settings > Add Container > Image Pull Policy

    Set whether to pull images from the image registry when creating or updating Pods.

    ParameterDescription

    Use Local Image First

    When creating or updating a pod, prioritize using the images stored by the container runtime on the node.

    Pull Image Always

    When creating or updating a pod, pull the image from the image registry every time.

    Use Local Image Only

    When creating or updating a pod, only use the images stored by the container runtime on the node. If the required image is not available locally, the pod may be created with an exception.

  • New Version Settings > Add Container > Health Check

    Check the health status of the container. Before using this feature, you need to configure the application within the container to return the results of the health check.

    KubeSphere supports the following types of health check:

    ParameterDescription

    Liveness Check

    Checks if the container is alive. If the liveness check fails, the system will attempt to restart the container.

    Readiness Check

    Checks if the container is ready to process requests. If the readiness check fails, the system will prevent access to the pod through a service.

    Startup Check

    Checks if the container has started. If the startup check fails, the system will disable other probes for the container and attempt to restart it.

    KubeSphere supports the following check methods:

    ParameterDescription

    HTTP Request

    Sends an HTTP GET request to the virtual IP address of the pod. If the response status code is 2XX or 3XX, the check is considered successful.

    Command

    Runs a command in the container. The check is considered successful if the command’s exit code is 0.

    TCP Port

    Attempts to establish a TCP connection with the specified container port. The check is considered successful if the connection is established.

  • New Version Settings > Add Container > Health Check > Add Probe

    Create probes for liveness, readiness, or startup checks on the container.

    • Click Add Probe to create a probe.

    • Hover over the created probe, then click pen on the right to edit the probe settings.

    • Hover over the created probe, then click trash-light on the right to delete the probe.

    ParameterDescription

    Path

    The protocol (HTTP or HTTPS), the path relative to the virtual IP address of the pod for HTTP requests, and the port number for the request. Only available when the health check method is HTTP Request.

    Command

    The command to run in the container. You can use commas (,) to separate the commands and its parameters. Only available when the health check method is Command.

    Port

    The container port number for TCP checks. Only available when the health check method is TCP Port.

    Initial Delay

    The delay time in seconds before the probe is initiated after container startup.

    Timeout

    The timeout period for the probe in seconds. After the timeout, the check will be considered a failure. The value must be an integer, with a minimum of 0.

    Check Interval

    The time interval for performing checks in seconds. The value must be an integer, with a minimum of 1.

    Success Threshold

    The minimum consecutive successes required to consider the check successful after a failure. The minimum value is 1. For liveness probes and startup probes, this parameter must be 1.

    Failure Threshold

    The minimum consecutive failures required to consider the check failed after a success. The minimum value is 1.

  • New Version Settings > Add Container > Lifecycle Management

    Configure actions to be performed after the container starts or before it terminates for environment checking or graceful termination. Before using this feature, you need to configure the application within the container to return the results of the performed action.

    ParameterDescription

    Post-start Action

    The action to be performed after the container starts. If the post-start action fails, the system will attempt to restart the container.

    Pre-stop Action

    The action to be performed before the container terminates. This action follows these rules:

    • If the pre-stop action fails, the system will terminate the container immediately.

    • The default period for the graceful termination of a container is 30 seconds. If the pres-stop action is still running when the grace period ends, the system will provide a one-time grace period of 2 seconds.

    • After the grace period ends, regardless of whether the pres-stop action has finished, the system will terminate the container.

    KubeSphere supports the following execution methods for post-start actions and pre-stop actions:

    ParameterDescription

    HTTP Request

    Sends an HTTP GET request to the virtual IP address of the pod. If the response status code is 2XX or 3XX, the action is considered successful.

    Command

    Runs a command in the container. The action is considered successful if the command’s exit code is 0.

    TCP Port

    Attempts to establish a TCP connection with the specified container port. The action is considered successful if the connection is established.

  • New Version Settings > Add Container > Lifecycle Management > Add Action

    Create post-start or pre-termination actions for the container.

    • Click Add Action to create an action.

    • Hover over the created action, then click pen on the right to edit the action settings.

    • Hover over the created action, then click trash-light on the right to delete the action.

    ParameterDescription

    Path

    The protocol (HTTP or HTTPS), the path relative to the virtual IP address of the pod for HTTP requests, and the port number for the request. Only available when the action execution method is HTTP Request.

    Command

    The command to run in the container. You can use commas (,) to separate the commands and its parameters. Only available when the action execution method is Command.

    Port

    The container port number for TCP checks. Only available when the action execution method is TCP Port.

  • New Version Settings > Add Container > Start Command

    Configure the command to be executed inside the container when it starts.

    ParameterDescription

    Command

    The startup command to be executed.

    Parameters

    The parameters of the startup command. Use commas to separate multiple parameters.

  • New Version Settings > Add Container > Environment Variables

    Configure 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 to be referenced must belong to the same project as the container. The values of environment variables will not dynamically change with changes made in the ConfigMap or Secret after the container is created.

    • Click trash-light on the right of the created environment variable to delete it.

    ParameterDescription

    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 in 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 > Container Security Context

    Configure the permissions of the container process in the Linux system.

    ParameterDescription

    Access Control

    Access permissions for the container process.

    • Privileged Mode: Run the container process as the root user on the host.

    • Allow Privilege Escalation: Allow the container process to gain more privileges than the parent process. This option is enabled by default when Privileged Mode is enabled.

    • Root Directory Read-Only: Set the root directory of the container filesystem to read-only.

    User and User Group

    The users and user groups running the entry point of container processes.

    • Run as Non-root: Checks if the container will run as the root user before starting. If the container is set to run as the root user, it won’t start. When this feature is enabled, the system will ignore the Privileged mode setting.

    • User: The UID (User ID) executing the container process entry point. Defaults to the UID specified in the image metadata.

    • User Group: The GID (Group ID) executing the container process entry point. Defaults to the default GID of the container runtime.

    SELinux Context

    The SELinux labels for the container process, including Level, Role, Type, and User. For more information, refer to the SELinux Documentation.

    Capabilities

    Additional capabilities added to or removed from the container process in the Linux system. Refer to the Linux Documentation for the list of Linux process capabilities.

    • When adding or removing capabilities for the container process, you need to remove the CAP_ prefix from the capability names. For example, entering SYS_TIME in the Drop text box will remove the CAP_SYS_TIME capability from the container process.

    • Click Add to set multiple instructions for adding or removing capabilities.

  • New Version Settings > Add Container > Sync Host Timezone

    Select the checkbox on the left of Synchronize Host Timezone will synchronize the timezone between the container and the host.

  • Strategy Settings

    Set the traffic distribution strategy for the grayscale 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 specify the traffic distribution ratio between the new and old versions, or forward requests to the new or old version based on request parameters.

      ParameterDescription

      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 distribution strategy.

Receive the latest news, articles and updates from KubeSphere


Thanks for the feedback. If you have a specific question about how to use KubeSphere, ask it on Slack. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.

What’s on this Page