Basic Concepts

Cluster

A Kubernetes cluster is a managed collection of cloud resources, including compute instances (nodes) and load balancers, used to run containerized applications. Nodes within a cluster are deployed in the same subnet to provide a shared compute resource pool.

A Kubernetes cluster consists of a control plane and worker nodes.

CCE supports the cluster types shown in the table below.

For more details, see Comparison Between Cluster Types.

For details, see Buying a CCE Standard/Turbo Cluster.

Node

In a Kubernetes cluster, nodes are worker machines that run containerized applications. They can be physical servers (PMs) or virtual machines (VMs) connected over a network. Each node runs the following components:

• Container runtime: executes containers (such as containerd or Docker).
• kubelet: reports node and pod status to the API server, and executes pod specifications received from the control plane.
• kube-proxy: maintains network rules on the node and routes Service traffic.

Pods (Pod), the smallest deployable units, are scheduled and run on nodes by the Kubernetes control plane. Nodes provide the foundational runtime environment for clusters, ensuring application availability and scalability.

For details, see Creating a Node.

Node Pool

In a Kubernetes cluster, a node pool is a group of nodes that have the same configuration and attributes. These nodes usually have the same hardware specifications, OS version, and configurations. A node pool makes it easier to manage and scale cluster resources in batches. You can create node pools of different sizes and configurations to meet different workload scheduling requirements and ensure efficient resource utilization. In addition, node pools support auto scaling. The number of nodes in a node pool can be scaled automatically based on workloads. This improves the resource utilization, flexibility, and scalability of a cluster.

For details, see Creating a Node Pool.

Container Runtime

A container runtime is the component responsible for creating and running containers on a node. Kubernetes communicates with runtimes through the Container Runtime Interface (CRI). The following runtimes are supported:

• containerd (recommended): a lightweight, high-performance runtime. It is the default and recommended runtime of the Kubernetes community.
• Docker: supported via dockershim. Since Kubernetes 1.24, dockershim has been removed from kubelet. Docker support requires cri-dockerd.

CCE uses containerd as the default runtime. Nodes in clusters v1.34 or later do not support Docker.

For more information, see Container Runtimes.

VPC

A VPC provides a secure, logically isolated virtual network environment. VPCs provide the same resources as physical networks, and they also provide various advanced network services, such as elastic IP addresses and security groups.

With VPCs, both node networks and pod networks in CCE clusters can be isolated. You can also configure EIPs and bandwidths for your clusters for more flexible scalability.

For details, see Creating a VPC with a Subnet.

Security Group

A security group is a collection of access rules for ECSs that have the same security requirements and are mutually trusted in a VPC. After a security group is created, you can create different access rules to control who can access the ECSs that are added to this security group.

For details, see Adding a Security Group Rule.

Relationships Between Clusters, VPCs, Security Groups, and Nodes

Figure 1 Relationship between clusters, VPCs, security groups, and nodes

Service

In Kubernetes, a Service defines a stable network endpoint for accessing a set of pods. Because pod IP addresses are ephemeral and change upon restart, Services use label selectors to dynamically associate with backend pods, providing a consistent access method regardless of pod churn.

There are different types of Services with their respective values and behaviors:

• ClusterIP: This is the default Service type. Each ClusterIP Service is assigned a unique IP address within the cluster. This IP address is only accessible within the cluster. It cannot be directly accessed from external networks. ClusterIP Services are typically used for internal communications within a cluster.
• NodePort: A NodePort Service opens a static port (NodePort) on all nodes in a cluster. You can access the Service through this port. External systems can contact NodePort Services using the EIPs associated with the nodes over the specified ports.
• LoadBalancer: This type of Service allows you to use the load balancers provided by cloud service providers to expose Services to the Internet. Load balancers can distribute traffic to the NodePort and ClusterIP Services within the cluster.
• DNAT: This type of Service translates IP addresses for cluster nodes and enables multiple nodes to share an EIP. Compared to directly binding an EIP to a node, DNAT enhances reliability. You do not need to bind an EIP to a single node and requests can still be distributed to the workload even if any of the nodes inside is down.

For details, see Service Overview.

Ingress

