容器与pod

容器的本质是一个视图被隔离、资源受限的进程

 容器里pid=1的进程就是应用本身

管理虚拟机=管理基础设施；管理容器=管理应用本身

k8s是云时代的操作系统，那么容器镜像其实就是这个操作系统的软件安装包

那pod就是进程组

举例：

一个程序由4个进程组成，这些进程之间共享某些文件

如果这个程序由一个容器跑起来，那么pid=1的进程就是应用本身，那么谁来管理剩余的三个进程呢？

由于容器是单进程模型，pid=1的进程挂掉后，其他进程也会随之挂掉

除非应用进程本身举报“进程管理”能力（这意味着：helloworld进程需要具备systemd的能力）

或者，容器的pid=1进程改为systemd

这会导致：管理容器=管理systemd=直接管理应用本身

所以我们要将这4个进程放到不同容器里，通过进程组（pod）来管理这4个容器

可是为什么pod必须是原子调度单位呢？

如果app先被调度到nodeA中那么logcollector是无法再被调度到nodeA中，导致两个容器无法紧密协作

但是有了pod的感念就可以很容易解决两个应用运行在同一个宿主机上面

pod的实现机制

pod要解决的问题

容器与容器之间是被namespace和cgroup所隔离，pod需要将这种隔离去打破

1共享网络

在每个容器里都有一个infra container的容器来共享同一个network namespace

直接使用localhost进行通信，这样所有容器看到的网络视图是一样的

所以一个pod只有一个ip地址，也就是这个pod的network namespace对应的IP地址

所有网络资源，都是一个pod一份，并且被该pod中的所有容器共享

整个pod的生命周期跟infra容器一直，而与容器a和b无关

2共享存储

将一个目录同时挂载在两个容器下，从而实现共享存储