Create an application service

Prerequisites

• You have created an application.

• A cluster is created or a cluster is imported.

Creating an application service involves the following six steps:

1. Enter basic information

2. Configure the pod template

3. Elastic Configuration

4. Access configuration

5. Configure deployment and scheduling

6. Preview and submit

1. Enter basic information

1. Log on to the console. In the navigation pane on the left, click Publishing and O&M > Application Service.

2. On the Application Service page, click Create Application Service.

3. On the Create Application Service page, enter the following basic information and click Next.

   • Namespace: Select a namespace. The first namespace in the list is selected by default.

   • Application service name: The name of the container service. The name can contain lowercase letters, digits, and hyphens. It must start with a letter and end with a letter or a digit. The name must be unique within the same workspace group.

   • Application: Select an application to associate with the container service.

   • Stateful mode: Disabled by default. If you enable this mode, pod names are appended with a numerical suffix, such as -0 or -1. New pod names are not generated during pod recreation. For more information, see Configure LHC Pod Domain Names.

   • Volume template configuration: Optional. Used to mount storage. You can click Add Configuration to set multiple templates. The configuration items are as follows:

     • Name: Enter a template name. The name can contain letters, digits, and hyphens. It must start with a letter and end with a letter or a digit.

     • Storage class: Specifies the supported storage category. Clicking Create Storage Class redirects you to the storage page.

       Note

       • Storage classes are typically defined by a system administrator. The specific classes vary based on factors such as storage Service-level agreements (SLAs) and backup policies.

       • For a storage class to be used in a multi-cluster environment, it must exist in all clusters.

     • Capacity: Set the capacity of the volume template. The unit is GiB.

       Note

       The volume capacity is limited by the configured capacity of the persistent volume (PV). For more information about how to set the PV capacity, see Create a persistent volume.

   • Description: Optional. A description of the container service.

2. Configure the pod template

Configure the containers within the pod. A pod can contain more than one container. You can click Add App Container to configure multiple containers for a single pod.

Basic options

• Container type: Supports APP and INIT types.

• Container name: The name of the container.

• Image source: You can use an Image repository or a Build record.

  • Image repository: Enter the image repository address, for example, registry-cnhz.cloud.alipay.com/aks/nginx:1.8.

    Note

    If you configure multiple containers, the image addresses must be different.

  • Build record: If you select this source type, the build associated with the application of the application service is automatically used. For more information, see Image build.

    Note

    The Build record option is not currently supported. If you need this feature, you can submit a ticket.

  • Use secret: If the image is private and requires authentication, you can enable Use secret to pull the image. If you have not created a secret, click Create Secret. For more information, see Create a secret.

• CPU configuration: Set the number of CPU cores for the container. Request Cores is the minimum guaranteed number of cores. Maximum Cores is the maximum number of cores that can be used. Conversion: 1 core = 1000 millicores.

• Memory configuration: Set the amount of memory for the container. Request Memory is the minimum guaranteed amount of memory. Maximum Memory is the maximum amount of memory that can be used. Conversions: 1024 Bytes = 1 KiB, 1024 KiB = 1 MiB, 1024 MiB = 1 GiB, 1024 GiB = 1 TiB.

• Start command: Optional. Specifies the command to run when the container starts.

Advanced configuration

Disabled by default. If you enable it, configure the following options.

• hostNetwork configuration: Disabled by default. If you enable this option, the pod IP address is the same as the node IP address. In host mode, a maximum of one pod can be run on a node.

• Environment variable configuration: Set key-value pairs to pass to the application process when the container starts, for example, USER=tester.

• Volume configuration: Configure the volumes that are used by the container. This option supports multiple types such as local storage, temporary directories (emptyDir), and NFS. Currently, only mounting directories from the host where the container resides is supported.

• Health check configuration: Includes two check mechanisms: readiness and liveness. For more information, see Kubernetes Probe.

• Lifecycle hook configuration: Add lifecycle hooks for the container, which run after the container starts and before it stops.

