Basic Concepts
CCE is a scalable, enterprise-class hosted Kubernetes service. With CCE, you can easily deploy, manage, and scale containerized applications in the cloud.
The graphical CCE console enables E2E user experiences. In addition, CCE supports native Kubernetes APIs and kubectl. Before using CCE, understand related basic concepts.
Cluster
A cluster is a group of one or more cloud servers (also known as nodes) in the same subnet. It has all the cloud resources (including VPCs and compute resources) required for running containers.
CCE supports the following cluster types.
|
Cluster Type |
Description |
|---|---|
|
CCE standard cluster |
CCE standard clusters are for commercial use, which fully support the standard features of open-source Kubernetes clusters. CCE standard clusters offer a simple, cost-effective, highly available solution. There is no need to manage and maintain master nodes. You can choose between the container tunnel network model or VPC network model depending on your service needs. CCE standard clusters are ideal for typical scenarios that do not require special performance or cluster scale requirements. |
|
CCE Turbo cluster |
CCE Turbo clusters run on the Cloud Native 2.0 infrastructure. They feature hardware and software synergy, zero network performance loss, high security and reliability, and intelligent scheduling, offering you a one-stop and cost-effective container service. The Cloud Native 2.0 networks are available for large-scale, high-performance scenarios. In CCE Turbo clusters, container IP addresses are assigned from VPC CIDR blocks, and containers and nodes can be in different subnets. External networks in a VPC can directly access container IP addresses for high performance. |
|
CCE Autopilot cluster |
CCE Autopilot allows you to create serverless clusters that offer optimized Kubernetes compatibility and free you from O&M. CCE Autopilot clusters can be deployed without user nodes, simplifying the application deployment. There is no need to purchase nodes or maintain the deployment, management, and security of nodes. You only need to focus on the implementation of application service logic, which greatly reduces your O&M costs and improves the reliability and scalability of applications. |
Node
A node is a cloud server (virtual or physical machine) running an instance of the Docker Engine. Containers are deployed, run, and managed on nodes. The node agent (kubelet) runs on each node to manage container instances on the node. The number of nodes in a cluster can be scaled.
Node Pool
A node pool contains one node or a group of nodes with identical configuration in a cluster.
VPC
A VPC is a logically isolated virtual network that facilitates secure internal network management and configurations. Resources in the same VPC can communicate with each other, but those in different VPCs cannot communicate with each other by default. VPCs provide the same network functions as physical networks and also advanced network services, such as elastic IP addresses and security groups.
Security Group
A security group is a collection of access control rules for ECSs that have the same security protection requirements and are mutually trusted in a VPC. After a security group is created, you can create different access rules for the security group to protect the ECSs that are added to this security group.
Relationship Between Clusters, VPCs, Security Groups, and Nodes
- Different clusters are created in different VPCs.
- Different clusters are created in the same subnet.
- Different clusters are created in different subnets.
Pod
A pod in Kubernetes is the smallest, basic unit for deploying applications or services. It can contain one or more containers, which typically share storage and networks. 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.
Container
A container is a running instance that is created using a Docker image. Multiple containers can run on a node (host). Containers are essentially processes, but they run in their own separate namespaces, unlike processes that directly run on the host machine. These namespaces provide isolation, allowing each container to have its own file system, network API, process ID, and more. This enables OS-level isolation for containers.
Workload
A workload is an application running on Kubernetes. No matter how many components are there in your workload, you can run it in a group of Kubernetes pods. A workload is an abstract model of a group of pods in Kubernetes. Workloads in Kubernetes are classified as Deployments, StatefulSets, DaemonSets, jobs, and cron jobs.
- Deployment: Pods are completely independent of each other and functionally identical. They feature auto scaling and rolling upgrade. Typical examples include web applications like Nginx and blog platforms like WordPress.
- StatefulSet : A StatefulSet in Kubernetes allows for the organized deployment and removal of pods. Each pod in a StatefulSet has a unique identifier and can communicate with other pods. StatefulSets are ideal for applications that need persistent storage and communication between pods, like etcd, the distributed key-value store, or MySQL High Availability, the high-availability databases.
- DaemonSet: A DaemonSet in Kubernetes guarantees that all or specific nodes have a DaemonSet pod running and automatically deploys DaemonSet pods on newly added nodes in a cluster. It is used for services that need to run on every node, like log collection (Fluentd) and monitoring agent (Prometheus Node Exporter) services.
- Job: A job in Kubernetes is a task that ensures a specific number of pods are successfully executed. It is used for one-off tasks that need to be performed in a cluster, such as data backup and batch processing.
- Cron job: A cron job in Kubernetes is a task that runs at a specific time and is used for recurring tasks that need to be executed periodically. It is commonly used for scheduled data synchronization and generating reports on a regular basis.
Image
An image is a standardized 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. Its content remains unchanged after being built. 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.
Images become containers at runtime, that is, containers are created from images. Containers can be created, started, stopped, deleted, and suspended.
Namespace
A namespace in Kubernetes is a way to group and organize related resources and objects, such as pods, Services, and Deployments. It provides a logical grouping mechanism where data within different namespaces is isolated from each other, while still allowing them to share basic resources like CPUs, memory, and storage within the same cluster. By deploying different environments in separate namespaces, such as development, testing, and production, you can ensure environment isolation and simplify management and maintenance tasks.
In Kubernetes, most resource objects are associated with a specific namespace (default), including pods, Services, ReplicationControllers, and Deployments. 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.
Service
In Kubernetes, a Service is used to define access policies for pods. There are different types of Services with their respective values and behaviors:
- ClusterIP: This is the default Service type. It assigns a unique IP address to the Service within the cluster. This IP address is only accessible within the cluster and cannot be directly accessed from external networks. ClusterIP Services are typically used for internal communication 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. This type of Service allows external traffic to reach the Service by using the Elastic IP (EIP) associated with the node and the specified port.
- LoadBalancer: This type of Service uses the load balancer provided by cloud service providers to expose the Service to the Internet. An external load balancer can distribute traffic to the NodePort and ClusterIP Services within the cluster.
- DNAT: DNAT translates IP addresses for cluster nodes and enables multiple nodes to share an EIP. This enhances reliability as an EIP does not need to be bound to a single node. Any node failure does not affect access to the cluster.
Layer-7 Load Balancing (Ingress)
An ingress is a set of routing rules for requests entering a cluster. It provides Services with URLs, load balancing, SSL termination, and HTTP routing for external access to the cluster.
Network Policy
Network policies provide policy-based network control to isolate applications and reduce the attack surface. A network policy uses label selectors to simulate traditional segmented networks and controls traffic between them and traffic from outside.
ConfigMap
A ConfigMap is used to store configuration data or configuration files as key-value pairs. ConfigMaps are similar to secrets, but they are specifically designed to handle non-sensitive string data in a more convenient manner.
Secret
A secret manages sensitive data like passwords, tokens, and keys without exposing them in images or pod specifications. Secrets can be mounted to pods as volumes or injected to pods as environment variables.
Label
In Kubernetes, a label is a key-value pair that is associated with a resource object like a pod, Service, or Deployment. 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 in Kubernetes simplify resource management and operations by allowing users to group and select resource objects based on their labels. This enables batch operations on the selected resource groups, such as traffic distribution, scaling, configuration updates, and monitoring.
Annotation
Annotations are defined as key-value pairs and are similar to labels. However, they serve a different purpose and have different constraints.
Labels are used for selecting and managing resources, following strict naming rules and defining metadata for Kubernetes objects. Label selectors use labels to select resources for users.
On the other hand, annotations provide additional information defined by users. While Kubernetes does not directly use annotations to control resource behavior, external tools can access the information stored in annotations to extend Kubernetes functions.
PersistentVolume
A PV is a storage resource in a cluster that can be either a local disk or network storage. It exists independently of pods, so even if a pod using a PV is deleted, the data stored in the PV will not be lost.
PersistentVolumeClaim
A PersistentVolumeClaim (PVC) is a request for PVs. It specifies the desired storage size and access mode. Kubernetes will automatically find a suitable PV that meets these requirements.
The relationship between PVs and PVCs is similar to that between pods and nodes. Just as pods consume resources from nodes, PVCs consume resources from PVs.
Auto Scaling - HPA
Horizontal Pod Autoscaling (HPA) is a function that implements horizontal scaling of pods in Kubernetes. HPA enables a Kubernetes cluster to automatically scale in or out the number of pods based on CPU usage, memory usage, or other specified metrics. By setting thresholds for target metrics, HPA dynamically adjusts the pod count to ensure the best application performance.
Affinity and Anti-Affinity
If an application is not containerized, multiple components of the application may run on the same virtual machine and processes communicate with each other. However, in the case of containerization, software processes are packed into different containers and each container has its own lifecycle. For example, the transaction process is packed into a container while the monitoring/logging process and local storage process are packed into other containers. If closely related container processes run on distant nodes, routing between them will be costly and slow.
- Affinity: Containers are scheduled onto the nearest node. For instance, when application A and application B have frequent interactions, it is important to use affinity to ensure that these two applications are placed in close proximity or even on the same node. By doing so, any potential performance degradation caused by slow routing can be avoided.
- Anti-affinity: Instances of the same application spread across different nodes to achieve higher availability. Once a node is down, instances on other nodes are not affected. For example, if an application has multiple replicas, it is necessary to use the anti-affinity feature to deploy the replicas on different nodes. In this way, no single point of failure will occur.
Node Affinity
By selecting labels, you can schedule pods to specific nodes.
Pod Affinity
You can deploy pods onto the same node to reduce consumption of network resources.
Pod Anti-Affinity
You can deploy pods onto different nodes to reduce the impact of system breakdowns. Anti-affinity deployment is also recommended for workloads that may interfere with each other.
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. LimitRange is a feature used to apply resource limits to objects, like pods, within a namespace.
It offers several capabilities, including:
- Restricts the minimum and maximum resource usage for each pod or container in a namespace.
- Sets limits on the storage space that each PVC can request within a namespace.
- Controls the ratio between the request and limit for a resource within a namespace.
- Sets default requests and limits for compute resources within a namespace and automatically applies them to multiple containers during container execution.
Environment Variable
An environment variable is a variable whose value can affect the way a running container will behave. A maximum of 30 environment variables can be defined at container creation time. You can modify environment variables even after workloads are deployed, increasing flexibility in workload configuration.
The function of setting environment variables on CCE is the same as that of specifying ENV in a Dockerfile.
Chart
For your Kubernetes clusters, you can use Helm to manage software packages, which are called charts. Helm is to Kubernetes what the apt command is to Ubuntu or what the yum command is to CentOS. Helm can quickly search for, download, and install charts.
Charts are a Helm packaging format. It describes only a group of related cluster resource definitions, not a real container image package. A Helm chart contains only a series of YAML files used to deploy Kubernetes applications. You can customize some parameter settings in a Helm chart. When installing a chart, Helm deploys resources in the cluster based on the YAML files defined in the chart. Related container images are not included in the chart but are pulled from the image repository defined in the YAML files.
Application developers need to push container image packages to the image repository, use Helm charts to package dependencies, and preset some key parameters to simplify application deployment.
Helm directly installs applications and their dependencies in the cluster based on the YAML files in a chart. Application users can search for, install, upgrade, roll back, and uninstall applications without defining complex deployment files.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot
