什么是pod？
pod是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在pod中，所有容器都被统一安排和调度，并运行在共享的上下文中。对于具体应用而言，pod是它们的逻辑主机，pod包含业务相关的多个应用容器。所以，pod是一组具有共享命名空间、IP地址和端口的容器的集合。
每个pod还包含一个Pause容器，Pause容器是Pod的父容器，主要负责僵尸进程的回收管理。同时，通过Pause容器可以使用同一个Pod里面的不同容器共享存储、网络等。
Pod的状态
pending（挂起） pod已经被kubernetes系统接收，但是仍有一个或多个容器未被创建，可以通过kubectl describe查看处于pending状态的原因
Running（运行中） pod已经被绑定到一个节点上，并且所有的容器被已经被创建，而且至少有一个是运行的状态、正在启动或者重启，可以通过kubectl logs查看Pod的日志
Succeeded 所有容器执行成功，并终止，并且不会再次重启，可以荣国kubectl logs查看Pod的日志
Failed（失败） 所有容器都已终止，并且至少一个容器以失败的方式终止，也就是说这个容器要么以非零状态退出，要么被系统中之，可以荣国log和describe查看pod的日志和状态
unknown（未知） 通常是由于通信问题造成无法获得pod的状态
ImagePullBackOffErrImagePull 镜像拉取失败，一般是由于镜像不存在、网络不通或者需要登录认证引起的，可以使用describe命令查看具体的原因
CrashLoopBackOff 容器启动失败，可以通过logs命令查看具体的原因，一般为启动命令不正确、健康检查不通过等原因
OOMKilled 容器内存溢出，一般是容器的内存Limit设置的过小，或者程序本身有内存溢出，可以通过logs查看程序的启动日志
Terminating Pod正在被删除，可以通过describe查看状态
SysctlForbiden pod自定义了内核配置，但kubectl没有添加内核配置或配置的内核参数不支持，可以通过describe查看具体原因
completed 容器内部主进程退出，一般计划任务执行结束会显示该状态，此时可以通过log查看容器日志
ContainerCreating pod正在创建，一般正在下载镜像，或者有配置不当的地方，可以通过describe查看具体原因。
Pod探针
Pod提供的探针可以很方便的用来检测容器的应用是否正常
实现方式 说明
ExecAction 在容器内执行一个指定的命令，如果命令返回值为0，则认为容器健康
TCPSocketAction 通过TCP连接检查容器指定的端口，如果端口开放，则认为容器健康
HTTPGetAction 在指定的URL进行Get请i去，如果状态码在200~400之间，则认为容器健康
Success（成功） 容器通过检查
Failure（失败） 容器检查失败
Unknown（未知） 诊断失败，因此不采取任何措施
Pod探针有三类，分别是livenessProbe（存活探针）、readinessProbe（就绪探针）、startupProbe（启动探针）。
livenessProbe（存活探针）：判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略决定是否重启容器
readinessProbe（就绪探针）：判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器
startupProbe（启动探针）：判断容器内的应用是否启动成功，在success状态前，其他探针都处于无效状态。
Pod镜像拉取策略和重启策略
在发布应用或者更改控制器配置时，会触发pod的滚动更新，此时针对容器的镜像有不同的拉取方式。
操作方式 说明
Always 总是拉取，无论镜像是否存在，总是拉取
Never 无论是否存在都不会拉取
IfNotPressent 镜像不存在时拉取镜像，是k8s默认的策略，但是如果tag为latest，则总是拉取
Pod进行部署或者运行时，难免会出现故障，对于故障，Pod也有不同的处理方式
操作方式 说明
Always 默认策略，容器失效时，自动重启该容器
OnFailure 容器以不为0的状态码终止，自动重启该容器
Never 无论何种状态，都不会重启
Pod文件语法
（1）Pod文件的一级属性
一级属性主要包含5部分：
apiVersion <string>版本，由kubernetes内部定义，版本号必须可以用kubectl api-versions查询到
kind <string> 类型，由kubernetes内部定义，版本号必须可以用kubectl api-resource查询到
metadata <Object>元数据，主要是资源标识和说明，常用的由name、namespace、labels等
spec <Object>描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
status <object>状态信息，里面的内容不需要定义，由kubernetes自动生成
（2）spec（规格）属性
在一级属性中，spec是研究的重点，它的常见子属性有：
containers <[]object>容器列表，用于定义容器的详细信息
nodeName <string> 根据nodeName的值将pod调度到指定的Node节点上
nodeSelector <map[]>根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上
hostNetwork<boolean> 是否使用主机网络模式，默认为false，如果设置为true，标识使用宿主机网络
volumes <[]object>存储卷，用于定义pod上面挂载的存储信息
restartPolicy<string>重启策略，表示pod在遇到故障的时候的处理策略。
Pod启动阶段（相位 phase）
pod创建完之后，一直到持久运行起来，中间有很多步骤，也就有很多出错的可能，因此会有很多不同的状态
1：pod的启动过程包含的步骤
（1）调度到某台node上。kubernetes根据一定的优先级宣发选择一台node节点将其作为Pod运行的node
（2）拉取镜像
（3）挂在存储配置等
（4）运行起来。如果有健康检查，会根据检查的结果来设置其状态
2：phase的可能状态
（1）Pending：表示APIServer创建了Pod资源对象并已经存入了etcd中，但是它并未被调度完成（比如还没有调度到某台node上），或者仍然处于从仓库下载镜像的过程中
（2）Running：Pod已经被调度到某节点之上，并且Pod中所有容器都已经被kubelet创建。至少有一个容器正在运行，或者正处于启动或者重启状态（也就是说Running状态下的pod不一定能被正常访问）
（3）Succeeded：有些pod不是长久运行的，比如job、cronjob，一段时间后Pod中的所有容器都被成功终止，并且不会再重启。需要反馈任务执行的结果
（4）Failed：pod中的所有容器都已终止了，并且至少有一个容器时因为失败终止。也就是说，容器以非0状态退出或者被系统终止，比如command写的问题
（5）Unknown：表示无法读取pod状态，通常是kube-cotroller-manager无法与pod通信
故障排除步骤：
查看Pod事件
kubectl describe TYPE NAME_PREFIX
查看pod日志（failed状态下）
kubectl logs <POD_NAME> [-c Container_NAME]
进入pod（状态为running，但是服务没有提供）
kubectl exec -it <POD_NAME> bash
查看集群信息
kubectl get nodes
发现集群状态正常
kubectl cluster-info
查看kubelet日志发现
journalctl -xefu kubelet
