K8S---Pod重启策略和状态解释
目录
一、重启策略：Pod在遇到故障之后重启的动作
1.1 重启策略设置建议
1.2 always
1.3 never
1.4 onfailure
1.4.1 非0状态
1.4.2 为0状态
二、pod各种状态解释
2.1 Pod 一直处于Pending状态
2.2、Pod一直处于Waiting 或 ContainerCreating状态
2.3、Pod 一直处于ImagePullBackOff状态
2.4、Pod 一直处于CrashLoopBackOff状态
2.5 Pod处于Error状态
2.6 Pod 处于Terminating或 Unknown状态
三、pod从创建到成功或失败的事件
PodScheduled
Initialized
Ready
Unschedulable
Pod状态的详细说明
一、重启策略：Pod在遇到故障之后重启的动作
1：Always：当容器终止退出后，总是重启容器，默认策略
2：OnFailure：当容器异常退出（退出状态码非0）时，重启容器
3：Never：当容器终止退出，从不重启容器。
（注意：k8s中不支持重启Pod资源，只有删除重建，重建）
重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长为10s，20s，40s，80s，160s，300s，300s是最大延迟时长
1.1 重启策略设置建议
因为重启策略默认的就是Always，这也是合理的，因此在一般情况下，重启策略不需要设置，这里仅仅是作为知识点拿出来展示一下，在实际使用中，在大多数情况下都不需要进行重启策略配置
1.2 always
[root@master test]# vim always.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30; exit 3
kubectl apply -f always.yaml 创建中
运行中
出错了
立即重启
注：证明重启策略默认是always，总是自动拉取
1.3 never
[root@master test]# vim never.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo01
namespace: zy
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30; exit 3
restartPolicy: Never
kubectl apply -f never.yaml
注：这时pod故障后就一直不重启了
1.4 onfailure
1.4.1 非0状态
[root@master test]# vim onfailure.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo02
namespace: zy
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 20; exit 3
restartPolicy: OnFailure
kubectl apply -f onfailure.yaml
当容器异常退出（退出状态码非0）时，重启容器
1.4.2 为0状态
[root@master test]# mv onfailure.yaml onfailure0.yaml
[root@master test]# vim onfailure0.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo03
namespace: zy
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 20; exit 0
restartPolicy: OnFailure
kubectl apply -f onfailure0.yaml
退出后显示的完成，说明正常退出，只是完成了这个动作，并不是错误。
退出状态码为0时包含两种状态，一种是正常完成后返回值0，（complated）；第二种 手动指定 exit 0
[root@master test]# kubectl delete -f .
pod "foo" deleted
pod "foo01" deleted
pod "foo03" deleted
二、pod各种状态解释
2.1 Pod 一直处于Pending状态
Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl describe pod命令查看到当前Pod的事件，进而判断为什么没有调度)。
可能原因:资源不足（集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源); HostPort 已被占用(通常推荐使用Service对外开放服务端口)。
2.2、Pod一直处于Waiting 或 ContainerCreating状态
首先还是通过 kubectl describe pod命令查看当前Pod的事件。可能的原因有:
1、镜像拉取失败，比如镜像地址配置错误、拉取不了国外镜像源（gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时 (可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。
2、CNI网络错误，一般需要检查CNI网络插件的配置，比如:无法配置Pod 网络、无法分配IP地址。
3、容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数
4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盘坏道（input/output error)。
2.3、Pod 一直处于ImagePullBackOff状态
通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。
2.4、Pod 一直处于CrashLoopBackOff状态
此状态说明容器曾经启动了，但又异常退出。这时可以先查看一下容器的日志。
通过命令kubectl logs 和kubectl logs --previous 可以发下一些容器退出的原因，比如:容器进程退出、健康检查失败退出;此时如果还未发现线索，还而已到容器内执行命令(kubectl exec cassandra - cat /var.log/cassandra/system.loq)来进一步查看退出原因;如果还是没有线索，那就需要SSH登录该Pod所在的Node上，查看Kubelet或者Docker的日志进一步排查。
2.5 Pod处于Error状态
通常处于Error状态说明Pod启动过程中发生了错误。
常见的原因:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制，比如超过了LimitRange等;违反集群的安全策略，比如违反了PodSecurityPolicy.等;容器无法操作集群内的资源，比如开启RDAC后，需要为ServiceAccount配置角色绑定。
2.6 Pod 处于Terminating或 Unknown状态
从v1.5开始，Kubernetes不会因为Node失联而删除其上正在运行的Pod，而是将其标记为Terminating 或 Unknown 状态。想要删除这些状态的Pod有三种方法：
1、从集群中删除Node。使用公有云时，kube-controller-manager会在VM删除后自动删除对应的Node。而在物理机部署的集群中，需要管理员手动删除Node（kubectl delete node）。
2、Node恢复正常。kubelet会重新跟kube-apiserver通信确认这些Pod的期待状态，进而再决定删除或者继续运行这些Pod。用户强制删除，用户可以执行（kubectl delete pods pod-name --grace-period=0 --force）强制删除Pod。除非明确知道Pod的确处于停止状态（比如Node所在VM或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的Pod，强制删除容易导致脑裂或数据丢失等问题。
3、Pod行为异常，这里所说的行为异常是指Pod没有按预期的行为执行，比如没有运行podSpec 里面设置的命令行参数。这一般是podSpec yaml文件内容有误，可以尝试使用 --validate 参数重建容器，比如（kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml）；也可以查看创建后的podSpec是否是对的，比如（kubectl get pod mypod -o yaml）；修改静态Pod的Manifest后未自动重建，kubelet 使用inotify 机制检测 /etc/kubernetes/manifests 目录（可通过 kubelet 的 -pod-manifest-path 选项指定）中静态Pod的变化，并在文件发生变化后重新创建相应的 Pod。但有时也会发现修改静态Pod的 Manifest后未自动创建新 Pod的情景，此时已过简单的修复方法是重启 Kubelet。
Unknown 这个异常状态意味着Pod的状态不能持续地被 kubelet汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。
三、pod从创建到成功或失败的事件
PodScheduled
pod正处于调度中，刚开始调度的时候，hostip还没绑定上，持续调度之后，有合适的节点就会绑定hostip，然后更新etcd数据
Initialized
pod中的所有初始化容器已经初启动完毕
Ready
pod中的容器可以提供服务了
Unschedulable
不能调度，没有合适的节点
Pod状态的详细说明
CrashLoopBackOff： 容器退出，kubelet正在将它重启
InvalidImageName： 无法解析镜像名称
ImageInspectError： 无法校验镜像
ErrImageNeverPull： 策略禁止拉取镜像
ImagePullBackOff： 正在重试拉取
RegistryUnavailable： 连接不到镜像中心
ErrImagePull： 通用的拉取镜像出错
CreateContainerConfigError： 不能创建kubelet使用的容器配置
CreateContainerError： 创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError： 启动容器失败
PostStartHookError： 执行hook报错
ContainersNotInitialized： 容器没有初始化完毕
ContainersNotReady： 容器没有准备完毕
ContainerCreating： 容器创建中
PodInitializing：pod 初始化中
DockerDaemonNotReady： docker还没有完全启动
NetworkPluginNotReady： 网络插件还没有完全启动
Evicte: pod被驱赶四、总结
Pod在遇到故障之后“重启”的动作Pod在遇到故障之后“重启”的动作
- Always：当容器终止退出后，总是“重启”容器，默认策略
- OnFailure：当容器异常退出（退出状态码非0）时，重启容器
- Never：当容器终止退出，从不“重启”容器。
（注意：k8s中不支持重启Pod资源，只有删除重建，重建）