Container Service for Kubernetes:Service management

Package the application code into a container image and push the image to a repository of Container Registry. Then, pull the image from the repository of Container Registry and deploy the image in an ACK cluster or ACK Serverless cluster.

1. Save the code to a Dockerfile and build a container image from the Dockerfile. For more information, see Build an image for a Java application by using a Dockerfile with multi-stage builds.

2. If the image is built on an on-premises machine, you can push the image to a repository of Container Registry. For more information, see Create an application by using a private image repository.

3. Pull the image from the repository of Container Registry and deploy the image in an ACK cluster. For more information, see Create a stateless application by using a Deployment.

The following table describes different Service types that you can use in different scenarios.

You can create Services in the ACK console or by using the CLI.

• Method 1: Create a Service on the Advanced wizard page when you deploy an application. For more information, see Configure advanced settings.

• Method 2: If an existing application is not associated with a Service, you can create a Service in the ACK console. For more information, see Use Services to expose applications.

• Method 3: Create a Service for a Deployment by using the CLI.

  Run the following command to create a Service for the NGINX Deployment:

  kubectl expose deployment/nginx --type="LoadBalancer" --port 80

You must configure resource requests and resource limits for each container when you create a pod, including requests and limits for CPU and memory resources.

• requests: specifies the minimum amount of resources that must be reserved for a pod to run as normal. If the node that hosts the pod has sufficient resources, the pod may consume an amount of resources that exceed the value of the request parameter.

• limits: specifies the maximum amount of resources that can be allocated to a pod. This prevents a pod from consuming unlimited resources, which may cause other pods to crash. If a process in a pod attempts to consume memory resources that exceed the value of the limits parameter, the kernel of the operating system terminates the process and returns an Out of Memory (OOM) error. After you configure resource limits, ACK can use a proactive method or a passive method to control resource usage. If the passive method is used, ACK limits resource usage when ACK detects excess resource allocation. If the proactive method is used, ACK forces a container to use resources that do not exceed the resource limit of the container. ACK uses different methods to limit resource usage for containers based on the runtimes of the containers. If you use a Java application, we recommend that you set JAVA_OPTS -Xmx to a value that is 70% to 80% of the value specified by the limits parameter.

By default, pods are scheduled to different nodes in an ACK cluster to ensure load balancing. If you want to schedule a pod to a specified node, you can specify node affinities, taints, or tolerations for the pod.

• Node affinity: You can use node affinities to schedule pods only to a specific node or prioritize a specific node when ACK schedules pods. You can configure node affinities by specifying the nodeSelector parameter in the YAML file of a pod. For more information, see node-affinity.

• Tolerations: You can configure toleration rules to schedule pods to nodes with matching taints. Taints and tolerations can be used to prevent the system from scheduling pods to inappropriate nodes. You can add one or more taints to a node. Pods that do not tolerate the taints are not scheduled to the node with the same taints. For more information, see taint-and-toleration.

If multiple Services are used in microservices scenarios, you can assign different ports to different Services and configure the Services to use the same EIP. This reduces the cost of EIPs and SLB instances.

ACK supports auto scaling. The auto scaling feature can scale elastic computing resources to meet business requirements.

• Resource layer

  Use ECS instances and elastic container instances together. You can deploy regular workloads on ECS instances and use elastic container instances to handle heavy traffic during peak hours. For more information about how to use elastic container instances, see Use Elastic Container Instance in ACK clusters. For more information about how to use ECS, see What is ECS?

  • ACK uses virtual nodes to allow seamless integration between Kubernetes and elastic container instances. Virtual nodes provide Kubernetes clusters with high elasticity. This way, Kubernetes clusters are no longer limited by the computing capacity of the cluster nodes. For more information, see Deploy the virtual node controller and use it to create Elastic Container Instance-based pods.

  • If only ECS instances are used as computing resources, ACK uses the auto scaling component to scale nodes. Regular instances, GPU-accelerated instances, and preemptible instances can be automatically added to or removed from an ACK cluster as required. This component is suitable for multiple types of instances, instances that are deployed across multiple zones, and various scenarios. For more information, see Auto scaling of nodes.

• Container layer

  ACK provides general scaling models, such as Horizontal Pod Autoscaler (HPA), Cron Horizontal Pod Autoscaler (CronHPA), Vertical Pod Autoscaler (VPA), and horizontal auto scaling components. ACK also provides scaling models that use specific technologies, such as event-driven scaling, Knative serverless scaling framework, fine-grained scaling of elastic workloads, and Spark and Presto CustomResourceDefinitions (CRDs). For more information, see Auto scaling overview.

You can configure ACK to perform auto scaling at the resource layer and ignore the container layer. If the resource utilization is low or the resources are sufficient, you can configure ACK to perform auto scaling at the container layer and ignore the resource layer.

You can access an ACK cluster by using one of the following methods:

• Method 1: Connect to an ACK cluster in the ACK console

• Method 2: Connect to an ACK cluster by using kubectl

  To connect to an ACK cluster from your on-premises machine, we recommend that you use the kubectl command-line tool. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

• Method 3: Use kubectl on Cloud Shell to manage ACK clusters

  If you use this method, you do not need to install kubectl. For more information, see Use kubectl on Cloud Shell to manage ACK clusters.

• Method 4: Use SSH to access an ACK cluster

  If you do not enable SSH logon when you create an ACK cluster, you cannot directly connect to the cluster by using SSH or kubectl. To use SSH to connect to an ACK cluster that has SSH logon disabled, you must manually associate EIPs with the ECS instances in the cluster, configure security group rules, and then open SSH port 22. For more information, Use SSH to connect to the master nodes of an ACK dedicated cluster.

• Use other methods to access an ACK cluster

  You can also use other methods to access an ACK cluster. For example, you can access a cluster through an API server or by using an SSH key pair.

An API server exchanges data for an ACK cluster. The public IP address of an ACK cluster is the public IP address of the API server in the cluster. ACK allows you to use an EIP to expose the API server of a cluster. After you use an EIP to expose the API server of a cluster, the API server can be accessed over the Internet. To query the public IP address of an ACK cluster, perform the following steps:

1. Log on to the ACK console.

2. In the left-side navigation pane of the ACK console, click Clusters.

3. On the Clusters page, find the cluster that you want to manage. Then, click the name of the cluster or click Details in the Actions column.

4. On the cluster details page, click the Basic Information tab. In the Cluster Information section, you can view the public IP address of the cluster in the API Server Public Endpoint field.

The authorization mechanism of ACK consists of Resource Access Management (RAM) authorization and role-based access control (RBAC) authorization.

• O&M engineers manage cloud resources as RAM users. If you want to scale a cluster, add nodes to a cluster, or access a cluster as a RAM user, you must grant the required permissions to the RAM user. For more information, see RAM authorization.

• If a RAM user requires the permissions to manage resources in a specified cluster and namespace, you must go to the Authorizations page of the ACK console and grant the required permissions to the RAM user. For more information, see RBAC authorization.

After the RAM user logs on to the ACK cluster, the RAM user can obtain the authorized kubeconfig file. For more information, see Step 2: Select a type of cluster credentials.