Detailed explanation of the use of cloud native technology kubernetes scheduling unit pod

The smallest scheduling unit in k8s --- pod

In the previous article, we briefly introduced the problems that k8s can solve. In short, the problem it solves is the orchestration and scheduling of containers. Its core value lies in: there are actually various relationships between tasks running in large-scale clusters. The processing of these relationships is the most difficult part of task orchestration and system management. k8s was born for this problem.

This sentence is difficult to understand. We start with the existing knowledge, unravel it and slowly understand it. We already know that the essence of a container is a process, which consists of three parts:

If a container is a process in a cloud environment, then you can think of k8s as an operating system in a cloud environment.

In an operating system, processes do not always run in isolation, but are often run as a process group. When actually deploying applications, our applications are often not run in an isolated form in Docker containers. There are various relationships between applications. Sometimes, they must run on the same machine and access each other, similar to bundling. For example, if two containers need to exchange files or share certain Linux Namespaces, etc. We call this kind of relationship a "super-intimate relationship."

Based on the above premise, k8s took this into consideration at the beginning of its design. Therefore, when it was designed, it did not use containers as the smallest scheduling unit, but used the new concept of pod as the smallest scheduling unit of k8s. Each pod can contain multiple containers. In this way, the applications deployed in the containers are bundled, that is, they can only be deployed on one machine, and the deployment is either successful or failed, and there is no possibility of an intermediate state.

What is the relationship between Pod and container?

It should be noted that Pod is a logical concept, and its essence is a group of containers that share certain resources. To be precise, containers in the same pod share the same network namespace and, of course, can also share resources such as mounted volumes.

The so-called sharing is not dependence, but equality.

If we have two containers A and B, and if A depends on B, then A must be started after B. If the status of A and B is equal, then there will be no strict requirements for the startup order of A and B. This is true sharing. So who will create the shared network resources in advance?

In a Pod, if multiple application containers are included, an infra container is required to associate these application containers. It looks like this:

In K8S, the infra container takes up very few resources. It only runs an image called pause, so it is also called the pause container. The disk size it occupies is between 100 and 200 kb. The purpose of infra is to create a network namespace, and then application container A and application container B can be added to this network namespace.

For container A and container B in the Pod:
1. They can communicate directly using localhost;
2. The network devices they see are exactly the same as those seen by the Infra container;
3. A Pod has only one IP address, which is the IP address corresponding to the Network Namespace of the Pod;
4. Of course, all other network resources are shared by one Pod and all containers in the Pod;
5. The life cycle of the Pod is consistent only with the Infra container, and has nothing to do with containers A and B.
6. For all user containers in the same Pod, their inbound and outbound traffic can also be considered to be completed through the Infra container

In this design mode, it is very easy to mount the same Volume. You only need to configure the volume parameters in the Pod's initialization yaml file. The specific content will be shared later.

For containers, a container can only manage one process, not an application. When we migrate applications to the cloud, we need to divide the application into several processes and then consider whether the application modules have a "super-intimate relationship". Processes with super-intimate relationships can be deployed in one Pod, and other processes can be deployed in another Pod. Using this idea to split the application is in line with the original intention of container design.

The above is the detailed content of the detailed explanation of the use of the cloud native technology kubernetes scheduling unit pod. For more information on the use of kubernetes scheduling unit pod, please pay attention to other related articles on 123WORDPRESS.COM!