13. Why do we need Pod?
Essence 13.1 docker container
"""
docker容器的本质 是进程.
主要通过
Namespace 做隔离，Cgroups 做限制，rootfs 做文件系统
"""
Question: Since there are container Why Kubernetes project suddenly come up with a Pod to do?
To answer this question, we still have to remember a problem with what I have repeatedly stressed: What is the nature of the container in the end is?
You should be able to answer them without hesitation: the nature of the container is the process.
Yes. Container, is the future of cloud computing processes in the system; container mirroring is this system of ".exe" installation package . So Kubernetes it?
You should be able to immediately answer it: Kubernetes is the operating system!
very true.
13.2 Process Group
Now, let us log on to a Linux machine, the execution of a command shown below
pstree -g
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
# 小插曲: 当只知道一个命令,如果查询这个命令属于哪个rpm包中?
1. 命令存在时,使用rpm -qf `which 命令`
[root@node02 tools]# rpm -qf `which yum`
yum-3.4.3-161.el7.centos.noarch
2. 命令不存在时,使用yum whatprovides 命令
[root@node02 tools]# yum whatprovides pstree
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirrors.aliyun.com
* extras: mirrors.aliyun.com
* updates: mirrors.aliyun.com
docker-ce-stable/x86_64/filelists_db | 16 kB 00:00:00
kubernetes/filelists | 18 kB 00:00:00
psmisc-22.20-15.el7.x86_64 : Utilities for managing processes on your system
Repo : base
Matched from:
Filename : /usr/bin/pstreeNot difficult to find in a real operating system, the process is not "lonely" run alone, but by way of a process group, "principled" organization together . In the tree diagram of this process, each process behind the numbers in brackets, is its process group ID (Process Group ID, PGID
For the operating system, such a process group is more easy to manage. For example, Linux operating system only need to signal, for example, SIGKILL signal is sent to a process group, all processes in the process group to receive this signal will terminate the operation.
The Kubernetes project does, in fact, the concept of "process group" is mapped to the container technology , and make this cloud computing "operating system" in the "first-class citizens."
13.3 vessel design pattern
Pod in Kubernetes project there are still more important, that is: vessel design mode .
To understand this layer of meaning, I have to let you tell us about Pod implementation principle.
First, Pod most important fact is: it's just a logical concept.
In other words, Kubernetes really deal with, or the host operating system on a Namespace Linux containers and Cgroups, but there is not a so-called Pod boundaries or isolated environment.
So, Pod and how he has been "created" out of it?
The answer is: Pod, in fact, is a set of shared resources in a certain container
Specifically: Pod in all containers, it is shared with a Network Namespace, and may declare share the same Volume.
That such a view, then, an A, Pod B two containers, is not equivalent to a container (container A) share another container (container B) Volume of network and method of play it?
Well it seems to be able to achieve by docker run --net --volumes-from such a command, such as:
$ docker run --net=B --volumes-from=B --name=A image-A ...But you have not thought about, if you really do so, the container B must be started before the container A, so that a plurality of containers in a Pod is not a peer relationship, but topological relationship.
So, in Kubernetes project where, Pod implementation requires the use of an intermediate container that is called Infra container. In this Pod in, Infra container is always the first container is created, and other user-defined container, through the Join Network Namespace way associated with Infra container together. Such organizational relationships, one can use this expression to the following schematic:
As shown above, the user has two containers Pod A and B, there is a Infra container. It is easy to understand, in Kubernetes project where, Infra container must occupy very little resources, so it uses a very special mirror called: k8s.gcr.io/pause. This image is a written in assembly language, is always in a container "pause" state, the size of the decompressed only about 100 ~ 200 KB.
And after the Infra containers "Hold live" Network Namespace, user container can be added to the Network Namespace Infra among the container. So, if you see these containers Namespace files on the host machine (this path Namespace file, I have introduced in the previous content), they point value must be exactly the same.
This means that for Pod in the containers A and B is:
- They may communicate directly localhost;
- They see network equipment Infra container with exactly what you see;
- A Pod only one IP address, which is the Pod's Network Namespace corresponding IP address;
- Of course, all other network resources, is a Pod A and is shared by all of the Pod in the container;
- Pod life cycle is only consistent with Infra container, regardless of the container A and B.
For the same for all users Pod inside containers, they are out of the flow, it is also considered to be completed by Infra container. This is important, because in the future if you want to Kubernetes develop a network plug, consideration should focus on is how to configure the Pod's Network Namespace, rather than how each user container to use your network configuration, this makes no sense.
This means that if you need to install some network plugins can be configured in a package or container is completed, it is not desirable: rootfs Infra container mirrored almost nothing, there is no room you are free to play. Of course, this also means that you do not have to care about the network plug-in user to start or not the container, but only need to focus on how to configure the Pod, is Network Namespace you can Infra container.
With this design, after sharing Volume is much simpler: Kubernetes define the project as long as all are designed in Pod Volume level can be.
In this way, a corresponding Volume host directory for Pod is only one, as long as the statement Pod in the container mount the Volume, you will be able to share this Volume corresponding host directory. For example, the following example:
apiVersion: v1
kind: Pod
metadata:
name: two-containers
spec:
restartPolicy: Never
volumes:
- name: shared-data
hostPath:
path: /data
containers:
- name: nginx-container
image: nginx
volumeMounts:
- name: shared-data
mountPath: /usr/share/nginx/html
- name: debian-container
image: debian
volumeMounts:
- name: shared-data
mountPath: /pod-data
command: ["/bin/sh"]
args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]In this example, debian-container and nginx-container declare mount the shared-data this Volume. And shared-data is hostPath type. Therefore, it is in the corresponding directory on the host is: / data. And this directory, in fact, it was simultaneously bind-mounted into which the above two containers.
That is why, nginx-container from its / usr / share / nginx / html directory, read the reasons debian-container generated index.html file.
Understand the realization of the principle of Pod, let us discuss the "container design mode", much easier.
Pod This "super intimate relationship" container design, in fact, it is hoped, when the user wants to run multiple functions not related applications in a container, priority should be given or not they are should be described as in a Pod the multiple containers.
To be able to grasp this way of thinking, you should try to try to use it to describe some of the problems difficult to solve with a single container.
The first and most typical example is: WAR package to the Web server.
We now have a Java Web application WAR package, it needs to be up and running on the Tomcat webapps directory.
If you can only use Docker to do it, then how to deal with this combination to do with it?
- In one method, the WAR package directly on the mirror Tomcat webapps directory, a new image is made up and running. However, this time, if you want to update the contents of the WAR, or upgrade to Tomcat mirror, it is necessary to re-create a new publishing images, very troublesome.
- Another way is that you simply did not matter WAR package, for ever publish a Tomcat container. However, the container's webapps directory, you must declare a hostPath type of Volume, thereby WAR package on the host to mount them into the Tomcat container up and running. However, so you have to solve a problem, namely: how to make every host, are prepared in advance of this directory is stored WAR package it? This point of view, you can only be maintained independently of a distributed storage system.
In fact, with the following Pod, a problem easily solved. We can make the WAR and Tomcat mirror respectively, and put them together as a Pod in two containers "combination." This Pod configuration file as follows:
apiVersion: v1
kind: Pod
metadata:
name: javaweb-2
spec:
initContainers:
- image: geektime/sample:v2
name: war
command: ["cp", "/sample.war", "/app"]
volumeMounts:
- mountPath: /app
name: app-volume
containers:
- image: geektime/tomcat:7.0
name: tomcat
command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
volumeMounts:
- mountPath: /root/apache-tomcat-7.0.42-v2/webapps
name: app-volume
ports:
- containerPort: 8080
hostPort: 8001
volumes:
- name: app-volume
emptyDir: {}In this Pod, we define the two containers, the first container mirror using geektime / sample: v2, this image, only a WAR package (sample.war) in the root directory. While the second container is used it is a standard image Tomcat.
However, you may have noticed, type the WAR container is no longer an ordinary container, but a type of container Container Init.
In Pod, all containers Init Container defined, the user of the container will start first ratio spec.containers defined. And, Init Container container will start one by one in order, but until they all start and quit, user container will not start.
So, after the Init Container type of package container WAR start, I performed a "cp /sample.war / app", the application WAR package are copied to the / app directory, then exit.
Then the / app directory, mount the Volume of a man named app-volume.
The next very crucial. Tomcat container, also declared app-volume to mount under its own webapps directory.
So, when Tomcat and other containers start, it will exist under its webapps directory sample.war file: This file is the WAR package to copy the Volume inside the container starts, and this Volume is shared by the two containers.
Like this, we use a kind of "combination" approach to solve the problem of the coupling relationship between the WAR and Tomcat containers.
In fact, this so-called "combination" operation, the vessel is the most commonly used design patterns in a pattern, its name: sidecar.
As the name suggests, sidecar mean that we can in a Pod, start an auxiliary vessel, to accomplish some independent main process (primary container) work.
For example, in our Pod in this application, Tomcat container is the main container we want to use, and the presence of the WAR container, just to give it a WAR package only. So, we run with the Init Container way priority WAR package containers, played the role of a sidecar.
The second example, is the log collection container.
For example, I now have an application, you need to keep the output log file to the container / var / log directory.
At this point, I can put a Pod in the application container Volume mount / var / log directory on.
Then I run a sidecar container while this Pod, the statement also mount it on your own Volume / var / log directory and the same.
In this way, the next sidecar container just have to do one thing, and that is to continue to read the log file from your / var / log directory, or forwarded to MongoDB Elasticsearch stored up. In this way, a basic log collection is complete.
As with the first example, in this case the main job sidecar also be done using a shared Volume operations on files.
But do not forget, Pod Another important feature is that it's all containers share the same Network Namespace. This makes a lot of related Pod network configuration and management, it can also be handed sidecar complete, and completely without user interference container. The most typical example here than Istio this micro-management service project.
Istio project uses micro sidecar container complete service governance principles, I will soon explain to the back.
Note: Kubernetes community had to "container design model" theory, consolidation has become a small paper , you can click the link to browse.