具体过程如下:当用户在K8S的master那边创建了一个Pod后，Kubelet观察到新Pod的创建，于是首先调用CRI（后面的Runtime实现，比如：dockershim，containerd等）创建Pod内的若干个容器。在这些容器里面，第一个被创建的Pause容器是比较特殊的，这是K8S系统“赠送”的容器，里面跑着一个功能十分简单的go语言程序，具体逻辑是一启动就去select一个空的go语言channel，自然就永远阻塞在那里了。一个永远阻塞而且没有实际业务逻辑的pause容器到底有什么用呢？用处大了。我们知道容器的隔离功能利用的是Linux内核的namespace机制，而只要是一个进程，不管这个进程是否处于运行状态（挂起亦可），它都能“占”着一个namespace。因此，每个Pod内的第一个系统容器Pause的作用就是为占用一个Linux的network namespace，而Pod内其他用户容器通过加入到这个network namespace的方式来共享同一个network namespace。用户容器和pause容器之间的关系有点类似于寄居蟹和海螺的关系。

因此，Container Runtime创建Pod内所有容器时，调用的都是同一个命令：

$ docker run --net=none

意思是只创建一个network namespace，而不初始化网络协议栈。如果这个时候通过nsenter方式进入到容器，会看到里面只有一个本地回环设备lo。那么容器的eth0是怎么创建出来的呢？答案是CNI。

CNI主要负责容器的网络设备初始化工作。Kubelet目前支持两个网络驱动，分别是：kubenet和CNI。

Kubenet是一个历史产物，即将废弃，因此这里也不准备过多介绍。CNI有多个实现，官方自带的插件就有p2p，bridge等，这些插件负责初始化pause容器的网络设备，也就是给eth0分配IP等，到时候Pod内其他容器就用这个IP与外界通信。Flanne，calico这些第三方插件解决Pod之间的跨机通信问题。容器之间的跨机通信，可以通过bridge网络或overlay网络来完成。