K8s中Pod生命周期和重启策略

这周项目组提到了POD 的健康检查，自己在春节之中刚好度过，现在认真复习一下

复习以下《K8s权威指南》中第三章节深入理解pod中的关于POD 声明周期和重启策略的内容

一、POD状态：

1）Pending

Api Server 已经创建这个POD，但在POD 内还有一个或者多个容器镜像没有创建

2）Runing

POD内所有容器已经创建，但是至少有一个容器处于运行状态、正在启动状态或者重启状态

3）Successed

Pod 内所有容器均成功执行后退出，且不会再重启

4）Failed

Pod 内所有容器都退出，但是至少有一个容器为退出状态

5）Unknown

由于网络原因无法获得pod状态，可能是因为网络不通畅

二、重启策略：

当某个容器退出或者健康检查失败的时候会触发重启策略

1）Always

当容器失效的时候，kubeket 会自动重启这个容器

2）OnFailure

当容器退出状态码不为0的时候，才会启动重启策略

3）Never

不论状态怎么样都不会重启

我尝试使用Nerver，和OnFailure，但是并不会成功，好像k8s只支持Always

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      restartPolicy: Never
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

K8s重启的时间间隔 2n，最大延迟是5min

一般RC和Daemonset必须是Always，Deployment 经过实践也必须是Always

Job 可以是Onfailure 或者Never

kubelet 在pod 失效的时候自动重启，不论重启策略设置为什么也不会对pod进行健康检查 

三、POD 健康检查和服务可用性检测

K8s 健康检查有三种探针

LivenessProbe、ReadinessProbe以及StartupProbe

其中最主要的是LivenessProbe、ReadinessProbe

1）LivenessProbe 探针：

用于判断这个容器是否存活，如果容器不健康，那么会杀掉这个容器，然后执行相应的策略。如果不设置策略就一直为true。

2）ReadinessProbe 探针：

用于判断容器是否是ready 状态，达到Ready状态的Pod 才会收到请求，对于被Service管理的POD，Service和POD Endpoint 的关联关系也将基于POD是否ready 来进行设置，如果ready状态变为false，则从后端Service 的Endpoint中去掉，后续恢复ready会再加到Endpoint列表中，这样就会保证service 被访问的时候不会被转到不可以用的service中，readinessProbe 也是定期执行的，存在于pod的整个声明周期中。

3）StartProbe探针

有一些程序启动比较慢，比如启动时候需要加载初始化数据，或者网络访问比较慢，可以使用这个探针。

以上探针有三种实现方式：

1）execAction

内部执行一个命令，看容器是否存活，如果exit 是0代表存活

我自认为的常用方案

1、kill 0 进程号，通过信号判断进程是否存活

2、看文件是否有锁

2）TCPSocketAction

通过容器ip地址和端口号进行tcp检测，如果tcp连接connect 成功就是健康

3）HTTPGetAction

通过http请求，如果返回码是200~400 就是健康

探针参数：

initialDelaySeconds

容器启动后进行首次健康检查的等待时间

timeoutSeconds

健康检查请求后等待超时的响应时间

failurethreshold(threshold---门槛; 门口; 阈; 界; 起始点; 开端; 起点; 入门)

表示探针的最大失败次数，如果达到了最大的失败次数，
在存活性探针的情况，容器将重新启动。

periodSeconds:

表示多久进行一次探测，默认是10S，最小值是1

四、测试探针

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: xxxx
        ports:
        - containerPort: 80
        readinessProbe:
          enabled: true
          httpGet:
            path: /health
            port: 9411
          initialDelaySeconds: 30
          timeoutSeconds: 35
          periodSeconds: 30
          successThreshold: 1
          failureThreshold: 3

我们发现在经过initialDelaySeconds 后容器陆续启动

 容器启动