3-Pod探针

探针概述

• 在yaml文件中的pod.spec.containers字段下配置
• Kubernetes 探针是用于检测容器健康状况的机制，主要有三种类型：
• 探针是在应用容器中执行的

存活探针(Liveness Probe)

• 检测容器是否还在运行，如果探测失败，kubelet会杀死容器，容器会重启（受重启策略影响）
• 可以配置连续多少次失败才记为不健康
• 如果没有配置LivenessProbe，则默认容器启动为通过Success状态

就绪探针(Readiness Probe)

• 就绪探针的作用是用于判断 Pod 是否可以接收流量。决定是否加入 Service 的 Endpoint（负载均衡池），只有 Ready 状态的 Pod 才会被访问
• 如果就绪探测失败，则系统自动将其从Service的Endpoint列表中去除，后续再把恢复到Ready状态的Pod加回Endpoint列表
• 存活探针失败会重启容器，而就绪探针失败只会隔离流量，不会重启容器

启动探针(Startup Probe)

• 使用启动探针判断容器中的应用是否已经启动
• 如果三种探针同时存在，会先执行startupProbe探针，如果探测失败，kubelet会杀掉该容器，并根据容器的重启策略做相应的处理。
• 只有启动探针成功执行，才会执行另外两种探针

说明

• 启动探针通过 宽松的失败阈值（failureThreshold） 和 较长的检测间隔（periodSeconds），为慢启动应用争取足够的启动时间。
  关键逻辑：
• 最大允许启动时间 = initialDelaySeconds + failureThreshold × periodSeconds
• 对于启动比较慢的容器，使用启动探针可以，避免它们在启动运行之前就被杀掉
• 在readinessProbe中可以不用配置initialDelaySeconds，不配置默认pod刚启动，就开始进行readinessProbe探测。因为readinessProbe失败并不会重启pod，即使因启动未完成导致短暂失败也无风险
• 只有startupProbe、livenessProbe失败才会重启pod。

探针的检查方式

• LivenessProbe、ReadinessProbey和startupProbe都可以采用以下三种方式检查

exec

• 在容器内执行命令，如果命令退出的状态码为0，则探测成功

tcpSocket

• 与容器的IP和端口建立TCP连接，如果成功建立连接，则探测成功

httpGet

• 通过容器的IP和端口，在指定路径上调用HTTP GET请求。如果响应的200<=状态码<=400，则认为诊断成功

探针配置参数

• 所有探针都支持以下通用配置参数
  • initialDelaySeconds：容器启动后要等待多少秒后才开始检测，默认是 0 秒。
  • periodSeconds：执行探测的频率（单位是秒）。默认是 10 秒。
  • timeoutSeconds：探测超时后等待多少秒。默认 1 秒。当超时发生时，kubelet会重启容器。
  • successThreshold：探测连续成功多少次才认为成功（默认 1）
  • failureThreshold：探测连续失败多少次才认为失败（默认 3）

LivenessProbe示例

• 以ExecAction方式实现LivenessProbe探针
• 通过执行cat /tmp/healthy命令来判断容器是否正常

spec:
  containers:
  - name: probe-test-nginx
    image: nginx:latest
    imagePullPolicy: Never
    ports:
    - containerPort: 80
    livenessProbe:
      exec:
        command: ["cat", "/tmp/healthy"] 
      initiaDelaySeconds: 10      # 告诉 kubelet 在执行第一次探测前应该等待 5 秒
      periodSeconds: 5            # 每5秒检查一次

• 以TCPSocketAction方式实现LivenessProbe探针
• 通过与容器内的localhost:80建立TCP连接进行健康检查

livenessProbe:
  tcpSocket:
    port: 80
  initialDelaySeconds: 30
  timeoutSeconds: 1

• 以HttpGetAction方式实现LivenessProbe探针
• kubelet定时发送HTTP请求到localhost:80/_status/healthz来进行容器应用的健康检查

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSecond: 5

lifecycle（生命周期钩子）

