用户您好!请先登录!

Kubernetes引入pod的概念,为何不直接操作Docker容器

Kubernetes引入pod的概念,为何不直接操作Docker容器

首先要明确一个概念,Kubernetes并不是只支持Docker这一个容器运行,我们知道Kubernetes通过CRI这个抽象层,支持除Docker之外的其他容器运行,比如rkt甚至支持客户自定义的容器运行。因此,借助CRI这个抽象层,使得Kubernetes不依赖于底层某一种具体的容器运行时实现技术,而是直接操作pod,pod内部再管理多个业务上紧密相关的用户业务容器,这种架构便于Kubernetes做扩展。这是第一个原因。

为什么Kubernetes要引入pod的概念,而不直接操作Docker容器

第二个原因,我们假设Kubernetes没有pod的概念,而是直接管理容器,那么一组容器作为一个单元,假设其中一个容器死亡了,此时这个单元的状态应该如何定义呢?应该理解成整体死亡,还是个别死亡?

这个问题不易回答的原因,是因为包含了这一组业务容器的逻辑单元,没有一个统一的办法来代表整个容器组的状态,这就是Kubernetes引入pod的概念,并且每个pod里都有一个Kubernetes系统自带的pause容器的原因,通过引入pause这个与业务无关并且作用类似于Linux操作系统守护进程的Kubernetes系统标准容器,以pause容器的状态来代表整个容器组的状态。

为什么Kubernetes要引入pod的概念,而不直接操作Docker容器

第三也就是最后一个原因,pod里所有的业务容器共享pause容器的IP地址,以及pause容器mount的Volume,通过这种设计,业务容器之间可以直接通信,文件也能够直接彼此共享。

Kubernetes里的每个pod都有唯一的IP地址。Pod的IP地址可以通过命令kubectl describe pod来查看:

为什么Kubernetes要引入pod的概念,而不直接操作Docker容器

这个IP地址用来支持Kubernetes的底层网络借助Flannel,openswitch等虚拟二层网络技术来实现集群内任意两个pod之间的TCP/IP通信。也就是说,一个Pod内的容器与另外主机的pod容器能够直接通信。

Pod被创建后,会被Kubernetes master调度到某个具体的node上进行绑定:

为什么Kubernetes要引入pod的概念,而不直接操作Docker容器

上图中蓝色高亮区域代表的就是这个被观察的pod被分配到的node的名称。

pod和node绑定之后,node上的kubelet进程会对pod进行初始化操作,启动相关的Docker容器。

上图红色区域显示了Docker容器从正在从远端pull镜像,到pull完成,到创建Docker容器运行实例,到最终启动实例的状态迁移过程。

X-Eyes Admin
X-Eyes Admin

要发表评论,您必须先登录