Pod就是豆荚里面的小豆子，形象地比喻pod在k8s里面的逻辑状态，Pod是k8s中可部署创建管理的最小单元，一个Pod（就像一个豌豆荚）是一个组，这个组中包含一个或多个容器（如Docker容器），具有共享存储/网络，以及如何运行容器的规范。
Pod的内容总是同时定位和同时调度，并在共享上下文中运行。Pod为特定于应用程序的“逻辑主机”建立模型，它包含一个或多个相对紧密耦合的应用程序容器。在容器之前的世界中，在相同的物理或虚拟机上执行则意味着在相同的逻辑主机上执行。
1、Pod是什么
Pod是Kubernetes应用程序的基本执行单元，是创建或部署的Kubernetes对象模型中最小、最简单的单元。Pod代表在集群上运行的进程。
一个Pod封装了一个应用程序的容器（在某些情况下是多个容器）、存储资源、一个唯一的网络IP和控制容器如何运行的选项。
一个Pod代表一个部署单元，即Kubernetes中的应用程序的一个单个实例，它可能由单个容器或少量紧密耦合且共享资源的容器组成。
Docker是Kubernetes Pod中最常用的容器运行时，但是Pods也支持其他容器运行时。
Pod是Kubernetes应用程序的基本执行单元，是创建或部署的Kubernetes对象模型中最小、最简单的单元。Pod代表在集群上运行的进程。
Pod中的容器共享一个IP地址和端口空间，并且可以通过localhost相互查找。它们还可以使用SystemV信号量或POSIX共享内存等标准进程间通信进行通信。不同的Pods中的容器拥有不同的IP地址，没有特殊配置的情况下是不能通过IPC进行通信的。这些容器通常通过Pod IP地址彼此通信。
Pod中的应用程序也可以访问共享volumes，这些共享volumes被定义为Pod的一部分，可以安装到每个应用程序的文件系统中。
与单个应用程序容器一样，Pods被认为是相对短暂的（而不是持久的）实体。正如在Pod生命周期中所讨论的，创建Pod，分配唯一ID(UID)，并将其调度到节点，直到终止（根据重启策略）或删除。如果一个节点死亡，那么在超时之后，该节点的Pods将被删除。给定的Pod（由UID定义）不会“重新调度”到一个新节点；相反，它可以被一个相同的Pod替换，如果需要，甚至可以使用相同的名称，但是要使用一个新的UID。
如果Pod被删除，那么与之相关联的资源都会被销毁，并在必要时重新创建。
Pods是一个模型，这种模型就是将多个协作流程内聚成一个服务。它们通过提供比其组成应用程序集更高级别的抽象来简化应用程序部署和管理。Pods可以作为部署、水平扩展和副本的单元。在Pods中，托管（协同调度）、共享命运（如终止）、协调副本、资源共享和依赖项管理都是自动处理的。
2、Pod的基本用法
Pod在Kubernetes集群中主要有两种使用方式。
- 运行一个单独的容器：这是最常用的方式；在这种情况下，可以认为一个Pod封装了一个单独的容器，Kubernetes是对Pod进行管理，而不是直接对容器进行管理。
- 运行耦合度高的多个容器：Pod也可能包含多个容器，这些容器之间关联紧密，需要共享资源。将多个容器添加到单个Pod的主要原因是应用可能由一个主进程和一个或多个辅助进程组成。在实践中，把一个进程放到一个容器中运行是最好的。
首先，静态Pod直接由特定的节点上的kubelet进程来管理，不通过master节点上的apiserver，无法与人们常用的控制器Deployment或者DaemonSet进行关联，它由kubulet进程自己来监控，当Pod崩溃时重启该Pod，kubelet也无法对它们进行健康检查。
静态Pod始终绑定在某一个kubelet上，并且始终运行在同一个节点上。kubelet会自动为每一个静态Pod在Kubernetes的apiserver上创建一个镜像Pod(Mirror Pod)，因此可以在apiserver中查询到该Pod，但是不能通过apiserver进行控制和删除。
3、Pod生命周期和重启策略
1）Pod状态
- Pending：API Server已经创建该Pod，但在Pod内还有一个或多个容器的镜像还没被创建，包括正在下载镜像的过程。
- Running：Pod内所有的容器均已创建，且至少有一个容器处于运行状态，正在启动状态或正在重启状态。
- Succeeded：Pod内所有容器均已成功执行后退出，且不会重启。
- Unknow：由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。
2）Pod重启策略
Pod重启策略(RestartPolicy)应用于Pod内的所有容器，并且在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应的操作。Pod的重启策略包括Always（默认）、OnFailure和Never。
- Always：当容器失败时，由kubelet自动重启该容器。
- OnFailure：当容器终止运行且退出码不为0时，由kubelet重启该容器。
- Never：不论容器运行状态如何，kubelet都不会重启该容器。
kubelet重启失效容器的时间间隔以sync-frequnecy乘以2n来计算，如1、2、4、8倍等，最长延迟5min，并且在重启后10min重置该时间。
- RC和DaemonSet：必须设置为Always，需要保证该容器持续运行。
- Job：OnFailure或Never，确保容器执行完后不会再运行。
- Kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为何值，也不会对Pod进行健康检查。
4、Pod的健康检查
Kubernetes对Pod的健康检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。
- LivenessProbe探针：用于判断容器是否存活（Running状态），如果LivenessProbe探测到容器不健康，则kubelet将杀死该容器，并根据容器的重启策略进行相应的处理。如果一个容器不包括LivenessProbe探针，那么kubelet则会认为该容器的LivenessProbe探针返回的结果永远是success。
- ReadinessProbe探针：用于判断容器是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Reday进行设置。如果在运行过程中Ready变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，然后再把恢复到Ready状态的Pod加入到Endpoint列表。这样可以保证客户端再次访问Service时不会被转发到不可用的Pod实例上。
5、Pod的升级和回滚
在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，目前支持两种策略：Recreate（重建）和RollingUpdate（滚动更新），默认值为RollingUpdate。
有时（如新的Deployment不稳定时）用户可能需要将Deployment回滚到旧版本。默认情况下，所有Deployment的发布历史记录都被保留在系统中，以便于用户随时进行回滚（可以配置历史记录数量）。
6、Pod的扩容和缩容
Kubernetes对Pod的扩容和缩容操作提供了手动和自动两种模式，手动模式通过执行kubectl scale命令对一个Deployment/RC进行Pod副本数量的设置，即可一键完成。自动模式则需要用户根据某个性能指标或者自定义业务指标，并指定Pod副本数量的范围，系统将自动在这个范围内根据性能指标的变化进行调整。
从Kubernetes v1.1版本开始，新增了一个名为Horizontal Pod Autoscaler(HPA)的控制器，用于实现基于CPU使用率进行自动Pod扩容和缩容的功能。HPA控制器基于Master的kube-controller-manager服务启动参数--horizontal-pod autoscaler-sync-period定义的时长（默认为30秒），周期性地检测目标Pod的CPU使用率，并在满足条件时对Deployment/RC或Deployment中的Pod副本数量进行调整，以符合用户定义的平均Pod CPU使用率。
