9

readinessProbe：指示容器是否准备好响应请求。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态是失败。如果 Container 不提供就绪探测，则默认状态为 Success

如果就绪探测失败（并且 Pod 的 IP 地址从端点中删除），接下来会发生什么？是否会再次检查 Pod 的就绪探测条件？它会在初始延迟后再次检查吗？Pod 的 IP 地址是否有可能再次添加到端点（如果 Pod 在就绪探测失败后自我修复）？如果 Pod 痊愈了，它会再次接收流量吗？

4

2 回答 2

7

会再次检查吊舱的就绪概率条件吗？

是的，将根据您设置的阈值再次检查条件。

在每个periodSeconds配置中，都会检查 POD 的准备情况。

它会在最初的延迟后再次检查吗？

它将仅在初始延迟后检查。POD 初始化或启动时会出现初始延迟。就绪检查将等待配置的时间，然后在每个时间间隔开始检查 POD 的就绪情况，假设每一5秒或10几秒取决于periodSeconds.

是否有机会再次将 Pod 的 IP 地址添加到端点（如果在就绪探测失败后 Pod 自愈）？

是的，如果得到自动修复意味着，如果 POD 给出 200 一次，它将被标记为修复并且正在运行的 PodsuccessThreshold设置为时间，在这种情况下，POD 将再次获得流量。1

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 将处于就绪状态以处理流量，否则它将尝试另一次periodSeconds，因此在8秒后它将再次尝试，如果我们将200 responsePOD 将就绪，否则将在8秒后尝试。

timeoutSeconds：单跳或请求将等待从服务获得响应的时间量，否则标记为检查失败。

failureThreshold：此 POD 启动后失败检查的最大次数，或根据配置的活跃度或准备情况更改为未就绪状态。

successThreshold：成功阈值表示单个请求是否从服务 POD 状态获得成功响应时更改为Ready。

如果连续发生30 failureThreshold次，则只有 POD 将被标记为未准备好，如果在单个 successThreshold发生之间，POD 将被标记为准备就绪，与活跃度相同。

注意：以上示例仅供参考，不能用于实际生产场景。

阅读更多：https ://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

于 2021-06-14T03:47:25.587 回答
3

在与往常相同的periodSeconds延迟后再次检查它，然后当它successThreshold连续通过时间时，它将再次被视为就绪，并具有所有正常行为。

于 2021-06-14T03:24:35.530 回答