• Simple Log Service configuration: Configure Simple Log Service (SLS). You can select an existing Logstore or create a new one.

  Note

  If you are using the SLS configuration feature for the first time, go to the SLS console to enable index configuration. For more information, see Configure indexes.

For more information, see Advanced configuration.

Configuration override

Disabled by default. If you enable it, configure the following options.

• Environment variable configuration: You can set environment variables for each deployment unit individually to override the default configurations in the application service. This applies only to manually entered environment variables.

• Registry Address: You can configure different image addresses for each deployment unit to override the default configuration in the application service.

3. Configure elasticity

Replica scaling policy configuration: The following two scaling policies are supported.

• Fixed number of replicas: The default value is 0. You can select a deployment unit and change the value to the desired number of replicas. The application service will maintain a fixed number of pod replicas at runtime.

• Auto scaling: Configure the following auto scaling rules for the application service.

  • Fixed number of replicas: The default value is 0. You can select a deployment unit and set the desired number of replicas.

  • Minimum replicas: The minimum number of pod replicas for auto scaling.

  • Maximum replicas: The maximum number of pod replicas for auto scaling.

  • Rules: The metric type on which the current scaling rule is based. Click + Add Configuration and configure the following options.

    • Rule type: The type of rule on which the current scaling rule is based. Currently, CPU, Memory, QPS, and Response time are supported.

    • Target type: The type of value that the metric is expected to reach. Currently, Utilization and Average Resource Usage are supported.

    • Utilization/Average value: Enter the utilization or average value.

    • Unit: Automatically matched based on the selected rule type. You do not need to enter a value.

  • Advanced configuration: Disabled by default. If you enable it, configure the following options.

    • Scale: You can adjust the scaling rate by setting a percentage or a specific number. The unit is percentage or count.

    • Interval: The time interval between the last scaling operation and the current one, in seconds.

    • Cooldown period: The cooldown period for a scaling operation. This is the time window after a scaling operation completes during which no new scaling operations are triggered. The unit is seconds.

      Note

      After a scaling activity is complete, no other scaling activities are performed during the specified cooldown period.

4. Configure access (Optional)

Application services support two access methods: Unified Ingress and Server Load Balancer. Server Load Balancer provides port-based request load balancing, while Unified Ingress provides rule-based request load balancing. Plan your configuration based on your business needs.

Server Load Balancer

You can set the access method when you create an application service, or you can add it after the application service is created.

Set the access method when creating an application service

1. On the Access Configuration page, click Add Server Load Balancer.