An ingress controls how Services within a cluster can be accessed from outside the cluster. Ingresses can route traffic based on domain names and paths. They support load balancing, TLS termination, and SSL certificate management. An ingress manages traffic of multiple Services in a unified manner. It acts as an entry point for incoming traffic. This simplifies network configuration, improves cluster scalability and security, and is an important way to expose Services in microservices.

For details, see Ingress Overview.

Network Policy

Network policies allow you to specify rules for traffic flow between pods. They control whether traffic is allowed or denied to and from a pod based on specified rules to enhance network security for clusters.

Network policies define traffic rules across the following dimensions:

• Pod label: matches the label selector of the source or destination pod.
• Namespace: matches the source or destination namespace.
• IP block: matches a CIDR address range.
• Port: matches the protocol and port number.

For details, see Configuring Network Policies to Restrict Pod Access.

Pod

A pod is the smallest, basic unit for deploying applications or services. It can contain one or more containers, which typically share storage and network resources. Each pod has its own IP address, allowing the containers within the pod to communicate with each other and be accessed by other pods in the same cluster. Kubernetes also offers various policies to manage container execution. These policies include restart policies, resource requests and limits, and lifecycle hooks.

Figure 2 Pod

Pod Lifecycle

A pod progresses through the following phases from creation to deletion. Transitions between phases are controlled by the Kubernetes control plane.

The pod lifecycle is governed by the following key mechanisms:

• Restart policy: Always (default, the container is restarted regardless of exit status), OnFailure (the container restarts only if it exits with a non-zero status), and Never (the container is not restarted)
• Health checks (Probes): livenessProbe (detects whether the container is running. If the probe fails, the container is restarted), readinessProbe (detects whether the container is ready to accept traffic. If the probe fails, the pod is removed from its Service endpoints), and startupProbe (detects whether the application has started. Other probes are disabled until the application is fully initialized)
• Lifecycle hooks: postStart (executed immediately after the container is created) and preStop (executed before the container is terminated)

Container

A container is an instance created using a Docker image. Multiple containers can run on the same node (the host). Containers are essentially processes, but they run in their own separate namespaces, unlike actual processes, which run directly on a host machine. Namespaces provide isolation between containers, allowing each container to have its own file system, network API, process ID, and more. This enables OS-level isolation for containers.

Figure 3 Relationships between pods, containers, and nodes

Workload Types

A workload is an application running in a Kubernetes cluster. No matter how many components are there in your workload, you can run it in a group of pods. A workload is an abstract model of a group of pods. In Kubernetes, there are Deployments, StatefulSets, DaemonSets, jobs, and CronJobs.

A ReplicaSet is the underlying mechanism that Deployments use to manage pod replicas. A Deployment controls ReplicaSets to implement rolling updates and rollbacks. Each time a Deployment is updated, it creates a new ReplicaSet that gradually replaces pods from the previous ReplicaSet. You generally do not need to interact with ReplicaSets directly.

For details, see Creating a Workload.

Figure 4 Relationship between workloads and pods

Image

An image is a standard format used to package containerized applications and create containers. Essentially, an image is a specialized file system that includes all the necessary programs, libraries, resources, and configuration files for container runtimes. It also contains configuration parameters like anonymous volumes, environment variables, and users that are required for runtimes. An image does not contain any dynamic data. Once it has been created, the content does not change. When deploying containerized applications, you have the option to use images from Docker Hub, SoftWare Repository for Container (SWR), or your own private image registries. For instance, you can create an image that includes a specific application and all its dependencies, ensuring consistent execution across different environments.

The relationship between an image and a container is akin to that between a class and an instance in object-oriented programming. An image serves as a static blueprint, while a container is its active, running entity. Containers can be created, started, stopped, deleted, and suspended.

For details, see Pushing an Image.

Figure 5 Relationship between images, containers, and workloads

PV

A PersistentVolume (PV) is a storage resource in a cluster. It can be either a local disk or network storage. It exists independently from pods, so if a pod using a PV is deleted, the data stored in the PV will not be lost.

PVC

A PersistentVolumeClaim (PVC) is a request for storage resources. It specifies the desired storage size and access mode. Kubernetes automatically binds it to a suitable available PV.

The relationship between PVCs and PVs is analogous to that between pods and nodes: pods consume compute resources, while PVCs consume storage resources.

Namespace

