The basic concept of Pod

1. Resource limitations

      Pod is the smallest resource management component in kubernetes, and Pod is also a resource object that minimizes running containerized applications. A Pod represents a process running in the cluster. Most other components in kubernetes support and extend Pod functions around Pods, such as controller objects such as StatefulSet and Deployment used to manage Pod operations, used to expose Service and Ingress objects of Pod applications, and provide storage for Pods The PersistentVolume stores resource objects, etc.

2. Two ways to use Pod

       A container runs in a Pod. The mode of one container in each Pod is the most common usage. In this usage, you can think of the Pod as the encapsulation of a single container, and kubernetes manages the Pod instead of the container directly.
Run multiple containers concurrently in a Pod. A Pod can also encapsulate several containers that need to be tightly coupled and cooperate with each other at the same time, and they share resources. These containers in the same Pod can cooperate with each other to form a service unit, such as one container sharing files, and another sidecar container updating these files. Pods manage the storage resources of these containers as a single entity.

3. The meaning and usage of several important fields in Pod

1、NodeSelector

Is a field for users to bind Pods to Nodes

apiVersion: v1
kind: Pod
...
spec:
 nodeSelector:
   disktype: ssd

Such a configuration means that this Pod can only run on the node that carries the "disktype: ssd" label (Label) forever; otherwise, it will fail to schedule

2、NodeName

Once this field of the Pod is assigned a value, the Kubernetes project will consider that the Pod has been scheduled, and the result of the scheduling is the assigned node name. Therefore, this field is generally set by the scheduler, but users can also set it to "cheat" the scheduler. Of course, this method is generally used during testing or debugging.

3、HostAliases

Define the contents of the Pod's hosts file (such as /etc/hosts)

apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...

In this Pod's YAML file, I set a set of IP and hostname data. Thus, after the Pod starts, the contents of the /etc/hosts file will look like this:

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

The bottom two lines of records are what I set for the Pod through the HostAliases field. It should be pointed out that in the Kubernetes project, if you want to set the content in the hosts file, you must use this method . Otherwise, if the hosts file is modified directly, the kubelet will automatically overwrite the modified content after the Pod is deleted and rebuilt.

In addition to the above configurations related to "machines", you may also find that all attributes related to the Linux Namespace of the container must also be at the Pod level. The reason is also easy to understand: the design of Pod is to let the containers inside it share as much Linux Namespace as possible, retaining only the necessary isolation and restriction capabilities. In this way, the effect simulated by the Pod is very similar to the relationship between programs in the virtual machine.

For example, in the following Pod's YAML file, I define shareProcessNamespace=true:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

This means that the containers in this Pod share the PID Namespace.

In this YAML file, I also defined two containers: one is the nginx container, and the other is the shell container with tty and stdin enabled.

If the tty and stdin fields are not set in yaml, an error will be reported when using this command

When I introduced the basics of containers earlier, I explained what tty and stdin are. And declaring to enable them in the Pod's YAML file is actually equivalent to setting the -it (-i means stdin, -t means tty) parameter in docker run.

If you still don't quite understand the functions of them, you can directly think that tty is a resident applet provided by Linux to users, which is used to receive the user's standard input and return the standard output of the operating system. Of course, in order to be able to enter information in the tty, you also need to open stdin (standard input stream) at the same time.

So, after the Pod is created, you can use the tty of the shell container to interact with the container. Let's practice it together:

kubectl create -f nginx.yaml

In this way, we can execute the ps command in the shell container to view all running processes:

kubectl attach -it nginx -c shell
或者
kubectl exec -ti nginx -c shell sh
/ # ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   14 101       0:00 nginx: worker process
   15 root      0:00 sh
   21 root      0:00 ps ax

It can be seen that in this container, we can not only see its own ps ax command, but also the process of the nginx container and the /pause process of the Infra container. This means that the process of each container in the entire Pod is visible to all containers: they share the same PID Namespace.

Similarly, any container in a Pod that wants to share the namespace of the host must also be defined at the Pod level , for example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true
  hostIPC: true
  hostPID: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

In this Pod, I defined the Network, IPC and PID Namespace of the shared host. This means that all containers in this Pod will directly use the host's network, directly communicate with the host through IPC, and see all the processes running in the host.

Of course, in addition to these properties, the most important field in the Pod is "Containers". In the last article, I also introduced "Init Containers". In fact, these two fields belong to Pod's definition of containers, and the contents are exactly the same, except that the life cycle of Init Containers will precede all Containers, and will be executed in strict accordance with the order of definition.

The definition of Container in the Kubernetes project is not much different from that of Docker. In the previous series of articles on getting started with container technology concepts, I shared with you Image (mirror), Command (start command), workingDir (working directory of the container), Ports (ports to be developed by the container), and volumeMounts (to be mounted on the container). Loaded Volume) are the main fields that constitute the Container in the Kubernetes project. But here, there are still a few attributes that deserve your extra attention.

First, the ImagePullPolicy field. It defines the strategy for image pulling. The reason why it is a Container-level attribute is because the container image is originally part of the definition of Container.

The value of ImagePullPolicy defaults to Always, that is, the image is pulled every time a Pod is created. In addition, when the image of the container has a name like nginx or nginx:latest, ImagePullPolicy will also be considered as Always.

4. The life cycle of Pod objects in Kubernetes

Changes in the Pod life cycle are mainly reflected in  the Status  part of the Pod API object, which is its third important field besides Metadata and Spec. Among them, pod.status.phase is the current state of the Pod, which has the following possible situations:

• Pending . This state means that the Pod's YAML file has been submitted to Kubernetes, and the API object has been created and saved in Etcd. However, some containers in this Pod cannot be successfully created for some reason. For example, scheduling is unsuccessful.

• running . In this state, the Pod has been successfully scheduled and bound to a specific node. All the containers it contains have been successfully created and at least one is running.

• Succeeded . This status means that all containers in the Pod have finished running normally and have exited. This situation is most common when running one-off tasks.

• Failed . In this state, at least one container in the Pod exits with an abnormal status (non-zero return code). The appearance of this state means that you have to find a way to debug the application of this container, such as viewing Pod Events and logs.

• Unknown . This is an abnormal state, which means that the status of the Pod cannot be continuously reported to the kube-apiserver by the kubelet, which is likely to be a communication problem between the master and slave nodes (Master and Kubelet).

Furthermore, the Status field of the Pod object can be subdivided into a set of Conditions (status). The values ​​for these breakdown states include: PodScheduled, Ready, Initialized, and Unschedulable. They are mainly used to describe the specific reasons for the current Status.

For example, the Pod's current Status is Pending, and the corresponding Condition is Unschedulable, which means that there is a problem with its scheduling.

Among them, the subdivision status of Ready is worthy of our attention: it means that the Pod has not only started normally (Running status), but also can provide services to the outside world. There is a difference between the two (Running and Ready), and you might as well think about it carefully.

The status information of the Pod is an important criterion for us to judge the running status of the application. Especially after the Pod enters the non-"Running" state, you must be able to respond quickly and start tracking and locating according to the abnormal situation it represents. Not to scramble to consult the documentation.