2. In the Server Load Balancer configuration, enter the following information and click Next.

   • Load balancer name: Enter a service name. The system generates a service name with the prefix Application service name- by default. The service name can contain lowercase letters, digits, and hyphens. It must start with a letter and end with a letter or a digit.

   • Access method: Select the access method for the SLB service. The following options are supported:

     • Internal network: Creates an internal-facing LoadBalancer and forwards traffic to the corresponding container port.

     • Public network: Creates an Internet-facing LoadBalancer and forwards traffic to the corresponding container port. The access method consists of the public-facing SLB service address and the configured access port, for example, 10.117.117.117:80.

     • Custom: In custom mode, a LoadBalancer-type service is created in each selected deployment unit, reusing an existing SLB instance using the ID that is entered by the user.

       Important

       • Currently, only Alibaba Cloud SLB instance IDs are supported. Support for more partner models is coming soon.

       • In Alibaba Cloud scenarios, the reused SLB instance must meet the following conditions:

         • The reused SLB instance must be manually created in the SLB console.

         • The desired listener port must not be in use.

         • If it is an internal-facing SLB instance, it must be in the same VPC as the cluster corresponding to the deployment unit.

   • Enable intra-cluster VIP forwarding optimization: If enabled, requests to the SLB VIP from within the cluster are directly forwarded by kube-proxy to the corresponding backend service.

   • Deployment unit ID: This option is displayed only when the access method is set to Custom. Enter the corresponding SLB instance ID for each deployment unit.

     Note

     • You can set the same SLB instance ID for different deployment units under the same application service.

     • Ensure that the frontend port configured in the application service's port mapping is not already in use by another application service on the existing SLB instance. Otherwise, the application service will fail to publish due to a port conflict.

   • Federated SLB instance: This option is displayed only when the access method is Internal network or Public network and Use Federated SLB is enabled. Select the corresponding federated SLB instance from the drop-down list. The deployment units of the selected federated SLB must cover all deployment units selected in the Configure elasticity step of the application service.

     Note

     • To create a new federated SLB instance, see Create a federated SLB instance.

     • To modify the deployment units of a federated SLB configuration, see Configure a federated SLB instance.

   • Enable graceful shutdown: If enabled, the system waits for a period of time after the traffic weight of a backend server is set to zero before the system removes the backend server from the SLB backend server list.

   • Graceful shutdown timeout (seconds): This option is displayed after you enable Enable graceful shutdown. Configure the graceful shutdown wait time.

   • Port mapping: Click Add Port Mapping and enter the following information.

     • Protocol: Supports TCP, HTTP, and HTTPS protocols.

     • Forwarding rule: Create a port forwarding rule.

       • HTTP/HTTPS protocols support Round-robin, Weighted round-robin, and Weighted least connections.

       • TCP protocol supports Round-robin, Weighted round-robin, Weighted least connections, Four-tuple consistent hashing (TCH), and Source IP consistent hashing (SCH).

         Note

         • Four-tuple consistent hashing: Based on four-tuple consistent hash (source IP + destination IP + source port + destination port). Requests with the same four-tuple are scheduled to the same backend server.

         • Source IP consistent hashing: Based on source IP address consistent hash. Requests from the same source address are scheduled to the same backend server.

     • Frontend port: The port that the workload in the container image actually listens on. The port range is 1 to 65535.

     • Backend port: The port on the SLB instance to which the container port is mapped. This port is used when accessing the workload with the SLB IP address. The port range is 1 to 65535.

     • Bandwidth: The unit is Mbps. The default value is -1, which indicates unlimited bandwidth. The value can be an integer from 1 to 5120, or -1.

     • Certificate ID: When the protocol is HTTPS, you must enter the relevant certificate ID.

     • Connection request timeout: The timeout for HTTP/HTTPS listener requests, in seconds. The default is 60. If a backend service takes longer than the timeout to respond to a request, the load balancer will stop waiting and return a 504 error to the client.

     • HTTP health check: When the protocol is HTTPS or HTTP, you can enable this option. An HTTP health check simulates a browser's access behavior by sending a HEAD or GET request to check whether the backend pod is healthy. If enabled, configure the following items.

       Note

       TCP health checks are enabled by default for TCP ports. You can enable an additional HTTP health check here as needed.

       • URL: Specify the health check path.

       • Domain Name: Optional. If your application pod needs to verify the host field of the request, you must configure the relevant domain name to ensure the health check works correctly. If a domain name is configured in the health check, the SLB instance will add the domain name to the host field. Otherwise, the SLB instance will not include the host field in the request, which may cause the server to reject the health check request, leading to a failure.

       • Port: The port used by the health check service to probe the backend pod. The port range is 1 to 65535.

       • Timeout (s): The time to wait for a response. If the backend pod does not respond correctly within the specified time, the health check is considered failed. The default is 3 seconds.

       • Interval (s): The time interval for the SLB health check requests. The default is 5 seconds.

       • HTTP health status code: Select the HTTP status code that indicates a successful health check. The default is http_2xx.

     • Session persistence: When session persistence is enabled, the SLB listener distributes access requests from the same client to the same backend pod.

       HTTP session persistence is based on cookies. Server Load Balancer provides two cookie handling methods:

       • Insert cookie: You only need to specify the cookie's expiration time. When a client accesses for the first time, the load balancer inserts a cookie into the response (by inserting SERVERID into the HTTP or HTTPS response message). The next time the client accesses with this cookie, the SLB service will forward the request to the previously recorded backend server.

       • Rewrite cookie: You can specify the cookie to be inserted into the HTTPS or HTTP response. You must maintain the expiration time and lifetime of this cookie on your backend pod.

         When the SLB service detects a user-defined cookie, it will rewrite the original cookie. The next time the client accesses with the new cookie, the SLB service will forward the request to the previously recorded backend pod. For more information, see Configure session persistence rules.

     • Access control: If enabled, this feature supports filtering access by IP address using blacklists and whitelists.

       Note

       • Before you use the access control feature, you must create an access control policy group in the Alibaba Cloud Server Load Balancer console. For instructions, see Create an access control policy group.

       • Before you use the access control feature, you must disable Enable intra-cluster VIP forwarding optimization.

       • For HTTP and HTTPS protocols, the XForwardFor option is enabled by default to obtain the real client IP address using the X-Forwarded-For header.

       • Access control policy type: Select Blacklist or Whitelist to deny or allow specific IP addresses to access the load balancer.

       • Access control group ID: Enter the ID of the access control policy group created in the Alibaba Cloud Server Load Balancer console.

