一、重启策略：Pod在遇到故障之后重启的动作
- 1、always
- 2、never
- 3、onfailure
- - 3.1 非0状态
  - 3.2 为0状态
二、探针
附：pod各种状态解释：
- 1、Pod一直处于Pending状态
- 2、Pod一直处于Waiting 或 ContainerCreating状态
- 3、Pod 一直处于CrashLoopBackOff状态
- 4、Pod处于Error状态
- 5、Pod 处于Terminating或 Unknown状态

一、重启策略：Pod在遇到故障之后重启的动作

1：Always：当容器终止退出后，总是重启容器，默认策略
2：OnFailure：当容器异常退出（退出状态码非0）时，重启容器
3：Never：当容器终止退出，从不重启容器。
（注意：k8s中不支持重启Pod资源，只有删除重建，重建）

1、always

[root@master test]# vim always.yaml
apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3

[root@master test]# kubectl apply -f always.yaml

创建中

运行中

出错了

立即重启

证明重启策略默认是always，总是自动拉取

2、never

[root@master test]# vim never.yaml
apiVersion: v1
kind: Pod
metadata:name: foo01namespace: zy
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Never

[root@master test]# kubectl apply -f never.yaml

这时pod故障后就一直不重启了

3、onfailure

3.1 非0状态

[root@master test]# vim onfailure.yaml
apiVersion: v1
kind: Pod
metadata:name: foo02namespace: zy
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 20; exit 3restartPolicy: OnFailure

[root@master test]# kubectl apply -f onfailure.yaml

3.2 为0状态

[root@master test]# mv onfailure.yaml onfailure0.yaml
[root@master test]# vim onfailure0.yaml
apiVersion: v1
kind: Pod
metadata:name: foo03namespace: zy
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 20; exit 0restartPolicy: OnFailure

[root@master test]# kubectl apply -f onfailure0.yaml

退出后显示的完成，说明正常退出，只是完成了这个动作，并不是错误。

[root@master test]# kubectl delete -f .
pod "foo" deleted
pod "foo01" deleted
pod "foo03" deleted

二、探针

健康检查：又称为探针（Probe）
（注意：）规则可以同时定义
livenessProbe(存活性探针) 如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。
ReadinessProbe(就绪性探针) 如果检查失败，kubernetes会把Pod的IP：port信息从service endpoints中剔除。

Probe支持三种检查方法：
httpGet发送http(的GET)请求，返回200-400范围状态码为成功。
exec执行 shell命令返回状态码是0为成功（例如:/bin/sh -c cat /var/run/nginx.pid）。
tcpSocket 发起TCP Socket建立成功(三次握手的方式建立连接，建立成功，则为健康、否则，则为失败)

1、exec

[root@master test]# vim exec.yaml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-execnamespace: zy
spec:containers:- name: livenessimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5

在配置文件中，您可以看到/Pod具有单个Container ,该period9econds 字段指定Kucaeet应该每5秒执行一次活动性探测。该initialle1sy$conda字股告诉知cbee在执行第一个保影之前应等待5秒。为了执行探测，kubet cat /try/heolthy在容器中执行命令。如果命令成功执行，则返回，并且lubelet认l为Container仍然健康。如果命令返回非零值，则妙火ubelet将杀死Container并重新启动它。

附：pod各种状态解释：

1、Pod一直处于Pending状态

Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl describe pod命令查看到当前Pod的事件，进而判断为什么没有调度)。可能原因:资源不足（集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源);HostPort.已被占用(通常推荐使用Service对外开放服务端口)。

2、Pod一直处于Waiting 或 ContainerCreating状态

首先还是通过 kubectl describe pod命令查看当前Pod的事件。可能的原因有:
1、镜像拉取失败，比如镜像地址配置错误、拉取不了国外镜像源（gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超E(可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。
2、CNI网络错误，一般需要检查CNI网络插件的配置，比如:无法配置Pod 网络、无法分配IP地址。
3、容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数
4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盘坏道（input/output error)。
Pod 一直处于ImagePullBackOff状态
通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。

3、Pod 一直处于CrashLoopBackOff状态

此状态说明容器曾经启动了，但又异常退出。这时可以先查看一下容器的日志。
通过命令kubectl logs 和kubectl logs --previous 可以发下一些容器退出的原因，比如:容器进程退出、健康检查失败退出;此时如果还未发现线索，还而已到容器内执行命令(kubectl exec cassandra - cat /var.log/cassandra/system.loq)来进一步查看退出原因;如果还是没有线索，那就需要SSH登录该Pod所在的Node上，查看Kubelet或者Docker的日志进一步排查。

4、Pod处于Error状态

通常处于Error状态说明Pod启动过程中发生了错误。常见的原因:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制，比如超过了LimitRange等;违反集群的安全策略，比如违反了PodSecurityPolicy.等;容器无法操作集群内的资源，比如开启RDAC后，需要为ServiceAccount配置角色绑定。

5、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

pod重启策略和状态解释相关推荐

K8S---Pod重启策略和状态解释
目录一.重启策略:Pod在遇到故障之后重启的动作 1.1 重启策略设置建议 1.2 always 1.3 never 1.4 onfailure 1.4.1 非0状态 1.4.2 为0 ...
浅析Kubernetes Pod重启策略和健康检查
使用Kubernetes的主要好处之一是它具有管理和维护集群中容器的能力,几乎可以提供服务零停机时间的保障.在创建一个Pod资源后,Kubernetes会为它选择worker节点,然后将其调度到节点上 ...
Kubernetes(k8s) pod 重启策略
目录一.重启策略 1.在k8s集群中有如下三种重启策略 2.Always 3.Never 4.OnFailure 4.1.非0状态 4.2.为0状态二.Pod状态 1.Pod 一直处 ...
【云原生--Kubernetes】Pod重启策略
文章目录一. 重启策略二. Always 三. Never 四. OnFailure 4.1 非0状态 4.2 为0状态五. Pod状态引言:在k8s集群中,当某个pod资源需要重启时,我们只 ...
【K8S系列】Pod重启策略及重启可能原因
目录 1 重启策略 1.1 Always 1.2 OnFailure 1.3 Nerver 1.4 yaml示例 2 Pod常见异常状态 2.1 Pending状态 2.2 Waiting/Con ...
K8S系列：Pod重启策略restartPolicy（Always、OnFailure、Never）
restartPolicy apiVersion: v1 kind: Pod metadata:name: nginx-pod spec:restartPolicy: Alwayscontainers ...
k8s pod重启策略：Always、OnFailure、Never配置示例
k8s 详解 pod 生命周期容器探测(live and ready) 钩子函数 pod的重启策略
pause 容器, 每个pod的都有的根容器,评估pod 的健康状态,设置ip地址,ip+端口可以访问到指定的容器 pod pod 之间采用 flannel 通信 pod 定义 yaml 资源清单一 ...
k8s教程（pod篇）-生命周期、重启策略及健康检查
文章目录 01 引言 02 pod生命周期 03 pod重启策略 04 pod健康检查和服务可用性检查 4.1 方式一:ExecAction 4.2 方式二:TCPSocketAction 4.3 方 ...

pod重启策略和状态解释