add shared translation doc section : Paragraph 4

blog-en/addtional_p4.md

@@ -0,0 +1,14 @@
+In the world of Kubernetes, Pod is the smallest scheduling deployment unit. Simply put, a Pod is a group of containers made up of closely related containers. As a whole, these "intimate" containers share something to make the interaction between them more efficient. For example, for a network, containers in the same Pod share the same IP address and port space, allowing them to access each other directly via localhost. For storage, the volume defined in the Pod is mounted to each of its containers so that each container can access it.
+
+In fact, all of the above features can be implemented as long as a certain set of containers share some Linux Namespaces and mount the same volume. Below, we will analyze how the CRI Manager in PouchContainer implements the Pod model by creating a concrete Pod:
+
+1. When Kubelet needs to create a new Pod, it first calls the CRI interface of RunPodSandbox, and the implementation of the interface by CRI Manager is to create a special container we call "infra container". From the perspective of container implementation, it is not special, it is nothing more than calling Container Manager to create a normal container mirrored as pause-amd64:3.0. But from the perspective of the entire Pod container group, it has a special role, it is to contribute its own Linux Namespace, as the above mentioned Linux shared namespace of the container, the container in the container group is connected Come together. It is more like a carrier that carries all the other containers in the Pod and provides the infrastructure for their operation. In general, we also use an infra container to represent a Pod.
+
+2. After the infra container is created, Kubelet creates other containers in the pod container group.Each time a container is created, the two `CRI` interfaces `CreateContainer` and `StartContainer` will be called.For `CreateContainer`, `CRIManager` simply converts the `CRI` format container configuration to a PouchContainer format container configuration and passes it to the Container Manager, which completes the specific container creation work.The only thing we need to care about here is how the container joins the Linux Namespace of the infra container mentioned above. In fact, the real implementation is very simple. There are three parameters `PidMode`, `IpcMode` and `NetworkMode` in the container configuration parameters of the Container Manager, which are used to configure the Pid Namespace, Ipc Namespace and Network Namespace of the container. In general terms, the configuration of the container's Namespace generally has two modes: "None" mode, which creates the container's own unique Namespace, and the other is the "Container" mode, that is, the Namespace of another container. Obviously, we only need to configure the above three parameters as "Container" mode, and add the Namespace of the infra container. Specifically, CRI Manager does not need to care about how to join. For the `StartContainer`, the CRI Manager simply does a forwarding, gets the container ID from the request and calls the Container Manager's Start interface to start the container.
+
+
+3. Finally, Kubelet will continuously call the two CRI interfaces ListPodSandbox and ListContainers to get the running status of the container on this node. ListPodSandbox lists the status of each infra container, while ListContainer lists the status of other containers except the infra container. The problem is that there is no difference between the infra container and the other containers for the Container Manager. So how does CRI Manager distinguish between these containers? In fact, when creating a container, CRI Manager adds an additional label to the existing container configuration to indicate the type of the container. Therefore, when the `ListPodSandbox` and `ListContainers` interfaces are implemented, different types of containers can be filtered by using the value of the label as a condition.
+
+
+
+In summary, for the creation of Pod, we can outline the process to create the infra container first, then create other containers in the pod, and let them join the Linux Namespace of the infra container.