Unified Ingress

Unified Ingress supports configuring forwarding rules to direct traffic to the corresponding container ports. You can set the access method when you create an application service, or you can add it after the application service is created.

Add an access method when creating an application service

On the Access Configuration page, click Add Unified Ingress, enter the following information, and click Next.

• Service name: Enter a service name. The system generates a service name with the prefix Application service name- by default. The service name can contain lowercase letters, digits, and hyphens, and must start with a letter and end with a letter or a digit.

• Unified Ingress instance: Select a unified ingress instance that you created. For more information, see Create a unified ingress instance.

• Access protocol: Select a protocol supported by the unified ingress instance, typically HTTP or HTTPS.

• Routing mode: Select Cell-based or Non-cell-based.

  • Cell-based enables cell-based forwarding for this unified ingress instance. Requests are sharded based on a specific UID in the request cookie, and each zone processes requests from a fixed range of users.

  • Non-cell-based means random distribution.

• Unified Ingress rule: Click Add Unified Ingress Rule to add a forwarding rule, and enter the following information.

  • Domain Name: Enter the request domain name to be forwarded.

  • Forwarding path: The specific container path address to which the request is forwarded. The default is the root directory.

  • Backend port: The port that the workload program in the container image actually listens on. The port range is 1 to 65535.

    Important

    Adding or deleting existing forwarding rules will cause the online service to become unavailable during publishing.

  • Enable health check: A health check simulates a browser's access behavior by sending a HEAD or GET request to check whether the backend pod is healthy. It is disabled by default. If enabled, configure the following parameters:

    Note

    Before you use the unified ingress health check, confirm that the version of the cloud-controller-manager component in all clusters within the current workspace group is 1.3.0 or later.

    • Health check type: Currently, only the HTTP health check type is supported.

    • Health Check URI: Specify the health check path.

    • Healthy Threshold: The default is 1, which means the corresponding backend server is considered healthy after one consecutive successful health check.

    • Unhealthy Threshold: The default is 5, which means the corresponding backend server is considered unhealthy after five consecutive failed health checks.

    • Health check interval: The time interval for health checks. The default is 10 seconds.

    • Health check timeout: The time to wait for a response. If the backend pod does not respond correctly within the specified time, the health check is considered failed. The default is 3 seconds.

    • Health check port: The port used by the health check service to probe the backend pod. The port range is 1 to 65535.

    • Health check domain name: Optional. If your application pod needs to verify the host field of the request, you must configure the relevant domain name to ensure the health check works correctly. If a domain name is configured in the health check, Spanner will add the domain name to the host field. Otherwise, Spanner will not include the host field in the request, which may cause the server to reject the health check request, leading to a failure.

    • Health check method: Select the type of request for the health check. HEAD and GET methods are supported.

    • Expected return code: Select the HTTP status code that indicates a successful health check. The default is http_2xx.

  • Session persistence: When session persistence is enabled, the unified ingress distributes access requests from the same client to the same backend pod. Session persistence is based on cookies and provides two cookie handling methods:

    Note

    To use unified ingress session persistence, the following conditions must be met:

    • Only single deployment unit scenarios in Non-cell-based forwarding mode are supported.

    • The version of the cloud-controller-manager component in all clusters within the current workspace group must be 1.3.0 or later.

    • The spanner image version used by the unified ingress cluster corresponding to the application service's unified ingress instance must be 1.3.0 or later.

    • Insert cookie: You must configure the session persistence timeout. When a client accesses for the first time, the unified ingress inserts a cookie into the response. The next time the client accesses with this cookie, the unified ingress service will forward the request to the previously recorded backend server.

    • Rewrite cookie: You must specify the name of the cookie to be inserted into the HTTP response. You need to maintain the expiration time and lifetime of this cookie on your backend pod.