A namespace in Kubernetes is a way to group and organize related resources and objects, such as pods, Services, and Deployments. It logically isolates data from other namespaces, but shares basic resources like CPUs, memory, and storage within the same cluster with them. By deploying different environments in separate namespaces, such as development, testing, and production, you can ensure environmental isolation and simplify management and maintenance tasks.

In Kubernetes, most resource objects, including pods, Services, ReplicationControllers, and Deployments, are associated with the default namespace by default. However, there are also cluster-level resources like nodes and PersistentVolumes (PVs) that are not tied to any specific namespace and provide services to resources across all namespaces.

For details, see Creating a Namespace.

ConfigMap

ConfigMaps are used to store configuration data in key-value pairs. ConfigMaps can decouple configuration details such as configuration files and command-line arguments from pods. With ConfigMaps, you can avoid the need to rebuild container images whenever configurations are shared or updated between pods. ConfigMaps support multiple data formats, such as YAML and JSON. This facilitates application configuration management and ensures maintainability and scalability.

For details, see Creating a ConfigMap.

Secret

Secrets store sensitive data, such as passwords, keys, and certificates. They are encrypted at rest to enhance data security. Secrets can be mounted as volumes or exposed as environment variables in a pod. They can also store cluster authentication credentials. By managing sensitive data separately from application code, secrets reduce exposure risks. They also support centralized management and dynamic updates, ensuring cluster security and operational flexibility.

For details, see Creating a Secret.

Comparison Between ConfigMaps and Secrets

Environment Variable

An environment variable is a variable that is configured in the runtime environment of a container. A maximum of 30 environment variables can be defined in a container template. You can modify environment variables even after workloads are deployed. Workload configuration is quite flexible.

CCE supports the following sources for environment variables:

• Manual input: Directly specify key-value pairs.
• ConfigMap: Reference data from a ConfigMap.
• Secret: Reference sensitive data from a secret.
• System variable: Reference pod metadata such as name, namespace, and IP address.

The function of setting environment variables on CCE is the same as that of specifying ENV in a Dockerfile.

Affinity and Anti-Affinity

Before an application is containerized, many of its components run on the same VM, and processes need to communicate with each other. During containerization, its processes are packed into different pods and each pod has its own lifecycle. For example, the business process is packed into a pod while the monitoring/logging process or local storage process is packed into another pod. If these pods run on distant nodes, routing between them will be costly and slow.

• Affinity: Closely related pods are scheduled on the same or topologically nearest node, minimizing network latency. For example, if two applications communicate frequently, pod affinity can schedule them within the same AZ or on the same node, minimizing network latency.
• Anti-affinity: Pods of the same application spread across different nodes to achieve higher availability. Once a node is down, the application pods on other nodes are not affected. For example, if an application runs in multiple pods, you can define anti-affinity rules to deploy these pods on different nodes to guarantee the application HA.

For details, see Overview of Scheduling a Workload.

Taint and Toleration

Taints and tolerations are node-level scheduling constraints that complement affinity. Affinity defines where pods prefer to run, and taints define which pods are prohibited from running on a node.

HPA

Horizontal Pod Autoscaler (HPA) automatically scales the number of pods in a workload based on observed metrics such as CPU utilization, memory usage, or custom metrics. You configure target thresholds for each metric. HPA dynamically adjusts pod count to maintain optimal application performance.

For details, see Creating an HPA Policy.

Cluster Autoscaler

Cluster Autoscaler automatically adjusts the number of nodes in a cluster to match workload demand. It provisions nodes when pending pods cannot be scheduled due to resource constraints, and removes underutilized nodes when demand decreases. This ensures that cluster capacity matches workload demands, improving resource utilization and cost efficiency.

For details, see Creating a Node Scaling Policy.

Label

Labels are key-value pairs that are attached to objects such as pods, Services, and Deployments. Labels are used to add extra, semantic metadata to objects, enabling users and systems to effortlessly identify, organize, and manage resources.

Label Selector

Label selectors simplify resource management by allowing you to group and select resource objects based on their labels. This enables batch operations, such as traffic distribution, scaling, configuration updates, and monitoring, on the selected resource groups.

Use cases:

• Service: Select backend pods.
• Deployment: Select pods to manage.
• HPA: Select the scaling target.
• NetworkPolicy: Select the pods to which the policy applies.

Annotation

Annotations are key-value pairs, similar to labels, but serve different purposes and have different constraints.

