Pod是一个或多个容器的组合，这些容器共享存储，网络和命名空间，以及运行规范，在Pod中，所有容器都被统一安排和调度，并运行在共享的上下文中，对于具体应用而言，Pod是他们的逻辑主机，Pod包含业务相关的多个应用容器，所以,Pod是一组具有共享命名空间，IP地址和端口的容器的集合
1:从使用的角度来看
在实际的使用时，单个容器是无法单独来支撑我们的应用的，往往需要很多微服务才能组成一个系统，并且还会存在A服务依赖B服务，B服务需要和C服务共用某个目录。另外，在使用裸容器时,很难实现对容器内进行健康检査以及横向扩容等操作,而 Pod 可以轻松解决这些问题。
2:从Kubernetes 的角度来看
Docker 只是容器 Runtime(运行时)的一种们还有很多容器 Runtime，比如 Rkt、CRI-0等，而 Kubernetes 作为目前最流行的容器编排工具，需要支持各个 Runtime 并且不依赖于底层Runtime 的实现技术，于是就抽象出了 Pod 这个概念，用于管理多个紧密相连的符合 CRI 标准的容器。
Pod 可以简单的理解为一组、一个或多个容器，每个 Pod 还包含一个 Pause 容器，Pause 容器是 Pod 的父容器，主要负责僵尸进程的回收管理。同时，通过 Pause 容器可以使同一个 Pod里面的不同容器共享存储、网络、PID、IPC等，容器之间可以使用 Localhost:Port 的方式相互访问，可以使用 volume 实现数据共享。根据 Docker 的构造，Pod 可以被创建为一组具有共享命名空卷、IP 地址和端口的容器。
Pod状态字段
1.Pending(挂起)
2.Running(运行中)
3.Succeeded(所以容器执行成功，并终止)
4.Failed(失败)
Pod探针
在生产环境中，进程正常启动并不代表能正常处理请求，所以合理的设计应用的健康检查尤其重要，在使用裸机或裸容器部署时，一般很难对应用做很完善的健康检查，而Pod提供的探针可以很方便的用来检测的应用是否正常，目前探针有三种检测方式，可以根据不同的场景选择合适的健康检查方式
Pod探针的实现方式
ExecAction : 在容器内执行一个指定的命令，如果命令返回值为0，则认为容器健康
TCPSocketAction:通过TCP连接检查指定的端口，如果端口开放，则认为容器健康
HTTPGetAction:对指定的URL进行Get请求，如果状态码在200-400之间，则认为容器健康
表3:Pod 探针检查容器后可能得到的状态
状态
Success(成功)
Failure(失败)
Unknown(未知)
说明
容器通过检查
容器检查失败
诊断失败，因此不采取任何措施
三:Pod 镜像拉取策略和重启策略
在发布应用或者更改控制器配置时，会触发Pod 的滚动更新，此时针对容器的镜像有不同的拉取方式。如表 4所示。
表 4:镜像拉取策略
操作方式
Always
Never
IfNotPressent
说明
总是拉取，无论镜像是否存在，总是拉取
无论是否存在都不会拉取
镜像不存在时拉取镜像,是 k8s 默认的策略,但是如果 tag为latest，则总是拉取