这篇文章给大家介绍如何理解Kubernetes 探针,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
配置 readiness、liveness 和 startup 探针可以处理不健康的 Pod,小编介绍了三种类型的探针、最佳实践和有关工具,以检测可能存在的配置问题。
分布式系统和微服务体系结构的挑战之一是自动检测不正常的应用程序,并将请求(request)重新路由到其他可用系统,恢复损坏的组件。健康检查是应对该挑战的一种可靠方法。使用 Kubernetes,可以通过探针配置运行状况检查,以确定每个 Pod 的状态。
同样的,这也是 Kubernetes 探针用来定义容器何时准备接受流量,以及何时重新启动容器的方式。从 Kubernetes v1.16 开始,已经支持三种类型的探针。在文中将介绍这三种类型的探针、最佳实践和有关工具,以检测可能存在的配置问题。
Kubernetes 探针
Kubernetes 版本小于 v1.15 时支持 readiness 和 liveness 探针,在 v1.16 中添加了 startup 探针作为 Alpha 功能,并在 v1.18 中升级为 Beta。
initialDelaySeconds
:启动 liveness、readiness 探针前要等待的秒数。periodSeconds
:检查探针的频率。timeoutSeconds
:将探针标记为超时(未通过运行状况检查)之前的秒数。successThreshold
:探针需要通过的最小连续成功检查数量。failureThreshold
:将探针标记为失败之前的重试次数。对于 liveness 探针,这将导致 Pod 重新启动。对于 readiness 探针,将标记 Pod 为未就绪(unready)。initialDelaySeconds
来确定 readiness 探测在准备就绪前要等待多长时间。
假设有一个偶尔需要下载大量数据的应用程序,由于 initialDelaySeconds
是一个静态数字,因此该应用程序即使不需要那么长的初始化等待时间,我们也必须设置最保守的等待时间。通过 startup 探针,我们可以配置 failureThreshold
和 periodSeconds
来解决该问题,例如设置 failureThreshold
为 15,periodSeconds
为 5,这意味着应用程序在失败之前会有 10x5=75s 的启动时间。
配置探针
现在我们了解了不同类型的探针,下面是配置每种探针的三种不同方式。
/healthz
endpoint 的 Express server)。HTTP 探针包含其他额外参数:
host
:要连接的主机名(默认值:pod 的 IP)。scheme
:HTTP(默认)或 HTTPS。path
:HTTP/S 服务器上的路径 。httpHeaders
:自定义标头(如果需要标头用于身份验证、CORS 设置等) 。port
:访问服务器的端口名称或端口号。最佳实践
虽然说探针的确切参数和使用方法取决于应用程序,但也有一些常用的最佳实践:
/healthz
),但能将 failureThreshold
设置得比其他探针更高,以拥有更长的启动时间,相对于 liveness 和 readiness 而言,设置的失败时间会更合理。简而言之,定义明确的探针通常会带来更好的弹性和可用性。确保观察启动时间和系统行为,在应用程序更改时调整探针设置。
工具
最后,鉴于 Kubernetes 探针的重要性,我们可以使用 Kubernetes 资源分析工具来检测缺失的探针。这些工具可以在现有集群上运行,也可以置入 CI/CD 流程中,可以在没有正确配置资源的情况下自动拒绝工作负载。
关于如何理解Kubernetes 探针就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。