《Kubernetes in action》探针

保持Pod健康

存活探针

存活探针: Kubemetes 可以通过存活探针 (liveness probe) 检查容器是否还在运行。 可以为 pod 中的每个容器单独指定存活探针。 如果探测失败， Kubenetes 将定期执行探针并重新启动容器。

Kubemetes 有以下三种探测容器的机制：

• HTTPGET探针对容器的 IP 地址（你指定的端口和路径）执行 HTTP GET 请求。如果探测器收到响应，并且响应状态码不代表错误（换句话说，如果HTTP响应状态码是2xx或3xx), 则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应，那么探测就被认为是失败的，容器将被重新启动。
• TCP套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。
• Exec探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是 o, 则探测成功。所有其他状态码都被认为失败。

apiVersion: v1 
kind: Pod 
metadata: 
  name: kubia-liveness 
spec: 
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080

在第五个请求之后，给每个请求返回HTTP状态码500(Internal Server Error)，你的应用程序将正确处理前五个客户端请求，之后每个请求都会返回错误。多亏了存活探针，应用在这个时候会重启，使其能够再次正确处理客户端请求。

Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  26m                  default-scheduler  Successfully assigned default/kubia-liveness to kmaster
  Normal   Created    22m (x3 over 25m)    kubelet, kmaster   Created container kubia
  Normal   Started    22m (x3 over 25m)    kubelet, kmaster   Started container kubia
  Normal   Killing    20m (x3 over 24m)    kubelet, kmaster   Container kubia failed liveness probe, will be restarted
  Normal   Pulled     20m (x4 over 26m)    kubelet, kmaster   Successfully pulled image "luksa/kubia-unhealthy"
  Warning  Unhealthy  15m (x16 over 25m)   kubelet, kmaster   Liveness probe failed: HTTP probe failed with statuscode: 500
  Warning  BackOff    6m2s (x24 over 12m)  kubelet, kmaster   Back-off restarting failed container
  Normal   Pulling    35s (x10 over 26m)   kubelet, kmaster   Pulling image "luksa/kubia-unhealthy"

你想看到的是前一个容器的日志，而不是当前容器的。可以通过添加--previous: kubectl logs mypod --previous

• delay=0s 在容器启动后立即开始探测
• timeout=1s 因此容器必须在1秒内进行响应， 不然这次探测记作失败。
• period=10s 每10秒探测一次容器
• success=1
• failure=3 探测连续三次失败(#fa辽ure= 3)后重启容器
• initialDelaySeconds: 15 kubernetes会在第一次探测前等待15s

创建有效的存活探针

存活探针应该检查什么:

简易的存活探针仅仅检查了服务器是否响应。 虽然这看起来可能过于简单， 但 即使是这样的存活探针也可以创造奇迹，因为如果容器内运行的web服务器停止响应HTTP请求， 它将重启容器。 与没有存活探针相比， 这是一项重大改进，而且在大多数情况下可能已足够。

保持探针轻量:

存活探针不应消耗太多的计算资源， 并且运行不应该花太长时间 。 默认情况下，探测器执行的频率相对较高， 必须在一秒之内执行完毕。 一个过重的探针会大大减慢你的容器运行。 在本书的后面， 还将学习如何限制容器可用的CPU时间。 探针的CPU时间计入容器的CPU时间配额， 因此使用重量级的存活探针将减少主应用程序进程可用的CPU时间。

无须在探针中实现重试循环:

你已经看到， 探针的失败阙值是可配置的， 并且通常在容器被终止之前探针必须失败多次。 但即使你将失败阙值设置为1 , Kubemetes为了确认一次探测的失败，会尝试若干次。

就绪探针

概念

就绪探测器会定期调用，并确定特定的 pod 是否接收客户端请求 当容器的准备就绪探测返回成功时，表示容器己准备好接收请求。
这个准备就绪的概念显然是每个容器特有的东西 Kuberne es 只能检查在容器中运行的应用程序是否响应 个简单的 GET／请求，或者它可以响应特定的 URL路径（该 URL 导致应用程序执行 系列检查以确定它是否准备就绪）

类型

像存活探针 样，就绪探针有三种类型：

• Exec 探针，执行进程的地方。容器的状态由进程的退出状态代码确定
• HTTP GET 探针，向容器发送 HTTP GET 请求，通过响应的 HTTP 状态代码判断容器是否准备好
• TCP socket 探针，它打开 一个TCP 连接到容器的指定端口。如果连接己建立，
  则认为容器己准备就绪

就绪探的操作

启动容器时，可以为 bernetes 配置一个等待时间，经过等待时间后才可以执行第一次准备就绪检查 之后，它会周期性地调用探针，并根据就绪探针的结果采取行动。如果某个 po 报告它尚未准备就绪，则会从该服务中删除该 pod 。如果再次准备就绪，则重新添加 pod

pod中添加就绪探针

apiVersion: apps/v1 
kind: ReplicationController
spec:
  ...
  template:
    spec: 
      containers:
      - name: kubia
      image: luksa/kubia
      readinessProbe:
        exec: 
          command: 
          - ls 
          - /var/ready
---
readinessProbe:
  httpGet:
    port: http
    path: /readiness
  initialDelaySeconds: 20
  periodSeconds: 10
---
readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
    periodSeconds: 10
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

就绪探针的实际作用

务必定义就绪探针

在总结本节之前， 有两个关于就绪探针的要点， 需要强调。 首先， 如果没有将就绪探针添加到 pod 中， 它们几乎会立即成为服务端点。 如果应用程序需要很长时间才能开始监听传入连接， 则在服务启动但尚未准备好接收传入连接时， 客户端请求将被转发到该 pod。 因此， 客户端会看到 “连接被拒绝 ” 类型的错误。提示 应该始终定义一 个就绪探针， 即使它只是向基准 URL 发送 HTTP 请求一样简单。

不要将停止 pod 的逻辑纳入就绪探针中

需要提及的另 一件事情涉及 pod 生命周期结束 (pod 关闭）， 并且也与客户端出现连错误相关。当一个容器关闭时， 运行在其中的应用程序通常会在收到终止信号后立即停止接收连接。 因此， 可能认为只要启动关机程序 ， 就需要让就绪探针返回失败， 以确保从所有服务中删除该 pod。

另类就绪探针（服务依赖）

spec:
  replicas: 2
  selector:
    matchLabels:
      app: alerting-executor
  template:
    metadata:
      labels:
        app: alerting-executor
    spec:
      initContainers:
      - name: wait-mysql
        image: busybox:1.28.4
        imagePullPolicy: IfNotPresent
        command: ['sh', '-c', 'until nc -z openpitrix-db.openpitrix-system.svc 3306; do echo "waiting for mysql"; sleep 2; done;']
      - name: wait-redis
        image: busybox:1.28.4
        imagePullPolicy: IfNotPresent
        command: ['sh', '-c', 'until nc -z redis.kubesphere-system.svc 6379; do echo "waiting for redis"; sleep 2; done;']
      - name: wait-etcd
        image: busybox:1.28.4
        imagePullPolicy: IfNotPresent
        command: ['sh', '-c', 'until nc -z openpitrix-etcd.openpitrix-system.svc 2379; do echo "waiting for etcd"; sleep 2; done;']
      containers:

参考博客

配置pod和容器之—配置pod的liveness探针和readiness探针