Pod

What Is a Pod?

A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates one or more containers, storage resources, a unique network IP address, and options that govern how the container(s) should run.

Pods can be used in either of the following ways:

• One container runs in one pod. This is the most common usage of pods in Kubernetes. You can view the pod as a single encapsulated container, but Kubernetes directly manages pods instead of containers.
• Multiple containers that need to be coupled and share resources run in a pod. In this scenario, an application contains a main container and several sidecar containers, as shown in Figure 1. For example, the main container is a web server that provides file services from a fixed directory, and the sidecar container periodically downloads files to the directory.
  Figure 1 Pod
  

In Kubernetes, pods are rarely created directly. Instead, controllers such as Deployments and jobs, are used to manage pods. Controllers can create and manage multiple pods, and provide replica management, rolling upgrade, and self-healing capabilities. A controller generally uses a pod template to create corresponding pods.

Container Specifications

You can use GPUs in CCI only if the namespace is of the GPU-accelerated type.

Currently, three types of pods are provided, including general-computing (used in general-computing namespaces), RDMA-accelerated, and GPU-accelerated (used in GPU-accelerated namespaces). For details about the specifications, see "Pod Specifications" in Notes and Constraints.

Creating a Pod

Kubernetes resources can be described using YAML or JSON files. For more details about the YAML format, see YAML Syntax. The following example describes a pod named nginx. This pod contains a container named container-0 and uses the nginx:alpine image, 0.5 vCPUs, and 1024 MB memory.

apiVersion: v1                      # Kubernetes API version
kind: Pod                           # Kubernetes resource type
metadata:
  name: nginx                       # Pod name
spec:                               # Pod specification
  containers:
  - image: nginx:alpine             # Used image is nginx:alpine
    name: container-0               # Container name
    resources:                      # Resources required for applying for a container. The values of limits and requests in CCI must be the same.
      limits:
        cpu: 500m                   # 0.5 vCPUs
        memory: 1024Mi
      requests:
        cpu: 500m                   # 0.5 vCPUs
        memory: 1024Mi
  imagePullSecrets:                 # Secret used to pull the image, which must be imagepull-secret.
  - name: imagepull-secret

As shown in the annotation of YAML, the YAML description file includes:

• metadata: Information such as name, label, and namespace
• spec: Pod specification such as image and volume used

If you query a Kubernetes resource, you can see the status field. This field indicates the status of the Kubernetes resource, and does not need to set when the resource is created. This example is a minimum set, and other parameter definition will be described later.

For the parameter description of Kubernetes resources, see API Reference.

After the pod is defined, you can create it using kubectl. If the YAML file is named nginx.yaml, run the following command to create the file. -f indicates that it is created in the form of a file.

$ kubectl create -f nginx.yaml -n $namespace_name
pod/nginx created

Container Images

A container image is a special file system, which provides the programs, libraries, resources, and configuration files required for running containers. A container image also contains configuration parameters, for example, for anonymous volumes, environment variables, and users. An image does not contain any dynamic data. Its content remains unchanged after being built.

SoftWare Repository for Container (SWR) has synchronized some common images from the container registry so that you can use the images named in the format of Image name:Tag (for example, nginx:alpine) on the internal network. You can query the synchronized images on the SWR console.

Viewing Pod Information

After the pod is created, you can run the kubectl get pods command to query the pod information, as shown below.

$ kubectl get pods -n $namespace_name
NAME           READY   STATUS    RESTARTS   AGE
nginx          1/1     Running   0          40s

The preceding information indicates that the nginx pod is in the Running state, indicating that the pod is running. READY is 1/1, indicating that there is one container in the pod, and the container is in the Ready state.

You can run the kubectl get command to query the configuration information about a pod. In the following command, -o yaml indicates that the pod is returned in YAML format. -o json indicates that the pod is returned in JSON format.

$ kubectl get pod nginx -o yaml -n $namespace_name

You can also run the kubectl describe command to view the pod details.

$ kubectl describe pod nginx -n $namespace_name

Deleting a Pod

When a pod is deleted, Kubernetes stops all containers in the pod. Kubernetes sends the SIGTERM signal to the process and waits for a period (30 seconds by default) to stop the container. If it is not stopped within the period, Kubernetes sends a SIGKILL signal to kill the process.

You can stop and delete a pod in multiple methods. For example, you can delete a pod by name, as shown below.

$ kubectl delete po nginx -n $namespace_name
pod "nginx" deleted

Delete multiple pods at one time.

$ kubectl delete po pod1 pod2 -n $namespace_name

Delete all pods.

$ kubectl delete po --all -n $namespace_name
pod "nginx" deleted

Delete pods by labels. For details about labels, see the next section.

$ kubectl delete po -l app=nginx -n $namespace_name
pod "nginx" deleted