Create a stateless application from an image

Step 1: Configure basic application information

1. Log on to the ACK console. In the left navigation pane, click Clusters.

2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Workloads > Deployments.

3. On the Deployments page, click Create from Image.

4. On the Basic Information page, configure the application's basic settings.

   Before you configure the Deployment workload, select a namespace at the top of the page. This example uses the default namespace and the Deployment application type.

   Parameter	Description
   Name	Enter a name for the application.
   Replicas:	The number of pods for the application.
   Type	The type of resource object. You can select Deployment, StatefulSet, Job, or CronJob.
   Labels	Add a label to identify the application.
   Annotation	Add an annotation to the application.

5. Click Next to proceed to the Container page.

Step 2: Configure containers

1. In the General section, complete the basic configuration for the container.

   Parameter	Description
   Image Name	Select Image Click Select Image to choose an image. You can select one of the following image types: Container Registry Enterprise Edition: Select an enterprise edition image hosted in Container Registry (ACR). Specify the region where the image resides and the ACR instance. For more information about ACR, see What is Container Registry? Container Registry Personal Edition: Select a personal edition image hosted in Container Registry (ACR). Specify the region where the image resides and the ACR instance. Artifact center: Includes base OS images, base language images, and AI or big data related images for containerized applications. This example uses the Nginx image from Artifact Center. For more information about Artifact Center, see Artifact Center. Note Container Registry provides Artifact Center to help you use base images. Alibaba Cloud or the OpenAnolis community maintains these base images by releasing version updates and security patches. If you have additional image requirements or questions, join DingTalk group 33605007047. You can also enter a private image. Use the format domainname/namespace/imagename:tag. Select Image Pull Policy ACK supports the following three image pull policies: IfNotPresent: Use the local image if it exists on the host. Pull the image only if it does not exist locally. Always: Pull the image from Container Registry every time you deploy or scale out the workload. Do not use the local image. Never: Use only the local image. Note If you select Image Pull Policy, no policy is set by default. Set Image Pull Secret Click Set Image Pull Secret to configure credentials for private images. For ACR Personal Edition instances, you can pull container images by setting an image pull Secret. For more information about how to set a Secret, see Manage Secrets. For ACR Enterprise Edition instances, you can pull images by using a secret-free component. For more information, see Install and use the managed secret-free component.
   Required Resources	The amount of resources reserved for the application, including CPU and Memory. This gives the container exclusive access to the resources, preventing contention that could make the application unavailable.
   Interactive Session	stdin: Keeps the standard input stream open for the container. tty: Allocates a pseudo-TTY for the container.
   Init Containers	Select this option to create an Init Container. Init Containers contain useful setup scripts or utilities. For more information, see Init Containers.

2. In the Ports section, click Add to configure container ports.

   • Name: Specify a name for the container port.

   • Container Port: Specify the exposed container port or port name. The port number must be between 1 and 65535.

   • Protocol: TCP and UDP are supported.

3. In the Environment Variable section, click Add to set environment variables.

   Note

   To configure environment variables, make sure you have created the required ConfigMaps or Secrets. For more information, see Manage ConfigMaps and Manage Secrets.

   You can configure environment variables for pods as key-value pairs. Use these variables to add environment flags or pass configurations to pods. For more information, see Pod variables.

   • Type: Set the type of environment variable. Supported types are Custom, ConfigMaps, Secrets, Value/ValueFrom, and ResourceFieldRef. You can reference all key-value pairs from a ConfigMap or Secret. For example, for a Secret,

     Select Secrets and Variable. By default, all files are referenced.

     The corresponding YAML references the entire Secret.

     envFrom:
       - secretRef:
           name: test

   • Variable Name: Specify the name of the environment variable.

   • Value/ValueFrom: Specify the value of the variable or the source of the value.

