健康检查回调hook

Posted 2021-09-03 givenchy_yzl

健康检查

怎样保证pod中的容器正常启动？
1、检查pod中容器是否能够正常启动
pod中所有容器的status=Running时，Pod的状态才会是Running状态。
当存活性探针检测失败的时候，kebulet会删除容器，重新启动一个新的容器。继续检查。

2、怎样保证pod中容器能够正常对外提供服务？
只有容器启动了并且能够正常对外提供服务了，才能放到负载均衡上供给用户访问

提到健康检查就不得不提探针了，他们是做检查的主要劳动力

容器探针

一般情况下存活性检测使用exec，就绪性检测使用tcpSocket,httpGet
如欲了解如何设置存活态、就绪态和启动探针的进一步细节，可以参阅 配置存活态、就绪态和启动探针。
针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：

livenessProbe：指示容器是否存活。如果存活态探测失败，则 kubelet 会杀死容器， 并且将容器重启。如果容器不提供存活探针， 则默认状态为 Success。

readinessProbe：指示容器是否准备好对外提供服务。如果就绪态探测成功，将容器加入负载均衡，如果就绪态探测失败，将容器踢出负载均衡 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。

startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

容器探针参数：

写在配置文件中，放在探针下面即可自定义探针
initialDelaySeconds：检查开始执行的时间，以容器启动完成为起点计算
periodSeconds：检查执行的周期，默认为10秒，最小为1秒
timeoutSeconds：检查超时的时间，默认为1秒，最小为1秒
successThreshold：从上次检查失败后重新认定检查成功的检查次数阈值（必须是连续成功），默认为1
failureThreshold：从上次检查成功后认定检查失败的检查次数阈值（必须是连续失败），默认为1

示例：

  livenessProbe:
    exec:
      command:
        - "/bin/sh"
        - "-c"
        - "cat /root/test/manage.py"
    initialDelaySeconds: 0
    periodSeconds: 3
    timeoutSeconds: 1
    successThreshold: 3
    failureThreshold: 3

Probe 是由 kubelet 对容器执行的定期诊断。 要执行诊断，kubelet 调用由容器实现的 Handler （处理程序）。有三种类型的处理程序：

ExecAction： 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

TCPSocketAction： 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。

HTTPGetAction： 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

Success（成功）：容器通过了诊断。
Failure（失败）：容器未通过诊断。
Unknown（未知）：诊断失败，因此不会采取任何行动。

存活性探针

何时该使用存活态探针?

FEATURE STATE: Kubernetes v1.0 [stable]
如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针; kubelet 将根据 Pod 的restartPolicy 自动执行修复操作。
如果你希望容器在探测失败时被杀死并重新启动，那么请指定一个存活态探针， 并指定restartPolicy 为 "Always"（一直重启） 或 "OnFailure"（故障重启）。

关于存活性探测小实验
#exec方式

vim liveness.yaml
kind: Service
apiVersion: v1
metadata:
  name: name-mysql
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: name-mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: alvinos/django:v1
          livenessProbe:
            exec:
              command:
                - "/bin/sh"
                - "-c"
                - "cat /root/test/manage.py"

kubectl apply -f liveness.yaml
kubectl describe pod name-mysql
找到liveness这一行，有以下参数

delay=0s 	：容器启动多久开始探测
timeout=1s 	：容器探测超时时间
period=10s 	：探测的频率
success=1  	：探测成功多少次为成功
failure=3	：探测失败多少次为失败

#httpGet检查

kind: Service
apiVersion: v1
metadata:
  name: name-mysql
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: name-mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: alvinos/django:v1
          livenessProbe:
            httpGet:
              port: 80
              path: /index

kubectl apply -f liveness.yaml
kubectl describe pod name-mysql

#TcpSocket 相当于 ping，检测端口是否正常

---
kind: Service
apiVersion: v1
metadata:
  name: name-mysql
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: name-mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: alvinos/django:v1
          livenessProbe:
            tcpSocket: 
              port: 80 

kubectl apply -f liveness.yaml
kubectl describe pod name-mysql

就绪性探针

何时该使用就绪态探针?

FEATURE STATE: Kubernetes v1.0 [stable]
如果要仅在探测成功时才开始向 Pod 发送请求流量，请指定就绪态探针。 在这种情况下，就绪态探针可能与存活态探针相同，但是规约中的就绪态探针的存在意味着 Pod 将在启动阶段不接收任何数据，并且只有在探针探测成功后才开始接收数据。
如果你的容器需要加载大规模的数据、配置文件或者在启动期间执行迁移操作，可以添加一个 就绪态探针。
如果你希望容器能够自行进入维护状态，也可以指定一个就绪态探针，检查某个特定于 就绪态的因此不同于存活态探测的端点。

说明：
请注意，如果你只是想在 Pod 被删除时能够排空请求，则不一定需要使用就绪态探针； 在删除 Pod 时，Pod 会自动将自身置于未就绪状态，无论就绪态探针是否存在。 等待 Pod 中的容器停止期间，Pod 会一直处于未就绪状态。

启动探针

何时该使用启动探针？

FEATURE STATE: Kubernetes v1.18 [beta]
对于所包含的容器需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的。 你不再需要配置一个较长的存活态探测时间间隔，只需要设置另一个独立的配置选定， 对启动期间的容器执行探测，从而允许使用远远超出存活态时间间隔所允许的时长。

如果你的容器启动时间通常超出 initialDelaySeconds + failureThreshold × periodSeconds 总值，你应该设置一个启动探测，对存活态探针所使用的同一端点执行检查。 periodSeconds 的默认值是 10 秒。你应该将其 failureThreshold 设置得足够高， 以便容器有充足的时间完成启动，并且避免更改存活态探针所使用的默认值。 这一设置有助于减少死锁状况的发生

回调hook

Kubernetes 为我们的容器提供了生命周期钩子的，就是我们说的Pod Hook，Pod Hook 是由 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。我们可以同时为 Pod 中的所有容器都配置 hook。Kubernetes 为我们提供了两种钩子函数：

PostStart（启动回调钩子）：这个钩子在容器创建后立即执行。主要用于资源部署、环境准备等。不过需要注意的是如果钩子花费太长时间以至于不能运行或者挂起， 容器将不能达到running状态。

PreStop（结束回调钩子）：这个钩子在容器终止之前立即被调用。它是阻塞的，意味着它是同步的， 所以它必须在删除容器的调用发出之前完成。主要用于优雅关闭应用程序、通知其他系统等。如果钩子在执行期间挂起， Pod阶段将停留在running状态并且永不会达到failed状态。

如果PostStart或者PreStop钩子失败， 它会杀死容器。所以我们应该让钩子函数尽可能的轻量。当然有些情况下，长时间运行命令是合理的， 比如在停止容器之前预先保存状态。

apiVersion: v1
kind: Pod
metadata:
  name: hook-demo1
spec:
  containers:
    - name: hook-demo1
      image: nginx
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]