• Lifecycle 指的是 Pod 及其容器的生命周期管理机制，它允许在容器的特定生命周期阶段（如启动后或终止前）执行自定义操作。它允许你在容器内部执行命令或脚本，以便在关键时间点完成一些初始化或清理工作。
• lifecycle有两种钩子函数：PostStart、PreStop
• 触发方式有两种
  • exec ，在容器内执行命令
  • httpGet，发送 HTTP 请求

PostStart

• PostStart：容器启动后立即执行（用于初始化配置、预热缓存等）

PostStart 典型用途

• 初始化配置文件（如生成动态配置）。
• 预热缓存（如加载数据库数据到内存）。
• 注册服务（如向服务发现系统注册 Pod）。

PreStop

• PreStop：在容器被终止前的任务，用于优雅关闭应用程序、通知其他系统等等。
• Kubernetes 默认给 PreStop 30 秒执行时间，超时后容器会被强制终止。可通过 spec.terminationGracePeriodSeconds 调整超时时间

PreStop使用说明

• 当容器启动时，Kubernetes 会 同时 做两件事：启动容器的主进程（即 ENTRYPOINT 或 CMD 定义的命令）。触发 PostStart 钩子（如果配置了）由于这两者是并行执行的，PostStart 可能会在主进程启动之后、甚至主进程已经部分运行时才执行。
• 如果初始化是必须的，更可靠的做法是直接写在容器的启动脚本中
• 对于复杂的初始化任务（如下载依赖、等待数据库），可以用 Init 容器 替代 PostStart

PreStop 典型用途

• 优雅关闭应用（等待请求完成，避免强制终止）。
• 保存状态（如将内存数据持久化到磁盘）。
• 通知其他服务（如从负载均衡器注销）。

PostStart和PreStop示例

• 容器启动后，会执行 echo 命令，写入日志文件
• 在 Pod 被终止前，访问/shutdown路径

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  terminationGracePeriodSeconds: 45
  containers:
  - name: web
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Init complete' > /tmp/init.log"]
      preStop:
        httpGet:
          path: /shutdown
          port: 80
          scheme: HTTP

readinessGates

• 通过Pod Readiness Gates机制， 用户可以将自定义的ReadinessProbe探测方式设置在Pod上， 辅助Kubernetes设置Pod何时达到服务可用状态（Ready）
• Pod的Readiness Gates在Pod定义中的ReadinessGate字段进行设置。pod.spec.readinessGates

对比传统Readiness Probe

• 传统 Readiness Probe：由 Kubelet 在节点上执行。检查容器内部状态（HTTP/TCP/Exec）。仅针对单个容器
• Readiness Gates：由外部控制器评估。可以检查集群级或外部系统状态。作用于整个 Pod 级别

应用场景

• 想象一个真实场景：您的应用Pod启动了，容器内部已经就绪（通过readiness probe），但此时：云服务商的负载均衡器(LB)还在配置中，比如：网络规则尚未完全生效、安全组规则未更新完成。如果没有Readiness Gates，Pod会立即被标记为就绪，Service会把流量引向这个Pod，但此时外部用户其实还无法真正访问

示例

• pod中设置了一个类型为load-balancer-ready的Readiness Gate，默认Condition的状态为False
• 当负载均衡器配置完成后，会将自定义Condition的状态（status）更新为True
• Kubernetes将在判断全部readinessGates条件都为True时，才设置Pod为服务可用状态（Ready为True）

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  readinessGates:
    - conditionType: "www.example.com/load-balancer-ready"  # 必须符合域名格式，“域名前缀/条件名称”
  containers:
  - name: my-container
    image: nginx
    readinessProbe:
      httpGet:
        path: /health
        port: 80

• 负载均衡器配置完成前后，可以通过kubectl describe看到类似的输出

status:
  conditions:
    - type: "security.company.com/auth-service-synced"
      status: "True" # 负载均衡器将默认值False更新为True
      lastTransitionTime: "2023-05-01T14:30:00Z"