4. In the Health Check section, enable Liveness, Readiness, and Startup probes as needed.

   Parameter	Description
   Liveness probe: A liveness probe checks if a container is running. If the probe fails multiple times, the kubelet restarts the container. This can help resolve issues like deadlocks where the container is running but unable to make progress.	Request type: HTTP request Sends an HTTP request to the container to periodically check its health. Protocol: HTTP or HTTPS. Path: The path to access on the HTTP server. Port: The port or port name exposed by the container. The port number must be an integer from 1 to 65535. HTTP Headers: Custom headers to set in the HTTP request. You can specify multiple headers with the same key. Initial Delay (seconds): The number of seconds to wait after a container starts before the first probe is performed. This corresponds to the initialDelaySeconds parameter. The default is 3 seconds. Probe interval (seconds): The interval for performing a probe, which is specified by the periodSeconds parameter. The default value is 10 seconds, and the minimum value is 1 second. Timeout (seconds): The timeout period for a probe, which is specified by the timeoutSeconds parameter. The default value is 1 second and the minimum value is 1 second. Healthy threshold: The minimum number of consecutive successful probes required to mark the container as healthy after a failure. Default value: 1. Minimum value: 1. For a liveness probe, this must be 1. Unhealthy threshold: The minimum number of consecutive failed probes required to mark the container as unhealthy. Default value: 3. Minimum value: 1. Request type: TCP connection The kubelet attempts to open a TCP socket on the specified port. If the connection is established, the container is considered healthy. If not, it is considered to have failed. Port: The port or port name exposed by the container. The port number must be an integer from 1 to 65535. Initial delay (seconds): The value of the initialDelaySeconds parameter. This is the number of seconds to wait after a container starts before the first probe is performed. The default is 15 seconds. Probe frequency (seconds): The interval for performing the probe, specified by the periodSeconds parameter. The default value is 10 seconds and the minimum value is 1 second. Timeout (seconds): The timeout period for a probe. This corresponds to the timeoutSeconds parameter. The default value is 1 second and the minimum value is 1 second. Healthy threshold: The minimum number of consecutive successful probes required to mark the container as healthy after a failure. Default value: 1. Minimum value: 1. For a liveness probe, this must be 1. Unhealthy threshold: The minimum number of consecutive failed probes required to mark the container as unhealthy. Default value: 3. Minimum value: 1. Request type: Command line Executes a command inside the container to determine its health status. Command: The command used to probe the health of the container. Initial delay (seconds): The value for initialDelaySeconds, which is the number of seconds to wait after a container starts before the first probe is performed. The default is 5 seconds. Probe Interval (seconds): The time interval for performing a probe. This corresponds to the periodSeconds parameter. The default value is 10 seconds and the minimum value is 1 second. Timeout (seconds): The timeoutSeconds parameter, which specifies the timeout period for a probe. The default value is 1 second. The minimum value is 1 second. Healthy threshold: The minimum number of consecutive successful probes required to mark the container as healthy after a failure. Default value: 1. Minimum value: 1. For a liveness probe, this must be 1. Unhealthy threshold: The minimum number of consecutive failed probes required to mark the container as unhealthy. Default value: 3. Minimum value: 1.
   Readiness probe: A readiness probe checks if a container is ready to accept traffic. A Pod is added as a backend to a Service only after its readiness probe succeeds.
   Startup Probes: These probes are executed only when a container starts to check if it has started successfully. The Liveness Probes and Readiness Probes are executed only after the startup probe succeeds. Note Startup probes are supported only in Kubernetes clusters that run version 1.18 or later.

5. In the Lifecycle section, configure the container's lifecycle hooks.

   You can configure startup command, post-start, and pre-stop hooks for the container's lifecycle. For more information, see Configure Lifecycle Hooks.

   • Start: Sets the command and arguments for the container's entrypoint.

   • Post-start Hook: Sets commands to run after the container starts.

   • Pre-stop Hook: Sets commands to run before the container is terminated.

6. In the Volumes section, add storage volumes, such as local storage, a Persistent Volume Claim (PVC), NAS, or cloud disks.

   The following volume types are supported:

   • Local storage

   • PersistentVolumeClaim

   • NAS

   • Cloud disk

   For more information, see Use a statically provisioned cloud disk volume, Use a dynamically provisioned cloud disk volume, and Use a statically provisioned NAS volume.

7. In the Log Service section, configure log-related parameters. For more information, see Create an application from an image.

8. Click Next to proceed to advanced settings.

Step 3: Configure advanced settings

On the Advanced Settings tab, configure access, scaling, and labels and annotations.

