Create an application service

AKS provides two methods for creating application services:

This topic describes the standard procedure for creating an application service. To create an application service from a product template in the App Store, see Publish a product.

Prerequisites

• You have created an application.

• You have created a cluster.

The standard procedure for creating an application service consists of the following six steps:

1. Enter basic information

2. Configure the pod template

3. Configure scaling

4. Configure access (Optional)

5. Configure deployment and scheduling (Optional)

6. Preview and submit

I. Enter basic information

1. Log on to the Container Application Service console. In the navigation pane on the left, choose Application Publishing > Application Services.

2. On the Application Services page, click Create.

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

   • Namespace: Select a namespace in the cluster. The default value is default.

   • Application Service Name: The name of the application service.

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

   • Stateful Application: This feature is disabled by default. Stateful applications use a StatefulSet as the deployment workload.

     If you enable this option, configure a volume template as follows:

     1. Click Create New Template.

     2. On the Create Volume Template page, enter the following information and click Create.

        • 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 Type: Specifies the supported storage class. Valid values include alicloud-disk-available, alicloud-disk-efficiency, alicloud-disk-essd, alicloud-disk-ssd, and alicloud-disk-topology.

        • Capacity: Enter an integer greater than 20. The unit is GiB.

   • Description: An optional description for the container service.

II. Configure the pod template

Configure the details of the containers in the pod. After you configure the basic options and the optional advanced settings, click Next.

Basic options

• Container Name: The name of the container. The name can contain lowercase letters, digits, and hyphens (-). It must start with a lowercase letter and end with a lowercase letter or a digit.

• Image Source: You can use an Image Repository, Build Record, or Build from Package.

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

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

    Note

    You can select Use Secret to Pull Image. For more information, see Create a secret.

  • Build from Package: Lets you upload code packages for applications that use a specific technology stack, such as SOFABoot or Java. The system automatically builds the image based on the configuration and uses the target image for subsequent application service deployments.

    • Technology Stack: Select the technology stack for the image. This serves as the base image for the build. You can use a custom or official technology stack. For more information, see Image Technology Stacks.

    • Technology Stack Version: Select the version of the technology stack.

    • Deployment Package: Upload the code package. The package format is not restricted.

    • Location in Target Image: The directory path for the code package in the built image. The path must start with a forward slash (`/`). The system copies the deployment package to the specified directory in the base image.

    • Base Image: Automatically generated based on the selected technology stack and version.

    • Dockerfile Preview: The content of the Dockerfile used to build the image. The content is derived from the base image and only the deployment package is overwritten.

    • Target Image Repository Address (Custom): The name of the image that is built. Enter the tag for the target image. The system pushes the built image to the Image Center at the specified address for future deployments.

      Note

      • A secret is used to pull the image by default. If you have not created a secret, you can click the Create Secret link to create one.

      • The built image is pushed to an image repository by default. Therefore, you must have created a namespace in Container Registry (ACR).

• CPU Configuration: Set the number of CPU cores for the container. Request specifies the minimum number of guaranteed cores. Limit specifies the maximum number of cores that can be used. 1 core = 1000 millicores.

• Memory Configuration: Set the amount of memory for the container. Request specifies the minimum amount of guaranteed memory. Limit specifies the maximum amount of memory that can be used. 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

• Environment Variable Configuration: Set key-value pairs that are passed to the application process when the container starts. For example, USER=tester.

• Volume Configuration: Configure the volumes that are used by the container. Currently, only mounting directories from the host on which the container resides is supported.

• Health Check Configuration: Includes two check mechanisms: Readiness and Liveness. For more information, see Kubernetes Probes.

• Lifecycle Hook Configuration: Add lifecycle hooks for the container. The hooks are executed after the container starts and before it stops.

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

• Business Real-time Monitoring: Add a monitoring directory. You can view the monitoring data of the container on the application service details page.

For more information, see Advanced configuration details.

III. Configure scaling

Replica Scaling Policy Configuration: Currently, only the Fixed Number of Replicas policy is supported. The default value is 1. This means that the application service maintains a fixed number of pod replicas at runtime. After you complete the configuration, click Next.

IV. Configure access (Optional)

Application services support three access methods: cluster-internal access, internal network access, and public network access. Plan your access method based on your business needs.

Cluster-internal access

If you select Cluster-internal access, a ClusterIP service is created to forward traffic to the corresponding container port. You can set the access method when you create the application service or add it after the service is created.

Add an access method during application service creation

1. On the Access Configuration page, click Create Service.

2. In the Create Service window, enter the following information and click Submit.

   • Service Name: The name of the service.

   • Access Method: Select Cluster-internal access.

   • Port Mapping: Click + and enter the following information.

     • Protocol: Supports TCP and UDP.

     • Access Port: The listening port for the workload program in the container image. Valid ports range from 1 to 65535.

     • Container port: To provide access to the workload, the container port is mapped to a port on the cluster's virtual IP. The valid port range is 1 to 65535.

Internal network access

If you select this access method, an internal service is created to forward traffic to the corresponding container port. You can set the access method when you create the application service or add it after the service is created.

Set the access method during application service creation

1. On the Access Configuration page, click Create Service.