ClusterIP Service

A ClusterIP service provides services through an internal IP address of the cluster. The service can only be accessed from within the cluster, and only nodes and pods within the cluster can access it.

Add a ClusterIP Service when creating an application service

1. On the Access Configuration page, click Add ClusterIP Service.

2. In the ClusterIP Service configuration, click Add Port Mapping and configure the following information.

   • Protocol: Supports TCP and UDP protocols.

   • Frontend port: The port that the workload in the container image actually listens on. The port range is 1 to 65535.

   • Backend port: The port on the ClusterIP Service to which the container port is mapped. The port range is 1 to 65535.

3. Click Submit.

Headless Service

Each Endpoint that corresponds to a Headless Service, which is each pod, has a corresponding DNS domain name. You can configure a Headless Service name so that pods can access each other through their domain names. A Headless Service is not assigned a ClusterIP address, and kube-proxy does not handle this type of service. However, pods can be accessed through domain name resolution. For more information, see Configure LHC Pod Domain Names.

You can add a Headless Service name when you create an application service, or you can add it by editing the application service after it has been created. The change takes effect after you publish the application service.

Add a Headless Service when creating an application service

1. On the Access Configuration page, click Add Headless Service.

2. In the Headless Service configuration, enter the Headless Service name. The name consists of a service name prefix and the Headless Service name.

   • Prefix: The system generates the service name prefix Application service name- by default.

   • Headless Service name: Enter a name. It can contain lowercase letters, digits, and hyphens (-). The maximum length is 20 characters.

3. Click Next.

5. Configure deployment and scheduling (Optional)

You can customize the deployment and scheduling configuration. If you do not modify the configuration, the system uses the default configurations when the application service is published.

This configuration item is used to configure the information that is required to deploy the container service. The information includes the following:

• Use beta verification: When you publish the application service, a portion of the pods are released first. After you confirm that there are no issues, the release continues. This feature is enabled by default.

  When a beta group is enabled, a special beta group is set for the application service during release. In this group, the system selects one pod from each deployment unit. The beta group is released in the first batch.

  • After the beta group is released, the application service release is automatically paused, waiting for the system owner or an O&M engineer to confirm the release status. If the container service is released as expected, click Confirm Beta Group to continue the grouped release of the application service.

  • The beta group can be determined in combination with all grouping strategies. When you create a new release request, Add Beta Group is enabled by default. In this case, a beta group is set for all application services in the same release order.

• Deployment grouping strategy: Specifies the grouping strategy for pods when the container service is released. The following strategies are supported, as described in the following table.

  Strategy Type	Description
  Group by deployment unit	The default option is Group by deployment unit. Releases based on the deployment unit dimension distribute pods as evenly as possible across deployment units.
  One pod per group	One pod per group. The number of groups equals the number of pods.
  All in one group	All pods are released in a single group.
  Quick grouping	Publishing by group dimension.
  All in one group (Beta unit mode)	Pods are released based on the specified maximum number of pods that can be changed at the same time. After you select this strategy, you can configure the following options. Maximum step size: The maximum number of pods to change in each normal group (excluding the beta group). If the maximum step size is set to 2, the number of pods in a normal group will not exceed 2. Deployment unit release order: If the deployment unit release order is not set, pods in each deployment unit are released or changed based on the default deployment unit order. If the deployment unit release order is set, pods in each deployment unit are released or changed according to the specified order. Use beta verification: If this feature is not enabled, all pods are released sequentially without a beta group or group pauses. You do not need to confirm any groups. The next normal group starts automatically after the previous one is complete. If enabled, the first unit in the deployment order is released as a whole beta group, which requires user confirmation. All pods in the remaining units are released sequentially, and these groups do not have group pauses. Note If you select All in one group (Beta unit mode), it is possible that all pods within a deployment unit are being released at the same time, making them unavailable. To avoid this while speeding up the release process and ensuring a certain number of pods are available, we recommend selecting Concurrent mode by deployment unit percentage.
  Concurrent mode by deployment unit percentage	To accelerate the release process by deployment unit, select this grouping strategy. After you select this strategy, you must specify a percentage value. During a release, a batch consists of the specified percentage of pods from each deployment unit. For example, if the percentage is set to 25%, the first batch releases the first 25% of pods from all deployment units, the second batch releases the pods in the 25% to 50% range from all deployment units, and so on, until 100% of the pods are released. The following figure provides an example.