1. In the Access Control section, configure access to the backend pods.

   Note

   You can flexibly configure access settings based on your application's communication needs:

   • Internal applications: For applications that only need to operate within the cluster, you can select Cluster IP or Node Port Service types for internal communication.

   • External applications: To expose an application to the public internet, you can use one of two methods:

     • Create a LoadBalancer Service: When creating a Service, select the Server Load Balancer type. This uses an Alibaba Cloud Server Load Balancer (SLB) instance to provide public access.

     • Create an Ingress: Provide public access by creating an Ingress. For more information, see Ingress.

   You can set how backend pods are exposed. This example creates a ClusterIP Service and an Ingress to make the Nginx application publicly accessible.

   • Configure a Service: To the right of Services, click Create to set up the Service configuration.

     Parameter	Description
     Name	Enter a name for the Service. This example uses nginx-svc.
     Type	Select the Service type, which defines the access method. This example selects Server Load Balancer. Cluster IP: Exposes the Service on an internal IP in the cluster. If you select this value, the Service is only reachable from within the cluster. This is the default Service type. Note You can set up a Headless Service only when your Service type is Cluster IP. Server Load Balancer: Uses an Alibaba Cloud Server Load Balancer (SLB) instance to expose the Service externally. You can choose public or private access. An SLB instance can route traffic to NodePort and ClusterIP Services. Create SLB: Click Modify to change the SLB specification. Use Existing SLB: Select an SLB specification from the existing list. Note The LoadBalancer type supports creating a new SLB instance or using an existing one. Multiple Kubernetes Services can reuse the same SLB instance, but with the following limitations: Using an existing SLB instance will forcibly overwrite its existing listeners. An SLB instance created by a Kubernetes Service cannot be reused because this may cause the SLB instance to be accidentally deleted. You can only reuse SLB instances that you created manually in the console or by calling an API. Multiple Services reusing the same SLB instance cannot have the same frontend listener port, as this would cause a port conflict. When you reuse an SLB instance, the listener name and virtual server group name are used as unique identifiers by Kubernetes. Do not modify the names of the listener and virtual server group. Reusing an SLB instance across different clusters is not supported.
     Port Mapping	Add a Service port and a container port. The container port must match the port exposed by the backend pod. In this example, the values are: Service Port: 80 Container Port: 80
     External Traffic Policy	Local: Traffic is sent only to pods on the same node. Cluster: Traffic can be forwarded to pods on other nodes. Note You can set the External Traffic Policy only when your Service type is Node Port or Server Load Balancer.
     Annotation	Add an annotation to the Service to configure SLB parameters. For example, setting service.beta.kubernetes.io/alicloud-loadbalancer-bandwidth:20 sets the peak bandwidth of the Service to 20 Mbit/s to control traffic. For more information, see Use annotations to configure Classic Load Balancer (CLB).
     Label	Add a label to identify the Service.

   • Configure an Ingress: To the right of Ingresses, click Create to set up routing rules for the backend pod.

     For detailed Ingress configuration information, see Ingress configuration description.

     Important

     When you create an application from an image, you can create an Ingress for only one Service. This example uses a virtual host name as a test domain. You need to add a domain mapping entry to your hosts file (Ingress external endpoint IP Ingress domain). In a production environment, use a registered domain name.

     101.37.XX.XX   foo.bar.com    # This is the Ingress IP.

     To get the Ingress IP address: On the application details page, click the Access Method tab. The IP address displayed in the External Endpoint column is the Ingress IP address.

     Parameter	Description
     Name	Enter a name for the Ingress. This example uses nginx-ingress.
     Rule	A routing rule defines how inbound traffic reaches cluster Services. For more information, see Ingress configuration description. Domain Name: Enter the Ingress domain. This example uses the test domain foo.bar.com. Path: Specify the URL path for Service access, which defaults to the root path /. This is not configured in this example. Each path is associated with a backend Service. All inbound requests must match the domain and path before SLB forwards traffic to the backend. Services: Select the name and corresponding port of the Service. In this example, it is nginx-svc. TLS: Configure a secure routing Service. For more information, see Advanced Nginx Ingress usage.
     Service Weight	Set the weights for multiple Services under this path. Service weights are calculated as relative values, with a default of 100.
     Canary Release	Enable the canary release switch. We recommend selecting the community version here.
     IngressClass	Customize the Ingress class.
     Annotation	Click Add and enter the annotation name and value as a key-value pair for the Ingress. For more information about Ingress annotations, see Annotations.
     Label	Add a label to identify the Ingress.

   In the Access Control section, you can see the created Service and Ingress. You can click Update and Delete to reconfigure them.

2. In the Scaling section, enable HPA and CronHPA to automatically adjust the number of pods based on application load.

   Container Service for Kubernetes (ACK) supports elastic scaling of pods, which automatically adjusts the number of pods based on CPU and memory usage.

   Note

   To enable autoscaling, you must set resource requests for the container. Otherwise, autoscaling will not work.

   Parameter	Description
   Metric	Supports CPU and memory. The metric must match the resource type for which you set requests.
   Trigger Condition	The percentage of resource utilization. When usage exceeds this threshold, the application scales out.
   Max. Replicas	The maximum number of pods to which the application can scale out.
   Min. Replicas	The minimum number of pods to which the application can scale in.

3. In the Labels and Annotations section, click Add to set the pod's labels and annotations.

   • Pod Labels: Add a label to the pod to identify the application.

   • Pod Annotations: Add an annotation to the pod.

4. Click Create.

Step 4: View the application

On the Complete page, view the application creation status.

1. On the Complete page, click View Details. You can see the new serverless-app-deployment in the Deployments list.

   The Deployments list shows serverless-app-deployment with the label app:serverless-app-deployment, 0/2 pods (in a not-ready state), and the image address registry-vpc.cn-hangzhou.aliyuncs.com/devops2-xxx:latest.

2. In the left-side navigation pane, choose Network > Services. You can see the new Service serverless-app-svc in the Services list.

   The Service type is LoadBalancer, and the external endpoint displays a public IP address and port 80. You can access the application from the internet through this external endpoint.

3. In a browser, enter the external endpoint or domain name to access the Nginx welcome page.

   Important

   • To access the application in a browser, ensure the Service access method is Server Load Balancer.

   • To access the application by domain name, you must configure your local hosts file. For more information, see the note in the preceding step.

   After the browser successfully accesses the application, the default Nginx welcome page is displayed with the title Welcome to nginx! This indicates that the Nginx web server is running correctly.