This section describes how to create a Deployment and register it as a microservice.

Spring Cloud microservice instances are managed through Kubernetes Deployments. The pod replicas of a Deployment are the instances of the microservice.

Prerequisites

  • The KubeSphere Spring Cloud extension must be installed and enabled on the KubeSphere platform.

  • You need to join a project and have the Spring Cloud Microservice Management permission in the project. For more information, see Project Members and Project Roles.

  • The application in the container image used to create the Deployment must comply with Nacos specifications. For more information, refer to the Nacos official documentation.

Steps

Refer to Parameter Description to set the parameters for the Deployment.

  1. Log in to the KubeSphere web console with a user who has Spring Cloud Microservice Management permissions and enter your workspace.

  2. Click  Spring Cloud > Microservices in the left navigation pane.

  3. Select a project from the drop-down list in the upper left corner of the page.

  4. Click Enable Spring Cloud.

  5. Click Create on the page.

  6. On the Basic Information tab, set the basic information for the Deployment, then click Next.

  7. On the Pod Settings tab, set the number of replicas, containers, update strategy, security context, scheduling rules, and metadata for the pods managed by the Deployment, then click Next.

  8. On the Storage Settings tab, mount volumes for the containers managed by the Deployment, then click Next.

  9. On the Advanced Settings tab, specify nodes for the pods managed by the Deployment, and set the metadata for the Deployment, then click Create.

    After the Deployment is created, it will be registered as a microservice and appear in the microservice list.

    Note

    Deployments created on the Spring Cloud > Microservices page will be automatically registered as microservices. To perform operations on microservice instances (e.g., adjusting the number of instances), you need to go to the Workloads > Deployments page to operate on the Deployment corresponding to the microservice.

