Today, I will continue to introduce you to the relevant knowledge of Linux operation and maintenance. The main content of this article is a detailed explanation of the Pod object.
1. Pod overview
"Pod", directly translated as "pod" in English, is the smallest resource object in a Kubernetes cluster. Pods also have containers, just as there are many beans in a "pod". However, the Kubernetes cluster cannot directly manage and control the containers in the Pod, and can only manage the Pod. It should be emphasized that the operation of containers in Pod generally requires a Docker environment. However, Pod itself also supports the operation of containers other than Docker .
In a Kubernetes cluster, there are two ways to run a Pod:
1. Running a container in a Pod
This mode is the most common usage of a Pod, and the Pod itself is an encapsulation of a container.
2. Run multiple containers at the same time in a Pod
Sometimes, we need multiple containers to work together to provide a service. In this case, we need to encapsulate these multiple containers in a Pod. Pods manage the storage resources of these containers as an entity.
In a Pod, the shared environment includes Linux namespaces, cgroups, and other potentially isolated environments, while in a Pod's environment, each container may also have smaller isolated environments. Containers in Pods share IP addresses and port numbers, and they can communicate with each other through loopback addresses or inter-process communication. But containers between different pods have different IP addresses. The containers in the Pod have permission to share the Volume, which is usually defined as a part of the Pod and mounted on the Pod's file system.
Pods are temporary entities in a Kubernetes cluster. After a Pod is created, it will be assigned a unique ID, scheduled to a node, and maintained in the desired state according to the settings until it is deleted. If the Node running the Pod goes down, the Pod assigned to this Node will be rescheduled to another node after a timeout. But the original Pod and the rescheduled Pod are essentially two Pods because they have different IDs. Usually, the names of the two pods will also change, but we can set the two pods to have the same name.
2. Pod management of multiple containers
In a Kubernetes cluster, each container in a Pod is a process, and containers in the same Pod are assigned to a Node node.
Note that running multiple containers concurrently within a Pod is a cumbersome usage, and should only be used when those containers need to run tightly together. For example, in a Pod, there are containers of WebServer and Sidecar at the same time. WebServer is responsible for providing HTTP services, and Sidecar is responsible for updating and obtaining files from the remote end. The architecture is as follows:
3. Pod use
We usually rarely create a single Pod directly on a Kubernetes cluster, because the life cycle of a Pod is a short-lived, "burn-in" entity. Pods do not "self-heal". If the Node running the Pod fails, or the scheduler itself fails, the Pod will be deleted. Similarly, if the Node node where the Pod is located lacks resources or the Pod is in maintenance state, the Pod will also be evicted. In a Kubernetes cluster, we usually use a higher-level Controller control layer to manage Pod instances. The Controller can create and manage multiple Pods, providing replica management, rolling upgrades, and cluster-level self-healing capabilities.
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200