一个 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就会失败。
相关参考
- K8S官方文档 除了 httpGet 和 exec，还有基于 TCP 端口和 gRPC 的探测方式
- https://support.huaweicloud.com/devg-cci/cci_05_0026.html