Kubernetes 探针详解！-低调大师

Kubernetes 探针详解！

2021-01-04 611

来参与2020年CNCF中国云原生调查

问卷链接（https://www.wjx.cn/jq/97146486.aspx）

配置 readiness、liveness 和 startup 探针可以处理不健康的 Pod，本文介绍了三种类型的探针、最佳实践和有关工具，以检测可能存在的配置问题。

作者：Yitaek Hwang

翻译：Bach（才云）

校对：木子（才云）

分布式系统和微服务体系结构的挑战之一是自动检测不正常的应用程序，并将请求（request）重新路由到其他可用系统，恢复损坏的组件。健康检查是应对该挑战的一种可靠方法。使用 Kubernetes，可以通过探针配置运行状况检查，以确定每个 Pod 的状态。

默认情况下，Kubernetes 会观察 Pod 生命周期，并在容器从挂起（pending）状态转移到成功（succeeded）状态时，将流量路由到 Pod。Kubelet 会监控崩溃的应用程序，并重新启动 Pod 进行恢复。许多开发人员认为这样的基本设置就足够了，尤其是当 Pod 内的应用程序还配置了守护进程管理器（例如 Node.js 的 PM2）时。

但有一种意外情况，当 Kubernetes 在所有容器启动后，认为 Pod 是健康且可以接受请求时，但应用程序在实际准备就绪之前就已收到流量，比如应用程序在处理应用程序逻辑之前，初始化了一些状态，建立了数据库连接或加载了数据。当 Deployment 开始扩展时，未就绪的应用程序会接收流量并返回 500 错误，这造成了应用程序实际的准备就绪与 Kubernetes 认为的准备就绪之间的时间间隔问题。

同样的，这也是 Kubernetes 探针用来定义容器何时准备接受流量，以及何时重新启动容器的方式。从 Kubernetes v1.16 开始，已经支持三种类型的探针。在本文中将介绍这三种类型的探针、最佳实践和有关工具，以检测可能存在的配置问题。

K8sMeetup

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）。

Readiness 探针

readiness 探针可以让 kubelet 知道应用程序何时准备接受新流量。 如果应用程序在进程启动后需要一些时间来初始化状态，要配置 readiness 探针让 Kubernetes 在发送新流量之前进行等待。readiness 探针的主要作用是将流量引导至 service 后的 deployment。

关于 readiness 探针有一点很重要，它会在容器的整个生命周期中运行。 这意味着 readiness 探针不仅会在启动时运行，而且还会在 Pod 运行期间反复运行。 这是为了处理应用程序暂时不可用的情况（比如加载大量数据、等待外部连接时）。在这种情况下，我们不一定要杀死应用程序，可以等待它恢复。 readiness 探针可用于检测这种情况，并在 Pod 再次通过 readiness 检查后，将流量发送到这些 Pod。

Liveness 探针

liveness 探针用于重新启动不健康的容器。 Kubelet 会定期地 ping liveness 探针，以确定健康状况，并在 liveness 检查不通过的情况下杀死 Pod。liveness 检查可以帮助应用程序从死锁中恢复。如果不进行 liveness 检查，Kubernetes 会认为死锁中的 Pod 处于健康状态，因为从 Kubernetes 的角度来看，Pod 的子进程仍在运行，是健康的。通过配置 liveness 探针，kubelet 可以检测到应用程序处于不健康状态，并重新启动 Pod 以恢复可用性。

Startup 探针

startup 探针与 readiness 探针类似，但它仅在启动时执行，能针对启动缓慢的容器或在初始化过程中有不可预测行为的应用程序进行优化。 借助 readiness 探针，我们可以配置 initialDelaySeconds 来确定 readiness 探测在准备就绪前要等待多长时间。

假设有一个偶尔需要下载大量数据的应用程序，由于 initialDelaySeconds 是一个静态数字，因此该应用程序即使不需要那么长的初始化等待时间，我们也必须设置最保守的等待时间。通过 startup 探针，我们可以配置 failureThreshold 和 periodSeconds 来解决该问题，例如设置 failureThreshold 为 15，periodSeconds 为 5，这意味着应用程序在失败之前会有 10x5=75s 的启动时间。

K8sMeetup

配置探针

现在我们了解了不同类型的探针，下面是配置每种探针的三种不同方式。

HTTP

kubelet 将 HTTP GET 请求发送到 endpoint，并检查 2xx 或 3xx 响应。我们可以重复使用现有的 HTTP endpoint 或设置轻量级 HTTP 服务器以进行探测（例如，具有 /healthz endpoint 的 Express server）。HTTP 探针包含其他额外参数：

host ：要连接的主机名（默认值：pod 的 IP）。
scheme ：HTTP（默认）或 HTTPS。
path ：HTTP/S 服务器上的路径。
httpHeaders ：自定义标头（如果需要标头用于身份验证、CORS 设置等）。
port ：访问服务器的端口名称或端口号。

TCP

如果仅需要检查是否可以建立 TCP 连接，则可以指定 TCP 探针。如果建立 TCP 连接，则将 Pod 标记为运行状况良好。对于不适合使用 HTTP 探针的 gRPC 或 FTP 服务器，TCP 探针可能会有用。

