Before you use Container Service for Kubernetes (ACK), understand the product concepts involved. This topic introduces common terms and brief descriptions to help you understand ACK, building on Kubernetes concepts.
See Kubernetes concepts for a broader Kubernetes reference.
Cluster
A cluster is a set of cloud resources that run containerized applications, including ECS instances, VPC networking, and SLB load balancing.
ACK offers cluster types for different operational and infrastructure needs:
| Cluster type | Description | Ideal for |
|---|---|---|
| ACK managed Pro cluster | Extends ACK managed Basic clusters with higher reliability, stronger security, and an SLA with compensation clauses. | Enterprise workloads and large-scale production that need 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 three control planes and worker nodes. Provides fine-grained infrastructure control, but you plan, manage, and update nodes. | Teams that need direct control plane control |
| ACK cluster that supports sandboxed containers | Runs sandboxed containers on ECS Bare Metal instances for high performance under heavy load and high bandwidth. | 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 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, including on-premises and third-party cloud clusters. | Multi-cluster or hybrid-cloud environments |
Node
A node is a VM or physical server with Docker Engine installed. When added to an ACK cluster, ACK installs an agent and registers the node. Scale nodes up or down based on workload demand.
Node pool
A node pool groups nodes with the same configuration for centralized upgrades and scaling.
ACK node pools support automated O&M features that reduce operational overhead:
-
Automatic patching for OS Common Vulnerabilities and Exposures (CVE)
-
Self-recovery for faulty nodes
-
Automatic version updates for kubelet and containerd
See Node pools.
VPC
A VPC is a logically isolated network on Alibaba Cloud. Customize the CIDR block, route tables, and gateways. Deploy ECS instances, SLB instances, and RDS instances within a VPC.
Security group
A security group is a virtual firewall with Stateful Packet Inspection (SPI) and packet filtering for instances in the same region. Instances in a security group share the same security rules.
App catalog
App catalog is an ACK feature that simplifies deployment with Helm integration and a GUI for browsing and installing Helm charts.
Orchestration template
An orchestration template stores Kubernetes resource configurations in YAML for versioning, reuse, and sharing.
Knative
Knative is a Kubernetes-based serverless framework for building and running cloud-native applications across platforms.
Kubernetes
Kubernetes is an open source platform for containerized workloads and services, with declarative configuration, automated rollouts and rollbacks, self-healing, and horizontal scaling.
Container
A container packages an application and its runtime dependencies into a portable, isolated unit. One node can run multiple containers.
Container image
A container image packages an application and its dependencies. Pull images from Docker Hub, Container Registry, or a private 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 Kubernetes-provided images and images built from containers.
Control plane
The control plane manages worker nodes and cluster components, exposing the Kubernetes API, scheduling workloads, maintaining cluster state, and managing the container network.
The control plane includes the following components:
| Component | Role |
|---|---|
kube-apiserver |
Exposes the Kubernetes API. All cluster operations go through it. |
kube-scheduler |
Assigns new pods to nodes based on resource availability and scheduling constraints. |
kube-controller-manager |
Runs controller loops that reconcile actual cluster state with desired state (for example, restarting failed pods). |
etcd |
Distributed key-value store that holds all cluster configuration and state data. |
| Container network plug-ins | Implements pod networking and network policy for the cluster. |
Worker node
A worker node is a VM or physical machine that runs workloads, hosts scheduled pods, and communicates with the control plane. Worker nodes run these components:
-
Docker runtime environment
-
kubelet— the primary node agent that ensures containers are running as specified -
kube-proxy— maintains network rules for pod-to-pod and pod-to-service communication -
Optional components specific to your cluster configuration
Namespace
Namespaces divide cluster resources into isolated virtual spaces. Separate environments, teams, or applications within one cluster. Cluster administrators can create additional namespaces.
Every ACK cluster includes these default namespaces:
| Namespace | Purpose |
|---|---|
default |
Default namespace for resources created without an explicit namespace. |
kube-system |
Reserved for Kubernetes system components. Do not deploy your applications here. |
kube-public |
Readable by all users, including unauthenticated ones. Reserved for cluster-wide public resources. |
Pod
A pod is Kubernetes's smallest deployable unit, encapsulating one or more containers, storage volumes, a unique cluster IP, and runtime configuration.
ReplicationController
A ReplicationController maintains a specified number of pod replicas. It replaces failed pods and terminates excess replicas. The minimum count is one.
ReplicationController is a legacy resource. Use ReplicaSet (managed by a Deployment) for new workloads.
ReplicaSet
A ReplicaSet succeeds ReplicationController with more flexible label selectors. Deployments create and manage ReplicaSets to maintain the desired pod count.
Workload
A workload is an application running on Kubernetes. Choose the workload type based on application behavior and requirements:
| Workload type | Description | Use when |
|---|---|---|
| Deployment | Deployments manage replicated applications on a Kubernetes cluster. Use them for independent applications with the same features. | 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 on Kubernetes resources. They carry no system semantics. Use labels to organize and select resources—for example, for Service selectors or nodeAffinity scheduling. Add labels at creation or modify them later. Each resource can have multiple labels, but each key must be unique.
Service
A Service exposes pods as a stable network endpoint. kube-proxy selects a backend pod and routes traffic to the Service port.
Ingress
An Ingress routes external HTTP and HTTPS traffic to in-cluster Services. Configure reachable URLs, distribute traffic, terminate SSL, and enable name-based virtual hosting.
Create an Ingress with an HTTP POST to the cluster API server. An Ingress controller (typically a load balancer) enforces the rules. For high availability, add edge routers or frontend proxies.
ConfigMap
A ConfigMap stores non-sensitive configuration as key-value pairs. Separate configuration from container images to port applications across environments. ConfigMaps hold individual values, configuration files, or JSON objects.
Secret
A Secret stores sensitive data such as passwords and certificates, separate from general configuration to reduce accidental exposure.
Volume
A Kubernetes volume is storage scoped to a pod's lifetime. Unlike Docker volumes (scoped to one container), a Kubernetes volume is shared across all containers in the same pod.
Persistent volume (PV)
A persistent volume (PV) is cluster-level storage independent of any pod. Provision PV types such as cloud disks or NAS through StorageClasses.
Persistent volume claim (PVC)
A persistent volume claim (PVC) requests storage. Pods consume PVCs like they consume node resources.
StorageClass
A StorageClass defines a storage type and enables dynamic PV provisioning. When a PVC references a StorageClass, Kubernetes automatically creates a matching PV.
Auto scaling
Auto scaling adjusts compute resources based on workload demand. ACK scales at two levels:
Pod-level scaling adjusts pod count or size within a cluster:
| Component | Description |
|---|---|
| Horizontal Pod Autoscaler (HPA) | Scales pod count based on CPU utilization for Deployments and StatefulSets. |
| CronHPA | Scales workloads on a predefined schedule using the kubernetes-cronhpa-controller add-on 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 cluster node count:
| Component | Description |
|---|---|
| Cluster Autoscaler | 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. |
Use auto scaling for online workloads, large-scale computing and training, GPU-accelerated deep learning, model inference and training with shared GPUs, and periodic load patterns.
Observability
Kubernetes observability covers monitoring and logging:
-
Monitoring — tracks health and performance metrics for real-time issue detection.
-
Logging — captures application and system events for diagnostics and troubleshooting.
Helm
Helm is the Kubernetes package manager. A Helm chart bundles resource configurations to deploy, upgrade, and share applications.
nodeAffinity
nodeAffinity constrains which nodes a pod can run 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 to repel pods without a matching toleration. Taints work opposite nodeAffinity—they repel pods instead of attracting them.
Toleration
A toleration lets a pod schedule onto a node with a matching taint. Tolerations permit but do not require placement on tainted nodes.
podAffinity
podAffinity places a pod in the same topological domain (such as the same node or zone) as pods matching a selector. Use podAffinity to co-locate services that communicate frequently and reduce network latency.
podAntiAffinity
podAntiAffinity prevents a pod from sharing a topological domain with pods matching a selector. Use podAntiAffinity to spread replicas across nodes or zones for higher availability.
Service mesh (Istio)
Istio is an open source service mesh that connects, secures, controls, and observes microservices.
Service Mesh (ASM) is Alibaba Cloud's fully managed service mesh, compatible with open source Istio. Route and split inter-service traffic, secure communication with authentication, and observe service behavior without modifying application code.