• Deployment unit release order: This option is displayed only when the grouping strategy is Group by deployment unit or All in one group (Beta unit mode). It is disabled by default. This option is used to reorder the original deployment unit release sequence. If you enable this option, you can drag and drop deployment units to sort them. This lets you flexibly adjust the release order based on your business needs.

• Minimum number of groups: You must set this parameter if the grouping strategy is Group by deployment unit or Quick grouping.

  Note

  The minimum number of groups is a reference value for grouping during release. The actual number of groups is affected by the distribution of pods in deployment units at the time of release.

• Group pause: You can pause the release after only the first group or after every group. The release continues after you confirm it.

  • Pause all: Selected by default. The release pauses at each group.

  • Pause first batch: If you select Pause first batch, the release pauses only at the first group.

• Group release mode (Parallel/Serial): Not selected by default. The system's default mode is used. If you select this option, you can choose a parallel or serial group release mode.

• Custom tags: When the application service is published, these tags are published as labels on the pod. Enter the tags in the key=value format. Separate multiple labels with commas.

• Annotations: When the application service is published, these annotations are published as annotations on the pod. Enter the annotations in the key=value format. Separate multiple annotations with commas (,).

• Custom property configuration: Supports manual configuration of the pod deletion grace period.

• Pod topology spread constraints: Configure a spread scheduling policy to distribute pods across different machines to ensure high availability of the application service.

• Application service-to-node affinity configuration: Add node-level affinity configurations for the application service. You can use node labels to restrict the range of nodes where the application service can be scheduled.

  Note

  Affinity settings take effect only when pods are recreated. The affinity configuration will always take effect on the first release. For subsequent releases, you must choose a replacement upgrade method for the affinity configuration to take effect.

• Inter-application service affinity configuration: Add pod-level affinity configurations for the application service. You can restrict the range of nodes where the application service can be scheduled by choosing to schedule the pods on the same nodes as or different nodes from certain other application services.

  Note

  Affinity settings take effect only when pods are recreated. The affinity configuration will always take effect on the first release. For subsequent releases, you must choose a replacement upgrade method for the affinity configuration to take effect.

• Deregister from service registry: Disabled by default. If enabled, configure the wait time after deregistration.

  Note

  The version of the cloud-controller-manager cluster component must be 1.2.0-pub or later to enable this feature. Otherwise, the application service will fail to publish.

• Application service taint toleration configuration: After you configure this feature, the application service is deployed on nodes that have the corresponding taints. In the dialog box that appears, enter a Key and Value, and select an Effect. The following effects are available:

  • NoSchedule: Pods without a matching toleration are not allowed to be scheduled on this node.

  • NoExecute: If a pod without a matching toleration is already running on the node, the pod is evicted. If a pod without a matching toleration is not yet running on the node, it will not be scheduled on that node.

  • PreferNoSchedule: Tries to avoid scheduling pods without a matching toleration on this node.

• Inject SOFAMesh: The cluster must have the Mesh feature enabled. If traffic shifting is enabled, each release forwards traffic to the new version based on the specified traffic shifting rules. You can also configure these rules during the release process. If you enable this feature, the service mesh feature is activated for the application service. This lets you manage and govern the application service in the Service Mesh console.

6. Preview and submit

On the application service Preview page, confirm that the information is correct and click Submit.