Command

可以将探针配置为运行 shell 命令。如果命令返回的退出代码为 0，则检查通过，否则 Pod 将被标记为不健康。如果不希望公开 HTTP 服务器与端口，或者希望通过命令检查初始化步骤（例如，检查是否已创建配置文件、运行 CLI 命令），这种类型的探针会很有用。

K8sMeetup

最佳实践

虽然说探针的确切参数和使用方法取决于应用程序，但也有一些常用的最佳实践：

对于较旧的（≤v1.15）Kubernetes 集群，使用具有初始延迟的 readiness 探针来处理容器启动阶段。
对于较新的（≥v1.16）Kubernetes 集群，如果是具有不可预测或可变启动时间的应用程序应使用 startup 探针。 startup 探针与 readiness 和 liveness 探针共享相同的 endpoint（例如 /healthz ），但能将 failureThreshold 设置得比其他探针更高，以拥有更长的启动时间，相对于 liveness 和 readiness 而言，设置的失败时间会更合理。
如果 readiness 探针不用于其他信号目的，readiness 和 liveness 探针可以共享相同的 endpoint，但如果只有一个 Pod（也就是使用 VPA）时，设置 readiness 探针来解决启动行为，使用 liveness 探针来确定运行状况。这种情况下，标记 Pod 不健康意味着停机时间。
readiness 检查可以用各种方式来发出系统故障的信号。 例如，当应用程序失去与数据库的连接时，可以使用 readiness 探针暂时阻止新请求并允许系统重新连接。它还可以将繁忙的 Pod 标记为未准备，将工作负载平衡到其他 Pod。

简而言之，定义明确的探针通常会带来更好的弹性和可用性。确保观察启动时间和系统行为，在应用程序更改时调整探针设置。

K8sMeetup

工具

最后，鉴于 Kubernetes 探针的重要性，我们可以使用 Kubernetes 资源分析工具来检测缺失的探针。这些工具可以在现有集群上运行，也可以置入 CI/CD 流程中，可以在没有正确配置资源的情况下自动拒绝工作负载。

polaris ：一个具有仪表板的资源分析工具，也可以用作验证 webhook 或 CLI 工具。
kube-score ：一个静态代码分析工具，可用于 Helm、Kustomize 和标准 YAML 文件。
popeye ：只读的实用工具，用于扫描 Kubernetes 集群并报告配置中的潜在问题。

原文链接： https://medium.com/dev-genius/understanding-kubernetes-probes-5daaff67599a

推荐阅读：

文章转载自K8sMeetup社区。点击这里阅读原文了解更多。

扫描二维码联系我们！

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。

本文分享自微信公众号 - CNCF（lf_cncf）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/cncf/blog/4875208

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

一件好事

【溯源】在每一场对话中，追溯关于开源的故事，认识那些极客、自由，并坚持着的开源人。当我们联系到《大教堂与集市》中文译本作者卫剑钒时，他说：“还没有人对我和开源的故事如此感兴趣。” 1997 年，《大教堂与集市》第一版发布。在开源概念传播开来之后，这本书被称作开源“圣经”，书中通过分析 Linux 成功的案例，总结开源开发规律。2012 年，卫剑钒受出版社编辑的邀请，开始翻译这本书，最终在 2014 年完成。据他说，有了解的人告诉他，这本译作华为某部门人手一本。虽然在开源圈引起了一阵轰动，但翻译“圣经”实际上并没有为他的生活带来太多变化。出书后的好几年，卫剑钒的兴趣主要在网络安全和区块链，鲜少涉及开源。直到 2019 年，接连发表的几篇开源文化与许可证解读文章又让他回到中国开源圈视野中央。卫剑钒称自己是开源的一个观察者。囿于工作原因，他没有以开源协作的开发方式参与某个开源项目。开源之于他，是一件好事，是时常会感兴趣的一个话题。翻译、写文章都是兴趣到了，想写了，凭着一股冲动就动笔了。然而在旁人看来，这些作品精准道出了开源的理念，有关许可证的解读更是难得的、通俗易懂的好文。认可开源，...

2021-01-04

601

生活中，你我一定都看到过这种「xx元爆改出租屋」，「爆改小汽车」之类的文章，做为IT人，折腾的劲头一点也不差。软件开发过程中，你是否有时候，会拿着业务提供的一个个CSV或者JSON的数据文件，写个解析程序，把它们存到数据库里，再在自己的程序里通过数据库读出来？其实不用这么麻烦，还绕了一个大圈。今天，我们一起来「爆改」JSON/CSV这类文件，把它们打造成 MySQL一样的关系型数据库，一套SQL查询走天下。:-) 第一步：代码里加入Maven依赖 ‍ <dependency> <groupId>org.apache.calcite</groupId> <artifactId>calcite-file</artifactId> <version>1.21.0</version> </dependency> 通过这一步，你大概就看出来，咱们今天的爆改，主要依赖 Calcite，这个Apache的顶级项目。来张官网截图感受下：简单介绍的话，它是个数据库查询和优化的引擎，不负责具体的存储。...

2021-01-03

559

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。