首先我们要明确一个概念，Kubernetes并不是只支持Docker这一个容器运行时，通过我的另一篇文章什么是Kubernetes的CRI-容器运行时接口介绍的内容，我们知道Kubernetes通过CRI这个抽象层，支持除Docker之外的其他容器运行时，比如rkt甚至支持客户自定义容器运行时。因此，借助CRI这个抽象层，使得Kubernetes不依赖于底层某一种具体的容器运行时实现技术，而是直接操作pod，pod内部再管理多个业务上紧密相关的用户业务容器，这种架构便于Kubernetes做扩展。这是第一个原因。
第二个原因，我们假设Kubernetes没有pod的概念，而是直接管理容器，那么一组容器作为一个单元，假设其中一个容器死亡了，此时这个单元的状态应该如何定义呢？应该理解成整体死亡，还是个别死亡？
这个问题不易回答的原因，是因为包含了这一组业务容器的逻辑单元，没有一个统一的办法来代表整个容器组的状态，这就是Kubernetes引入pod的概念，并且每个pod里都有一个Kubernetes系统自带的pause容器的原因，通过引入pause这个与业务无关并且作用类似于Linux操作系统守护进程的Kubernetes系统标准容器，以pause容器的状态来代表整个容器组的状态。
第三也就是最后一个原因，pod里所有的业务容器共享pause容器的IP地址，以及pause容器mount的Volume，通过这种设计，业务容器之间可以直接通信，文件也能够直接彼此共享。
Kubernetes里的每个pod都有唯一的IP地址。Pod的IP地址可以通过命令kubectl describe pod来查看：
这个IP地址用来支持Kubernetes的底层网络借助Flannel,openswitch等虚拟二层网络技术来实现集群内任意两个pod之间的TCP/IP通信。也就是说，一个Pod内的容器与另外主机的pod容器能够直接通信。
Pod被创建后，会被Kubernetes master调度到某个具体的node上进行绑定：
上图中蓝色高亮区域代表的就是这个被观察的pod被分配到的node的名称。
pod和node绑定之后，node上的kubelet进程会对pod进行初始化操作，启动相关的Docker容器。
上图红色区域显示了Docker容器从正在从远端pull镜像，到pull完成，到创建Docker容器运行实例，到最终启动实例的状态迁移过程。
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
