pod存在的意义

我们先来了解一下pod的原理以及它存在的意义，我们了解到容器的本质就是一个进程，不是说它里面只能运行一个进程，而是容器里的pid等于1的进程就是容器的启动命令，容器没有办法管理多个进程，比如你的容器pid等于一的命令是一个启动go的命令，其他进程都是这个进程的子进程，你执行exec执行了一个python的命令，那python进程的启动关闭谁来处理呢，容器技术高性能的缺陷就是容器内只能运行一个进程，kubernetes对pod的管理归根结底还是对linux系统上的进程的管理，我们知道linux上的应用都不是单个进程形成的，而是以一个进程组的方式经行管理的，我们想把这个应用容器化，就要把这个进程组内的进程每个都做成一个个的容器，使用容器的亲密性把三个容器调度到一台机器上，因为他们互相之间会发生直接的文件交换、使用localhoat，或者socket进行通信、会发生非常频繁的远程调用、需要共享某些 Linux Namespace（比如，一个容器要加入另一个容器的 Network Namespace）等等。当我们使用docker swarm经行调度时，因为资源问题，可能会出现，他们没法被调度到同一台机器上，当我们使用lubernetes经行调度时，这些容器被放在一个pod里，kubernetes会根据这个pod的资源使用量，也就是容器资源使用量总和调度到一个合适的节点上，pod就是共享了一些资源的容器，这些资源是network，volume等等，也就是一个一个容器加入到另一个容器的namaspace内，但是这又会出现另一个问题，就是一个容器要比另一个容器先启动，这样的话，容器内的关系就变成拓扑结构，我们应该把他变成平等关系，所以引入了infa容器，infa容器会在其他容器启动前先启动，其他容器通过加入infa容器的network namesapce，共享资源，infa容器非常小，可以用下面的图来说明
所以pod具有一下特性

pod里的容器可以直接通过localhost通信
他们看到的网路设备跟infa容器看到的一样
一个pod只有一个ip地址就是他的network namespace的ip地址
每个pod都有一份资源，被里面的容器所共享
pod的生命周期只和infa容器有关，而和里面的其他容器无关

所以如果我们想设计一个网络插件我们只需要关心infa容器的network namespace有关，所以在应用容器化的时候，一个很关键的做法是如何把一些具有亲密性的容器放在一个pod里，比如war包与Java应用，日志收集的例子，他们都使用了initcontainer，也就是常说的sidecar，sidecar 指的就是我们可以在一个 Pod 中，启动一个辅助容器，来完成一些独立于主进程（主容器）之外的工作。所以有时侯我们考虑应用上云的时候，我们需要知道应用有那些进程运行在虚拟机里，我们可以把虚拟机想像成一个pod，把这些容器都做成容器镜像，把有顺序的容器做成initcontainer，这是合理的做法，