前言
Kubernetes中的基本资源对象有四大类，分别是：Pod、Service、Volume 和 Namespace ；它们能够表示系统中部署的应用、工作负载、网络和磁盘资源，共同定义了集群的状态。Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合。Pod是Kubernetes 集群中能够被创建和管理的最小部署单元，Pod是一组容器的集合。
分类
静态Pod：并不将当前的状态存放到etcd这个数据库中去，而是存储在某个node的文件中，并且只有在这个node上面才能启动这个静态pod
普通Pod：会将自己的状态存放到etcd中去，随后master节点会将创建的Pod进行资源的分配
根容器
Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元，每一个Pod都最少拥有一个Init container(根容器)与一些自定义的应用容器；
Pod中的根容器会在Pod启动之初运行，主要用于初始化一些基础配置，另外一种应用容器则是在Pod处于Running状态时内部存活的容器，它们的主要作用是对外提供服务；需注意的是，根容器会比应用容器优先启动。
Pod 中的容器是可以通过 卷（Volume） 的方式共享文件目录的，这些 Volume 能够存储持久化的数据；在当前 Pod 出现故障或者滚动更新时，对应 Volume 中的数据并不会被清除，而是会在 Pod 重启后重新挂载到期望的文件目录中去。我会在 后面的章节 详细地介绍 Kubernetes 中卷的创建、挂载是如何进行的，在这里我们需要知道的是卷的挂载是 Pod 启动之前必须要完成的工作
同一个 Pod 中的多个容器会被共同分配到同一个 Host 上并且共享网络栈，也就是说这些 Pod 能够通过 localhost 互相访问到彼此的端口和服务，如果使用了相同的端口也会发生冲突，同一个 Pod 上的所有容器会连接到同一个网络设备上，这个网络设备就是由 Pod Sandbox 中的沙箱容器在 RunPodSandbox 方法中启动时创建的；每一个节点上都会由 Kubernetes 的网络插件 Kubenet 创建一个基本的 cbr0 网桥并为每一个 Pod 创建 veth 虚拟网络设备，同一个 Pod 中的所有容器就会通过这个网络设备共享网络，也就是能够通过 localhost 互相访问彼此暴露的端口和服务。
生命周期
Pod phase
Pod 的 status 属性是一个 PodStatus 对象，拥有一个 phase 字段。它简单描述了 Pod 在其生命周期的阶段。
| 阶段 | 描述 |
|---|---|
| Pending | Pod 已被 Kubernetes 接受，但尚未创建一个或多个容器镜像。这包括被调度之前的时间以及通过网络下载镜像所花费的时间，执行需要一段时间。 |
| Running | Pod 已经被绑定到了一个节点，所有容器已被创建。至少一个容器正在运行，或者正在启动或重新启动。 |
| Succeeded | 所有容器成功终止，也不会重启。 |
| Failed | 所有容器终止，至少有一个容器以失败方式终止。也就是说，这个容器要么已非 0 状态退出，要么被系统终止。 |
| Unknown | 由于一些原因，Pod 的状态无法获取，通常是与 Pod 通信时出错导致的。 |
Pod conditions
每个 Pod 都拥有一个 PodStatus，里面包含 PodConditions 数组，代表 Condition 是否通过。PodCondition 属性描述：
| 字段 | 描述 |
|---|---|
| lastProbeTime | 最后一次探测 Pod Condition 的时间戳。 |
| lastTransitionTime | 上次 Condition 从一种状态转换到另一种状态的时间。 |
| message | 上次 Condition 状态转换的详细描述。 |
| reason | Condition 最后一次转换的原因。 |
| status | Condition 状态类型，可以为 True False Unknown |
| type | Condition 类型 |
关于 Condition Type 的描述：
| Type | 描述 |
|---|---|
| PodScheduled | Pod 已被调度到一个节点 |
| Ready | Pod 能够提供请求，应该被添加到负载均衡池中以提供服务 |
| Initialized | 所有 init containers 成功启动 |
| Unschedulable | 调度器不能正常调度容器，例如缺乏资源或其他限制 |
| ContainersReady | Pod 中所有容器全部就绪 |
Container probes
Probe 是在容器上 kubelet 的定期执行的诊断，kubelet 通过调用容器实现的 Handler 来诊断。目前有三种 Handlers ：
- ExecAction：在容器内部执行指定的命令，如果命令以状态代码 0 退出，则认为诊断成功。
- TCPSocketAction：对指定 IP 和端口的容器执行 TCP 检查，如果端口打开，则认为诊断成功。
- HTTPGetAction：对指定 IP + port + path路径上的容器的执行 HTTP Get 请求。如果响应的状态代码大于或等于 200 且小于 400，则认为诊断成功。
每次探测可能有如下之一的结果：
- Success：容器诊断通过
- Failure：容器诊断失败
- Unknown：诊断失败，因此不应采取任何措施
kubelet 可以选择性地对运行中的容器进行两种探测器执行和响应：
livenessProbe：指示容器是否正在运行，如果活动探测失败，则 kubelet 会杀死容器，并且容器将受其 重启策略 的约束。如果不指定活动探测，默认状态是Success。readinessProbe：指示容器是否已准备好为请求提供服务，如果准备情况探测失败，则控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始化延迟之前的默认准备状态是Failure，如果容器未提供准备情况探测，则默认状态为Success。
Pod lifetime
通常，Pod 不会消失，除非人为或者控制器销毁它们。此规则的唯一例外情况是，Success 或 Failed 阶段超过一段时间（由主服务器中的 terminate-pod-gc-threshold 确定）的 Pod 将过期并自动销毁。
三种可用的控制器类型：
- Job：例如批量计算，仅适用于
restartPolicy为OnFailure或Never的 Pod - ReplicationController, ReplicaSet, 或 Deployment：例如 Web 服务，ReplicationControllers 仅适用于
restartPolicy为Always的 Pod。 - DaemonSet：需要在每个节点运行一个的 Pod，以便用于系统服务。
小结
Kubernetes 中的每一个 Pod 都包含多个容器，这些容器在通过 Kubernetes 创建之后就能共享网络和存储，这其实是 Pod 非常重要的特性，我们能通过这个特性构建比较复杂的服务拓扑和依赖关系。
参考地址：https://draveness.me/kubernetes-pod