Basic Concepts
CCI provides Kubernetes-like APIs based on the Kubernetes ecosystem and allows you to create associated resources through the console or APIs. Before using CCI, you are advised to understand related basic concepts to better understand CCI.
Image
A container image is a special file system that provides the programs, libraries, resources, and configuration files required for running a container. It also contains configuration parameters, for example, anonymous volumes, environment variables, and users. An image does not contain any dynamic data, and its content will not be changed after creation.
Container
The relationship between an image and a container is similar to that between a class and an instance in object-oriented programming. Images are static, while containers are running entities of images. A container can be created, started, stopped, deleted, and suspended.
Namespace
A namespace provides a method of allocating resources among multiple users. When you have a large number of projects and personnel, you can define namespaces based on project attributes, such as production, test, and development.
Pod
A pod is the smallest deployable unit of computing that you can create and manage. A pod is a group of one or more containers, with shared storage resources, a unique IP address, and a specification for how to run the containers.

Pods can be used in either of the following ways:
- One pod that runs a single container: This is the most common use case. You can think of a pod as a wrapper around a single container, and the pod can be managed directly rather than the container.
- One pod runs multiple containers that need to work together:
Generally, pods are not created directly but are created through workloads, for example, Deployments. A workload can have multiple pods and enjoy replica management, rolling upgrade, and self-healing. Generally, pods are created from a pod template.
Init Container
An init container is a type of container that starts and exits before the application containers start in a pod. If there are multiple init containers, they will be started in the defined sequence. The data generated in the init containers can be used by the application containers because storage volumes in a pod are shared.
Init containers are designed to perform initialization tasks and can be used in multiple resources, such as Deployments and jobs.
For details, see Init Containers.
Label
A label is a key-value pair attached to an object and is used to transfer user-defined attributes.
Labels are often used to select objects that meet conditions from a group of objects. Labels are currently the most important node grouping method.
For example, you may create labels (tier=frontend, app=myapp) to mark frontend pods and labels (tier=backend, app=myapp) to mark backend pods. You can then use selectors to select pods with specific labels and apply services or Deployments to these pods.
For details, see Labels.

Deployment
Deployments are a type of workloads.
A Deployment can contain one or more pods. Each pod has the same role, and the system automatically distributes requests to the pods of a Deployment. All pods created for a Deployment share storage volumes.
When using a Deployment, you only need to describe your desired pod status. The Deployment will help you change the pod status to the target status.
For details, see Deployments.
Service
Pods are mortal. They can be created and destroyed. Once destroyed, they cannot be resurrected. Pod controllers create and destroy pods dynamically (for example, during scaling or rolling upgrades). Each pod obtains its own IP address, but the IP address is not always stable or dependable. This leads to a problem: if a group of pods (backends) provides services to another group of pods (frontends) inside a cluster, how do those frontends find out and connect to the corresponding backends?
A Service is a method of exposing a network application running in a pod or a group of pods as a network service. Each Service object defines a logical set of endpoints (usually pods) and policies for accessing these pods.
Consider an image processing backend that is running with three pod replicas as an example. These replicas are interchangeable. This means the frontend does not need to know which replica it calls. The pods in the backend may change, and the frontend does not need to be aware of that or keep track of the backend status. A Service enables this decoupling.
For details, see Service.
ConfigMap
A ConfigMap is used to store configuration data as key-value pairs or configuration files. ConfigMaps are similar to secrets, but provide a means of working with strings that do not contain sensitive information.
For details, see ConfigMaps.
Secret
A secret is an object for storing sensitive data such as authentication information, certificates, and private keys. A secret can be loaded to a container as environment variables when the container is started.
For details, see Secrets.
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