• Label: identifies resources. Labels are part of the metadata of Kubernetes objects. They can be used with label selectors to filter resources and support core mechanisms such as scheduling and service discovery.
• Annotation: attaches arbitrary non-identifying metadata to Kubernetes objects. Unlike labels, annotations are not part of the resource selection mechanism. Kubernetes does not use annotations to control resource behavior directly. However, external tools can read annotations to extend Kubernetes capabilities.

Resource Quota

Resource quotas enable administrators to set limits on the overall usage of resources, such as CPU, memory, disk space, and network bandwidth, within namespaces.

Resource Limit (LimitRange)

By default, all containers in Kubernetes have no CPU or memory limit. A LimitRange is a policy used to apply resource limits to objects, like pods, within a namespace.

It offers several constraints that can:

• Restrict the minimum and maximum resource usage for each pod or container in a namespace.
• Set minimum and maximum limits for the storage space that each PVC can request within a namespace.
• Control the ratio between the request and limit for a resource within a namespace.
• Set default requests and limits for compute resources within a namespace and automatically apply them to multiple containers at runtime.

API Server

The API server (kube-apiserver) is a core component of the Kubernetes control plane and serves as the unified entry point for the entire system. It processes all API requests from users, internal cluster components, and external tools. All operations on cluster resources, such as pods, Services, and Deployments, must pass through the API server.

Key features and functions of the API server:

• Kubernetes API: The API server provides a RESTful API for managing and operating Kubernetes resources, such as pods, Services, and Deployments.
• Secure access control
  • Authentication: verifies the identity of the requester (for example, via tokens, client certificates, or username/password).
  • Authorization: determines whether an authenticated user has permission to perform the requested operation (for example, via RBAC or ABAC policies).
  • Admission control: Before resources are created, updated, or deleted, admission controllers verify or modify the requests.
• API versioning: APIs are versioned (for example, v1 or apps/v1) to enable feature iteration while maintaining backward compatibility.
• Interactions with other components
  • etcd: The API server persists cluster state by reading from and writing to etcd.
  • kube-controller-manager: watches for resource changes via the API server and executes control logic. It runs multiple controllers, including the node controller and the replication controller.
  • kube-scheduler: retrieves unscheduled pods via the API server and writes binding decisions back to it.
  • kubelet: reports node and pod statuses to the API, and receives and executes pod configuration.
  • kubectl: Users use kubectl to call the API to operate clusters.

For more information about the API server configuration, see kube-apiserver.

kube-controller-manager

The kube-controller-manager is the control center of Kubernetes. It runs multiple controllers, each operating as an independent control loop. Each controller watches for resource changes via the API server and executes the corresponding control logic. Key controllers include:

• Node controller: detects and responds to node failures.
• ReplicaSet controller: maintains the desired number of pod replicas.
• Service account controller: creates a default service account for each new namespace.
• Endpoints controller: populates the Endpoints object for each Service.

For more information, see kube-controller-manager.

kube-scheduler

The kube-scheduler assigns unscheduled pods to suitable nodes. The scheduling process consists of two phases:

1. Filtering: excludes nodes that do not meet the pod's resource requirements or scheduling constraints.
2. Scoring: ranks the remaining nodes by priority and selects the optimal one.

Scheduling decisions consider resource availability, affinity and anti-affinity rules, taints and tolerations, and data locality.

For more information about kube-scheduler, see kube-scheduler.

etcd

etcd is a distributed key-value store that Kubernetes uses to persistently store all cluster state data, including:

• Cluster configuration
• Node status and health information
• Definitions and statuses of resource objects such as pods and Services
• Configuration data such as ConfigMaps and secrets

etcd is the data foundation of a cluster, and its availability directly determines cluster availability. In CCE standard and Turbo clusters, etcd is hosted and maintained by the cloud platform. You do not need to manage it.

kubelet

kubelet is a per-node agent that:

• Reports node and pod statuses to the API server.
• Receives pod configurations and ensures containers run to spec.
• Performs health checks and restarts failed containers.
• Mounts volumes into pods.

For more information, see kubelet.

kube-proxy

kube-proxy runs on every node. It watches the API server for Service and Endpoints changes, and programs iptables or IPVS rules to route Service traffic to healthy backend pods.

For more information, see kube-proxy.