K8S 之就绪探针(Readiness Probe)

一个 Pod 创建之后,Service 马上就能选择它,并且请求也有可能转发到这个 Pod。然而,Pod 的启动很可能是需要时间的,在启动、加载、预热的过程中,如果有请求转发进来,这个请求很可能会失败。

K8S 处理这个问题的办法是引入了就绪探针(Readiness Probe),readiness 这个词的词根不是“read”,而是“ready”,就是说这个 Pod ready 了没有。如果没 ready,请求就不转发给它;ready 之后,就可以转发给它。

综合运用 Liveness Probe 和 Readiness Probe,可以让服务的自愈、启动、重启、升级更得心应手。

就绪探针怎么判断 Pod 是否就绪?和存活探针(Liveness Probe)一样,常用的有 httpGet 和 exec 两种方式。

httpGet

顾名思义,K8S 通过发送 HTTP GET 请求,判断 Pod 是否就绪。若该请求收到 HTTP 2xx~3xx 状态码均判断为成功。下面是例子:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: container-0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
            scheme: HTTP           # 还可以是HTTPS
          initialDelaySeconds: 60  # 容器启动后要等待多少秒后探针才开始,默认是0秒,最小值是0
          timeoutSeconds: 10       # 探测超时的阈值。默认值是1秒。最小值是1
          periodSeconds: 30        # 每次执行探测的时间间隔(单位是秒)。默认是10秒。最小值 1
          successThreshold: 1      # 视为成功的最小连续成功次数。默认值是1。存活和启动探测的该值必须是1。最小值是1
          failureThreshold: 3      # 视为失败的最小连续失败次数。默认值是3。最小值是1

exec

还可以通过 linux 命令的方式来判断,若 error code = 0,则表明命令正常。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

上面这个例子中,每 5s 会cat /tmp/healthy一次,30s 后该文件被删除,cat /tmp/healthy就会失败。

相关参考

  1. K8S官方文档 除了 httpGet 和 exec,还有基于 TCP 端口和 gRPC 的探测方式
  2. https://support.huaweicloud.com/devg-cci/cci_05_0026.html

发表评论

解决 : *
99 + 70 =