容器化实践指南 | 全面解析Pod（上）

在介绍Kubernetes集群管理的网络篇中，我们已经提到过Pod的概念。在Kubernetes的模型中，Pod是构建各类工作负载的最基本模块，也是用户可以创建和部署的最小单元。本文将重点介绍Pod的基本概念、生命周期以及Pod的一些重要属性。

 

在Kubernetes中，Pod是最基本的操作单元，也是用户应用运行的载体。Pod封装了运行应用程序的容器、存储资源、网络地址以及控制容器如何运行的各种配置。实际上，整个Kubernetes系统的设计都是以Pod为基础展开的，包括如何部署和运行Pod、如何保障Pod的高可用、如何建立Pod的访问入口等。

 

Pod与其他组件的关系

 

➤ Pod与容器 

 

Docker是最常用的容器运行时，但是Pod同样也支持使用其它的容器运行时。一个Pod中可以包含一个或者多个容器，其中运行多个容器的场景通常是这些容器之间耦合紧密并且需要共享部分资源，从微服务的角度来讲，同一个Pod中的多个容器通常聚合形成一个单一的服务单元。Kubernetes会将同一个Pod中的所有容器部署在一个Node节点中。

 

➤ Pod与网络 

 

每个Pod将被分配一个唯一的IP地址，同一Pod内部的所有容器都将共享同一个网络地址空间，因此Pod内部的容器间通过localhost即可互相通信，而这些容器对外通信时就需要共享同一个IP地址和所有端口，这就要求用户在创建Pod时需要定义好容器间如何对这些网络资源进行共享。

 

➤ Pod与存储 

 

Pod内的所有容器也将共享存储资源，用户在创建Pod时可以指定一系列共享存储卷，Pod中的所有容器均可以访问这些存储卷用于互相共享数据。由于Pod本身的生命周期可能较短，共享存储卷中的数据将会随着Pod被删除而释放，Kubernetes也支持用户通过PV（PersistentVolumes – 持久化存储卷）将持久化存储介质挂载到Pod中供容器使用。

 

如何定义Pod的生命周期

 

Pod的整个生命周期被定义为多种不同状态，包括：Pending、Running、Succeeded、Failed、Unknown。

 

这些状态的具体定义如下所示：

 

 

Pod可以被用户直接创建，也可能通过Kubernetes提供的各类控制器创建（控制器为用户提供了多种基于Pod的工作负载模型，我们将在后续文章中详细介绍）。当Pod被创建时，对应的容器资源将会被分配到某个集群节点中启动并运行，直到Pod停止。

 

通常Pod会因为3种原因停止：所有的容器均退出、节点资源不足将Pod驱逐、节点出现故障。

 

用户可以对Pod中的容器设置重启策略，用于在容器退出时判断是否要重启该容器。重启策略包括Always、OnFailure及Never，分别代表容器总是会被重启、仅在失败退出时重启、从不重启。如果用户不设置重启策略，那么默认的策略为Always。

 

其它重要功能

 

健康检查：用户可以对Pod设置两种健康检查探针：LivenessProbe和ReadinessProbe。前者用于判断Pod中的容器是否存活（处于running状态），当探测到容器不健康时kill该容器并根据容器重启策略做进一步处理。后者用于判断容器是否启动完成（处于ready状态），如果探测失败即容器无法接受请求，则修改Pod的状态，用于对Pod对应的访问入口进行处理。

 

Init容器：用户可以在Pod中定义一个或者多个Init容器，这些容器会优先于Pod中的其它容器启动。Init容器总是按照顺序一次运行一个，并且必须运行到成功，如果Init容器启动失败，Kubernetes将会不断重启该Pod，直到Init容器成功为止。当所有Init容器运行完成时，Kubernetes才会初始化Pod并正常启动其它的普通容器。

 

Pod Preset：Pod Preset是一种Kubernetes中的API资源，用来在创建Pod时向其注入运行时所需的额外信息，用户通过使用标签选择器来确定为Pod应用哪些Presets。Preset最大的好处在于可以创建出具有通用性的Pod模板，而模板的使用者只需要通过Preset提供Pod运行时所需的定制化形式，从而无需关注Pod实现的所有细节。

 

本期关于Pod的概念就介绍到这里，在实际使用kubernetes的过程中，用户其实很少会直接创建Pod，而是通过本文提到的控制器（Controller）来创建不同特定类型的Pod，下一篇文章我们将会详细介绍各种不同的控制器类型，敬请期待。