Parameter Description

  • Basic Information

    Set the basic information for the Deployment.

    Parameter Description

    Name

    The name of the Deployment. 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.

    Alias

    The alias of the Deployment. Different Deployments can have the same alias.

    Description

    The description of the Deployment. The description can contain any characters and can be up to 256 characters long.

  • Pod Settings > Pod Replicas

    Click add/subtract to increase/decrease the number of pod replicas. The minimum value is 1.

  • Pod Settings > 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 pen on the right to edit the container’s settings.

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

  • Pod 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 template 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 Reservation

    CPU resources reserved for the container, in cores.

    CPU Limit

    The maximum CPU resources allowed for the container, in cores.

    Memory Reservation

    Memory resources reserved for the container, in MiB.

    Memory Limit

    The maximum memory resources allowed for the container, in MiB.

    GPU Type

    The type of GPU allowed for the container.

    GPU Limit

    The maximum number of GPUs allowed for the container, in GPUs.

  • Pod 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.

  • Pod 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.

  • Pod 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.

  • Pod 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 pen on the right to edit the probe’s settings.

    • Hover over a created probe, then click trash-light 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.

  • Pod 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.

  • Pod 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 pen on the right to edit the action’s settings.

    • Hover over a created action, then click trash-light 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.

  • Pod 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.

  • Pod 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 trash-light 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.

  • Pod 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.

  • Pod 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.

  • Pod Settings > Update Strategy

    Set the strategy for pod updates during deployment.

    Deployment:

    Parameter Description

    Rolling Update (Recommended)

    Gradually replaces old pod replicas with new ones. During the upgrade, traffic is load-balanced between old and new pod replicas, ensuring no service interruption. If you choose this strategy, you need to further configure the Maximum Unavailable Pods and Maximum Surge Pods.

    Recreate

    Deletes all old pod replicas before creating new ones. Service will be interrupted during the upgrade.

  • Pod Settings > Update Strategy > Rolling Update Settings

    Set the relevant parameters for the rolling update strategy.

    Deployment:

    Parameter Description

    Max Unavailable Pods

    The maximum number or percentage of unavailable pod replicas allowed during the update process.

    Max Surge Pods

    The maximum number or percentage of extra pod replicas allowed during the update process.

  • Pod Settings > Pod Security Context

    Set the permissions of all container processes in the pod within the Linux system. If both the pod security context and the container security context have set the user, user group, and SELinux context, the settings in the container security context will override those in the pod security context.

    Parameter Description

    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.

  • Pod Settings > Pod Scheduling Rules

    Set rules for scheduling pod replicas to nodes.

    Parameter Description

    Default Rule

    Do not specify a particular rule; let the system decide which node to schedule the pod replicas to.

    Scatter Scheduling

    Try to schedule pod replicas to different nodes as much as possible.

    Concentrate Scheduling

    Try to schedule pod replicas to the same node as much as possible.

    Custom Rule

    Schedule pod replicas to nodes according to user-defined rules. If you select this option, you need to further customize the scheduling rules.

  • Pod Settings > Pod Scheduling Rules > Custom Rules

    Set custom pod scheduling rules.

    • Click Add to set multiple rules.

    • Click trash-light on the right side of a created rule to delete it.

    Parameter Description

    Type

    The type of the rule.

    • Schedule with Target: Pod replicas will be scheduled onto the same node as pods with specific labels in the current project.

    • Away from Target: Pod replicas will be scheduled onto different nodes from pods with specific labels in the current project.

    Strategy

    The enforcement strategy of the rule.

    • Prefer Matching: Try to meet the rule requirements as much as possible. If the rule requirements cannot be met, pod replicas will be scheduled onto nodes that do not meet the requirements.

    • Must Match: The rule requirements must be met. If the rule requirements cannot be met, pod replicas cannot be scheduled onto any node.

    Target

    The target of the rule. Pod replicas will be scheduled onto the same node or different nodes as pods with the app=<target> label (<target> is the value selected here), depending on the rule’s type and strategy.

  • Pod Settings > Pod Graceful Termination

    Set the waiting time before container termination. The container will be forcibly terminated after the timeout. The default value is 30s.

  • Pod Settings > Add Metadata

    Set the metadata of the pod. Currently, only setting annotations for the pod is supported; setting labels for the pod is not supported.

    • Click Add to set multiple annotations.

    • Click trash-light on the right side of a created annotation to delete it.

  • Storage Settings

    Mount volumes, ConfigMaps or Secrets for containers.

    Parameter Description

    Mount Volume

    Mount persistent volumes, ephemeral volumes, or HostPath volumes to containers.

    Mount ConfigMap or Secret

    Mount data from a ConfigMap or Secret as a volume to a container.

    • Hover over an added volume, then click pen on the right to edit the volume settings.

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

  • Storage Settings > Mount Volume > Persistent Volume

    Mount a persistent volume for a container. The persistent volume claim used to create the persistent volume must belong to the same project as the container.

    Parameter Description

    Select Persistent Volume Claim

    Select the persistent volume claim used to create the persistent volume. This persistent volume claim must belong to the same project as the container. If there are no available persistent volume claims in the container’s project, you need to create one in advance.

    Mount Mode

    The method by which a volume is mounted to a container.

    • ReadWrite: Allows the container to read data from and write data to the volume.

    • ReadOnly: Only allows the container to read data from the volume.

    • Unmounted: The volume is not mounted to the container.

    Mount Path

    The path where the volume is mounted to the container. Click textfield to set the subpath of the volume to be mounted. If no subpath is set, the entire volume is mounted by default.

  • Storage Settings > Mount Volume > Temporary Volume

    Mount a temporary volume for a container. Temporary volumes have the following characteristics:

    • Automatically created by the system in the storage system of the node where the pod resides.

    • Automatically managed by the system, with a capacity limit equal to the node’s storage capacity.

    • Cannot store persistent data. The temporary volume is automatically created by the system when the pod is created and automatically deleted when the pod is deleted.

    Parameter Description

    Volume Name

    The name of the temporary volume.

    Mount Mode

    The method by which a volume is mounted to a container.

    • ReadWrite: Allows the container to read data from and write data to the volume.

    • ReadOnly: Only allows the container to read data from the volume.

    • Unmounted: The volume is not mounted to the container.

    Mount Path

    The path where the volume is mounted to the container. Click textfield to set the subpath of the volume to be mounted. If no subpath is set, the entire volume is mounted by default.

  • Storage Settings > Mount Volume > HostPath Volume

    Mount files or directories from the node where the pod is located to the container.

    • Files or folders at the same path on different nodes may differ, so pod replicas on different nodes may read different data from the HostPath volume.

    • You need to ensure that the mounted path exists on the node where the pod is located and that the pod process has the necessary permissions. Otherwise, the pod process will be unable to read data from or write data to the HostPath volume.

    Parameter Description

    Volume Name

    The name of the HostPath volume.

    Host Path

    The path of the file or folder on the node that needs to be mounted.

    Mount Mode

    The method by which a volume is mounted to a container.

    • ReadWrite: Allows the container to read data from and write data to the volume.

    • ReadOnly: Only allows the container to read data from the volume.

    • Unmounted: The volume is not mounted to the container.

    Mount Path

    The path where the volume is mounted to the container. Click textfield to set the subpath of the volume to be mounted. If no subpath is set, the entire volume is mounted by default.

  • Storage Settings > Mount ConfigMap or Secret

    Mount data from a ConfigMap or Secret as a volume to a container.

    Parameter Description

    Select ConfigMap/Select Secret

    Select a ConfigMap or Secret from the current project.

    Mount Mode

    Set how the data from the ConfigMap or Secret is mounted on the container. ConfigMaps and Secrets only support mounting as Read-Only or Do Not Mount.

    Mount Path

    Set the path on the container where the data from the ConfigMap or Secret is mounted.

    • The system will generate a folder based on the data in the ConfigMap or Secret, mapping each key-value pair to a file, where the key is the filename and the value is the file content.

    • Click textfield to specify key-value pairs from the ConfigMap or Secret to be mounted as files. If no subpath is specified, the entire ConfigMap or Secret is mounted by default. If a subpath is used, the files mounted into the container will not be dynamically updated with changes to the ConfigMap or Secret.

    Select Specific Key

    Mount key-value pairs from the ConfigMap or Secret as files into the container. Files mounted into the container will be dynamically updated with changes to the ConfigMap or Secret. Click Add to mount multiple key-value pairs.

    • Key: The key name of the key-value pair in the ConfigMap or Secret that needs to be mounted.

    • Path: The path within the container relative to the Mount Path. The specified key-value pair from the ConfigMap or Secret will be mounted at this path, overwriting any existing files at the Mount Path.

  • Advanced Settings

    Specify nodes for the pods managed by the Deployment and set the metadata for the Deployment.

    Parameter Description

    Select Node

    Schedule pod replicas to nodes with specified labels.

    • You can manually enter the label key-value pairs for the target node, or click Specify Node to select a node.

    • Click Add Node Selector to set multiple labels. Pod replicas will be scheduled to nodes that have all the specified labels.

    • Click trash-light to the right of a created label to delete it.

    Add Metadata

    Set labels and annotations for the Deployment.

    • Click Add to set multiple labels or annotations.

    • Click trash-light on the right side of a created label or annotation to delete it.