Container Service for Kubernetes (ACK) builds on Kubernetes concepts. This topic defines the core terms used across ACK documentation and the ACK console.
For a broader Kubernetes reference, see Kubernetes concepts.
Cluster
A cluster is a collection of cloud resources used to run containerized applications. Each cluster includes compute resources (Elastic Compute Service (ECS) instances), networking (virtual private clouds (VPCs)), and load balancing (Server Load Balancer (SLB) instances).
ACK offers several cluster types to match different operational and infrastructure requirements:
| Cluster type | Description | Ideal for |
|---|---|---|
| ACK managed Pro cluster | Built on ACK managed Basic clusters, with higher reliability, stronger security, and a service-level agreement (SLA) that includes compensation clauses. | Enterprise workloads and large-scale production environments requiring guaranteed availability |
| ACK managed Basic cluster | ACK creates and manages the control plane. Create and maintain only the worker nodes. | Teams that want managed Kubernetes at lower resource cost |
| ACK dedicated cluster | Requires creating three control planes and the appropriate worker nodes. Gives you fine-grained control over cluster infrastructure, but you are responsible for planning, managing, and updating nodes. | Teams that need direct control over control plane configuration |
| ACK cluster that supports sandboxed containers | Runs sandboxed containers on ECS Bare Metal instances for high performance under heavy load and high-bandwidth conditions. | Workloads with strict isolation requirements or high I/O demands |
| ACK cluster for confidential computing | Uses Intel Software Guard Extensions (Intel SGX) to protect code and data at runtime. | Data protection, blockchain, key management, intellectual property protection, and genomics computing |
| ACK Edge cluster | Extends Kubernetes to the edge, with node autonomy, cell-based management, and network traffic management. Supports native Kubernetes APIs—no code rewrite required. | Applications that span cloud and edge environments |
| ACK Serverless cluster | No control planes or worker nodes to provision. Configure resources, specify container images, and start applications directly from the ACK console or CLI. | Teams that want to run containers without managing any infrastructure |
| ACK One registered cluster | Connects external Kubernetes clusters to ACK for centralized management. Supports clusters running in on-premises data centers or on third-party clouds. | Multi-cluster or hybrid-cloud environments |
Node
A node is a virtual machine (VM) or physical server with Docker Engine installed. When added to an ACK cluster, ACK automatically installs an agent on the node and registers it with the cluster. Scale the number of nodes up or down based on workload demand.
Node pool
A node pool is a group of nodes that share the same configuration. Node pools enable centralized management of upgrades and scaling operations.
ACK node pools support the following automated operations and maintenance (O&M) features to reduce operational overhead:
Automatic patching for OS Common Vulnerabilities and Exposures (CVE)
Self-recovery for faulty nodes
Automatic version updates for kubelet and containerd
For more information, see Node pools.
VPC
A virtual private cloud (VPC) is a logically isolated network environment on Alibaba Cloud. The CIDR block, route tables, and gateways of a VPC are fully customizable. Cloud resources such as ECS instances, SLB instances, and ApsaraDB RDS (RDS) instances can be deployed within a VPC.
Security group
A security group acts as a virtual firewall, providing Stateful Packet Inspection (SPI) and packet filtering for instances in the same region. All instances within a security group are mutually trusted and governed by the same security rules.
App catalog
App catalog is an ACK feature that simplifies application deployment. It integrates with Helm and provides a GUI for browsing and installing Helm charts.
Orchestration template
An orchestration template stores Kubernetes resource configurations in YAML format, making it easy to version, reuse, and share cluster configurations.
Knative
Knative is a Kubernetes-based serverless framework that provides a cloud-native, cross-platform standard for building and running serverless applications.
Kubernetes
Kubernetes is an open source platform for managing containerized workloads and services. It supports declarative configuration, automated rollouts and rollbacks, self-healing, and horizontal scaling.
Container
A container packages an application together with its runtime dependencies into a portable, isolated unit. A single node can run multiple containers simultaneously.
Container image
A container image is the binary package that encapsulates an application and all its software dependencies. Images can be pulled from Docker Hub, Container Registry, or a private image registry.
Each image is identified by a combination of its registry URI and a tag. The default tag is latest.
Image registry
An image registry stores container images provided by Kubernetes and images that are built from containers.
Control plane
The control plane manages the worker nodes and all cluster components. It exposes the Kubernetes API, schedules workloads, maintains cluster state, and manages the container network.
The control plane includes the following components:
| Component | Role |
|---|---|
kube-apiserver | Exposes the Kubernetes API. All cluster operations go through the API server. |
kube-scheduler | Assigns newly created pods to nodes based on resource availability and scheduling constraints. |
kube-controller-manager | Runs controller loops that reconcile the actual cluster state with the desired state (for example, restarting failed pods). |
etcd | A distributed key-value store that holds all cluster configuration and state data. |
| Container network plug-ins | Implement the cluster's pod networking and network policy. |
Worker node
A worker node is a VM or physical machine that runs your workloads. Each worker node hosts scheduled pods and communicates with the control plane. Worker nodes run the following components:
Docker runtime environment
kubelet— the primary node agent that ensures containers are running as specifiedkube-proxy— maintains network rules for pod-to-pod and pod-to-service communicationOptional components specific to your cluster configuration
Namespace
Namespaces divide a cluster's resources into isolated virtual spaces. Use namespaces to separate environments, teams, or applications within a single cluster. Cluster administrators can create additional namespaces as needed.
The following namespaces exist in every ACK cluster by default:
| Namespace | Purpose |
|---|---|
default | The default namespace for resources created without an explicit namespace. |
kube-system | Reserved for Kubernetes system components. Avoid deploying your own applications here. |
kube-public | Readable by all users, including unauthenticated ones. Reserved for cluster-wide public resources. |
Pod
A pod is the smallest deployable unit in Kubernetes. Each pod encapsulates one or more containers, storage volumes, a unique cluster IP address, and the configuration that governs how the containers run.
ReplicationController
A ReplicationController keeps a specified number of pod replicas running at all times. If a pod fails, the ReplicationController launches a replacement. If there are too many replicas, it terminates the excess. The minimum replica count is one.
ReplicationController is a legacy resource. Use ReplicaSet (managed by a Deployment) for new workloads.
ReplicaSet
A ReplicaSet is the successor to ReplicationController and supports more flexible label selectors. ReplicaSets are not deployed independently—Deployments create and manage them to maintain the desired number of running pods.
Workload
A workload is an application running on Kubernetes. Choose the workload type based on your application's behavior and requirements:
| Workload type | Description | Use when |
|---|---|---|
| Deployment | A Deployment performs a one-time operation on a Kubernetes cluster. Deployments are suitable for running applications that have the same features but are independent of each other. | Running multiple replicas of a stateless application |
| StatefulSet | Ensures ordered deployment, scaling, and rolling updates; supports persistent storage. | Applications that need stable identities or persistent data (databases, queues) |
| DaemonSet | Runs one pod on every node (or a selected subset). | Cluster-wide operations such as log collection, monitoring agents, or node-level network plugins |
| Job | Runs a task to completion, with optional parallelism. | Batch processing and one-off tasks |
| CronJob | Runs a Job on a schedule. | Periodic tasks such as backups or email notifications |
| CustomResourceDefinition (CRD) | Extends the Kubernetes API with custom resource types. | Integrating third-party controllers or defining domain-specific resources |
Label
Labels are key-value pairs attached to Kubernetes resource objects. Labels do not imply semantics to the core system. Use labels to organize and select resources—for example, to target a Deployment for a Service selector or to constrain pod scheduling with nodeAffinity. You can add labels to objects when you create them and modify the labels at any time afterwards. Each resource can carry multiple labels, but each key must be unique per resource.
Service
A Service exposes a set of pods as a stable network endpoint. When a request arrives, kube-proxy selects a matching backend pod and routes traffic to the port defined in the Service configuration.
Ingress
An Ingress defines rules for routing external HTTP and HTTPS traffic to Services within a cluster. With Ingress, configure externally reachable URLs, distribute traffic across Services, terminate SSL connections, and enable name-based virtual hosting.
You can create an Ingress by sending an HTTP POST request to the API server of your cluster. An Ingress controller (typically a load balancer) reads these rules and enforces them. For high-availability configurations, add edge routers or additional frontend proxies.
ConfigMap
A ConfigMap stores non-sensitive configuration data as key-value pairs. Use ConfigMaps to separate configuration from container images, making applications easier to port across environments. ConfigMaps can hold individual values, entire configuration files, or JSON objects.
Secret
A Secret stores sensitive data such as passwords and certificates. Kubernetes keeps Secrets separate from general configuration to reduce the risk of accidental exposure.
Volume
A Kubernetes volume is a storage resource scoped to the lifetime of a pod. Unlike Docker volumes (which are scoped to a single container), a Kubernetes volume is shared across all containers within the same pod.
Persistent volume (PV)
A persistent volume (PV) is a cluster-level storage resource whose lifecycle is independent of any individual pod. Different PV types (for example, cloud disks or NAS) are provisioned through their corresponding StorageClasses.
Persistent volume claim (PVC)
A persistent volume claim (PVC) is a request for storage. Pods use PVCs to consume PVs, in the same way that pods consume node resources.
StorageClass
A StorageClass defines a type of storage and enables dynamic provisioning of persistent volumes (PVs). When a PVC references a StorageClass, Kubernetes automatically creates a matching PV without manual intervention.
Auto scaling
Auto scaling dynamically adjusts compute resources in response to workload demand. ACK provides scaling at two levels:
Pod-level scaling adjusts the number or size of pods within a cluster:
| Component | Description |
|---|---|
| Horizontal Pod Autoscaler (HPA) | Scales the number of pods based on CPU utilization. Works with Deployments and StatefulSets. |
| CronHPA | Scales workloads on a predefined schedule using the kubernetes-cronhpa-controller component. Compatible with HPA—use them together when you need both time-based and metric-based scaling. |
| Vertical Pod Autoscaler (VPA) | Adjusts the CPU and memory request and limit values for pods based on observed usage. Use VPA for applications that cannot scale horizontally, or to right-size pods after anomaly recovery. |
Node-level scaling adjusts the number of nodes in the cluster:
| Component | Description |
|---|---|
| Cluster Autoscaler | Automatically adds or removes nodes when pods cannot be scheduled due to insufficient resources. Supports regular, GPU-accelerated, and preemptible instances across multiple zones and instance types. |
Auto scaling is suitable for online workloads, large-scale computing and training tasks, GPU-accelerated deep learning, model inference and training with shared GPUs, and workloads with periodic load patterns.
Observability
Observability in Kubernetes encompasses monitoring and logging:
Monitoring — tracks system health and performance metrics, helping developers detect and respond to issues in real time.
Logging — captures application and system events to support diagnostics and troubleshooting.
Helm
Helm is the package manager for Kubernetes. A Helm chart bundles all the Kubernetes resource configurations required to deploy an application, making it easy to install, upgrade, and share complex applications.
nodeAffinity
nodeAffinity is a scheduling rule that constrains which nodes a pod can be placed on, based on node labels. Use nodeAffinity to direct workloads to nodes with specific hardware, regions, or custom attributes.
Taint
A taint marks a node so that pods without a matching toleration are not scheduled onto it. Taints work in the opposite direction from nodeAffinity: instead of attracting pods, they repel them.
Toleration
A toleration is applied to a pod to allow it to be scheduled onto a node with a matching taint. Tolerations permit—but do not require—pod placement on tainted nodes.
podAffinity
podAffinity is a scheduling rule that places a pod in the same topological domain (for example, the same node or zone) as other pods that match a given selector. Use podAffinity to co-locate services that communicate frequently and reduce network latency between them.
podAntiAffinity
podAntiAffinity is a scheduling rule that prevents a pod from being placed in the same topological domain as pods that match a given selector. Use podAntiAffinity to spread replicas of an application across multiple nodes or zones, improving availability.
Service mesh (Istio)
Istio is an open source service mesh that connects, secures, controls, and observes microservices.
Service Mesh (ASM) is the fully managed Alibaba Cloud service mesh platform, compatible with the open source Istio service mesh. With ASM, manage inter-service traffic routing and splitting, secure inter-service communication with authentication, and observe service behavior across the mesh—without modifying application code.