问题描述
readinessProbe:指示容器是否准备好响应请求。如果就绪探测失败,端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态为失败。如果 Container 不提供就绪探测,则默认状态为 Success
如果就绪探测失败(并且从端点删除了 Pod 的 IP 地址),接下来会发生什么? 会再次检查 Pod 的就绪探测条件吗?它会在初始延迟后再次检查吗? Pod 的 IP 地址是否有可能再次添加到端点(如果就绪探测失败后 Pod 自我修复)?如果 Pod 被治愈,它会再次收到流量吗?
解决方法
会再次检查 Pod 的就绪概率条件吗?
是的,会根据您设置的阈值再次检查条件。
在每个periodSeconds
配置就绪时都会检查 POD。
它会在初始延迟后再次检查吗?
它只会在初始延迟后检查。当 POD 正在初始化或启动时,初始延迟就会出现。就绪检查将等待配置的时间,然后它将开始在每个时间间隔检查 POD 的就绪情况,假设每 5
秒或 10
秒取决于 periodSeconds
的配置。
是否有机会将 pod 的 ip 地址再次添加到端点(如果 Pod 在就绪探测失败后自愈)?
是的,如果获得自动修复意味着,successThreshold
设置为 1
次,如果 POD 给 200 一次,它将被标记为修复并且正在运行的 pod 在这种情况下 POD 将再次获得流量。
如果 pod 被治愈,它会再次收到流量吗?
是的
例如:
readinessProbe:
httpGet:
path: /k8/readiness
port: 9595
initialDelaySeconds: 25
periodSeconds: 8
timeoutSeconds: 10
successThreshold: 1
failureThreshold: 30
livenessProbe:
httpGet:
path: /k8/liveness
port: 9595
initialDelaySeconds: 30
periodSeconds: 8
timeoutSeconds: 10
successThreshold: 1
failureThreshold: 30
就绪和活跃探测器将检查配置中提到的 HTTP 端点上的状态。
initialDelaySeconds :它只会在您的 POD 初始化或由于重启或任何原因再次启动时出现。所以当 POD 开始准备就绪时,直到 30 秒才会检查服务状态。
30 seconds
后,它将尝试检查端点上的状态。如果成功的 POD 将处于 ready 状态来处理流量,否则它会再试一次 periodSeconds
所以在 8 秒后它会再次尝试,如果我们200 response
POD 将就绪,否则将在 8 秒后尝试。
timeoutSeconds :单跳或请求将等待从服务获得响应的时间量,否则标记为检查失败。
failureThreshold :此 POD 将根据配置活跃度或准备情况启动或更改为 Not Ready 状态后失败检查的最大次数。
successThreshold :成功阈值是指如果单个请求从服务 POD 获得成功响应的状态更改为 Ready。
如果连续 30 failureThreshold
发生,那么只有 POD 会被标记为 Not ready 如果在 single {{1} } 发生 POD 将被标记为 Ready 相同的活性。
注意:以上示例仅供参考,在实际生产场景中不适用。
,在与往常相同的 periodSeconds
延迟后再次检查它,然后当它连续经过 successThreshold
次时,它将再次被视为就绪,并具有所有正常行为。