pod重启策略和状态解释

一、重启策略：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: busybox
    image: busybox
    args:
    - /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: foo01
  namespace: zy
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
  restartPolicy: 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: foo02
  namespace: zy
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 20; exit 3
  restartPolicy: 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: foo03
  namespace: zy
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 20; exit 0
  restartPolicy: 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: liveness
  name: liveness-exec
  namespace: zy
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 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