2. In the Create Service window, enter the following information and click Submit.

   • Service Name: The name of the service.

   • Access Method: Select Internal Network Access.

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

     • Protocol: Supports TCP, HTTP, and HTTPS.

       Note

       For the TCP protocol, health checks are enabled by default and cannot be disabled.

     • Forwarding Rule: The supported rules are By Weight and By Weight and Minimum Connections.

     • Frontend Port: The port on which the workload in the container image listens. The valid port range is 1 to 65535.

     • Backend Port: The container port that maps to the SLB instance port. This port is used to access the workload through the SLB IP address. The valid port range is 1 to 65535.

     • Health Check: If you enable this feature, you must enter the corresponding configuration items based on the selected protocol.

Public network access

If you configure an external service, a public-facing LoadBalancer is created to forward traffic to the corresponding container port. The access endpoint consists of the public-facing SLB instance address and the configured access port. For example, 10.117.117.117:80.

Set the access method during application service creation

1. On the Access Configuration page, click Create Service.

2. In the Create Service window, enter the following information and click Submit.

   • Service Name: The name of the service.

   • Access Method: Select Public Network Access.

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

     • Protocol: Supports TCP, HTTP, and HTTPS. This topic uses TCP as an example.

       Note

       For the TCP protocol, health checks are enabled by default and cannot be disabled.

     • Forwarding Rule: The supported rules are By Weight and By Weight and Minimum Connections.

     • Frontend Port: The port on which the workload in the container image listens. The valid port range is 1 to 65535.

     • Backend Port: The container port that maps to the SLB instance port. This port is used to access the workload through the SLB IP address. The valid port range is 1 to 65535.

     • Health Check: If you enable this feature, you must enter the corresponding configuration items based on the selected protocol.

V. Configure deployment and scheduling (Optional)

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

This configuration item specifies the information required for the container service deployment, including the following:

• Upgrade Mode:

  • In-place Upgrade: This is the default option. This option keeps the pod and its IP address unchanged. If you select In-place Upgrade, you cannot enable Service Mesh.

    Note

    In Apsara Stack scenarios that have an agile PaaS base and in public cloud scenarios that use ACK clusters, the in-place upgrade capability is degraded. The pod IP address remains unchanged only when the image is upgraded. Other changes, such as changes to environment parameters, trigger a rolling upgrade that replaces old pods with new ones.

  • Rolling Upgrade: Replaces old pods with new ones. This is similar to the native RollingUpdate strategy of a deployment.

    Note

    If you switch the upgrade mode after the service is deployed, the service may become temporarily unavailable.

• Deployment Unit: This setting restricts the pods of the application service to be scheduled only on nodes that have the selected deployment unit tag. By default, all deployment units are selected.

• Deployment Grouping Strategy: Specifies the grouping strategy for pods when the application service is published. The following strategies are available. The default strategy is fast grouping.

  • Fast Grouping: Publishes pods in groups and distributes the pods of each group as evenly as possible across each deployment unit.

  • One Pod per Group: Each group contains one pod. The number of groups is equal to the number of pods.

  • All in One Group: All pods are published in a single group.

• Minimum Number of Groups: This option is available only for fast grouping. The default value is 3. This option takes effect only when the number of replicas is greater than or equal to this value. Each group can have a maximum of 20 replicas.

  Note

  The minimum number of groups is a reference value for publishing. The actual number of groups is affected by the distribution of pods across the deployment units at the time of publishing.

• Add Beta Group: Publishes a subset of pods first to verify their stability before the release continues. This option is selected by default.

  If you select Add Beta Group, a special beta group is set for the application service during publishing. In this group, the system selects one pod from each deployment unit. The beta group is published as the first group.

  • After the beta group is published, the application service publication is automatically paused. The publication waits for the owner or an O&M engineer to confirm the status of the release. If the application service is published correctly, click Confirm Beta Group to continue the grouped publication.

  • The beta group can be used with all grouping strategies to determine the groups. When you create a new publishing request, Add Beta Group is selected by default.

• Pause Between Groups: Pauses the publication after each group is published. The publication continues after you confirm the release. This option is selected by default.

• Pod Scheduling Policy: Currently, only the Distribute Evenly by Deployment Unit policy is supported.

  Note

  This option is effective only when the application service has multiple deployment units. If a deployment unit has insufficient resources to schedule the average number of pods, the pods on that unit are dynamically rescheduled to other units.

• Application Service and Node Affinity Configuration: Add node-level affinity configurations for the application service. You can use node tags to restrict the nodes on which the application service can be scheduled.

  Note

  Affinity settings take effect only when pods are recreated. The affinity configuration always takes effect on the first publication. For subsequent publications, you must select the rolling upgrade mode 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 nodes on which the application service can be scheduled by selecting to run it on the same or different nodes as other application services.

  Note

  Affinity settings take effect only when pods are recreated. The affinity configuration always takes effect on the first publication. For subsequent publications, you must select the rolling upgrade mode for the affinity configuration to take effect.

• Inject SOFAMesh: The service mesh feature must be enabled for the cluster. When traffic shifting is enabled, traffic is forwarded to the new version based on the specified rules during each publication. You can also configure this during the publication process. After you enable this feature, you must specify the traffic shifting ratio. The system forwards traffic to the newly published version based on the specified ratio and the target service.

VI. Preview and submit

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