内容简介:【编者的话】Kubernetes提供了两种探针来检查容器的状态,Liveness 和 Readiness,根据在Kubernets中,pods是Kubernetes创建及管理的最小的可部署的计算单元,一个pod由一个或者多个容器(Docker,rocket等等)组成,这些容器共享内存,网络以及运行容器的方式。在Kubernetes上下文中
【编者的话】Kubernetes提供了两种探针来检查容器的状态,Liveness 和 Readiness,根据 官方文档 ,Liveness探针是为了查看容器是否正在运行,翻译为存活探针,Readiness探针是为了查看容器是否准备好接受HTTP请求,翻译为就绪探针。这篇文章主要阐述了作者在使用这两种探针时总结的一些最佳实践。
在Kubernets中,pods是Kubernetes创建及管理的最小的可部署的计算单元,一个pod由一个或者多个容器(Docker,rocket等等)组成,这些容器共享内存,网络以及运行容器的方式。
在Kubernetes上下文中 存活探针和就绪探针 被称作 健康检查 。这些容器探针是一些周期性运行的小进程,这些探针返回的结果如(成功,失败或者未知)反映了了容器在Kubernetes的状态。基于这些结果,Kubernetes会判断如何处理每个容器,以其弹性,高可用性和更长的正常运行时间。
健康检查是每个分布式系统所必需的!
Kubernetes的健康检查:
Kubernetes提供了两种类型的健康检查: 就绪探针 和 存活探针 ,它们有各自的用途。在这篇文章中我们将会选择:
/.well-known/live— 用于探测HTTP是否存活
/.well-known/ready— 用于探测HTTP是否就绪
简而言之,HTTP探测意味着Kubernetes在特定时间间隔执行HTTP请求 /.well-known/live 和 /.well-known/ready 。响应的状态码用于决定需要对pod执行的操作。如果状态代码在区间 [200,300) 中,则一切正常。除此以外:
- 如果存活探测器的状态代码是 4xx 或 5xx ,则代表pod已被重启。
- 如果就绪探测器的状态代码是 4xx 或 5xx ,那么pod会被标记为不健康,并且Kubernetes为了提高可靠性和正常运行时间将不会再将HTTP请求转发给它。
如果您的容器独立于任何支持服务,则容器可以具有在同一处理程序上进行存活和就绪检查,并且后面的实践不适用于这种情况。
我们与来自Metro Systems Romania - Site Reliability Team的团队成员一起确定了健康检查的最佳实践列表,并建议应用程序开发人员遵循这些实践。这些最佳实践如下:
-
存活和就绪的结果处理程序需要是互相独立的程序
如前所述,对于在Kubernetes上下文中部署的每个产品,应该实现2个分别处理HTTP请求“存活”和“就绪”的处理程序。这些探测器的处理程序需要独立实现自己的功能。 -
不要把“存活/就绪”探针的逻辑与你的程序解耦
这适用于作业处理应用程序。对于Kubernetes,了解应用程序是否正在运行非常重要。如果存活/就绪逻辑被解耦了在新进程中运行,则结果不准确。 -
不要在“存活”处理程序里实现任何逻辑。如果主线程正在运行,它需要返回状态200,如果不是,则返回5xx
这个探针让Kubernetes知道应用程序是正在运行还是停止运行。通过检查/.well-known/live的状态代码来做出决定,如果应用程序被判断为停止运行,则Kubernetes会重新启动pod。从可靠性的角度来看,如果应用程序的主线程已启动并正在运行,则Live(存活)探测的结果为true,否则为false。
在这个上下文中,“逻辑”意味着对互相连接的服务实施某种检查
-
在“就绪”探针的处理程序中实现逻辑,以便提供有关应用程序准备情况的详情
就绪探针让Kubernetes知道pod是否已准备好接收HTTP请求。作为开发人员,在此处实现一些逻辑来检查应用程序的所有后端依赖的可用性非常重要。当实现就绪处理程序时,需要清楚的知道您的应用程序依赖于哪些功能。换句话说,在就绪处理程序里,需要运行所有步骤以保证应用程序已准备好接收和处理https请求的,这非常重要。例如,如果应用程序需要建立与数据库的连接以准备处理HTTP请求,那么在“ready(就绪)”程序中就必须检查是否已建立与数据库的连接并可以使用。 -
不要尝试在就绪处理程序上重新建立应用程序的就绪状态。这个探针只是为了检查应用程序是否准备就绪,而不是让应用程序就绪。
我并不建议实现任何让程序重新就绪的逻辑。这些逻辑可能会为系统中的某些组件带来危险。
结论:
存活和就绪探针是部署在Kubernetes中的应用程序的核心和灵魂。它们是与虚拟机管理程序通信的标准方式,通过这种方式可以了解虚拟机的状态和问题。存活和就绪探针是开发人员和应用程序必备的强大武器,它确保应用程序的可靠性和弹性。
特别感谢Ionut Ilie。部分内容是他的研究成果以及智慧结晶。
原文链接: Kubernetes Readiness & Liveliness Probes — Best Practices
==============================================================================
译者介绍
Grace,程序员,研究生毕业于SUNY at Stony Brook,目前供职于Linktime Cloud Company,对大数据技术以及数据可视化技术感兴趣。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Skywalking Node.js 探针 0.1.0 版本正式发布
- 框架已就绪,专注发力内容
- F5大中华区首席技术官吴静涛:无探针实时应用大数据采集引擎落地实践和AIOps实现
- CentOS7官方Docker发行版现重大Bug可致Kubernetes中的健康检测探针失败并影响容器交互
- 教程|构建生产就绪的Istio Adapter
- 细粒度和应用就绪的距离限制安全性
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
反应式设计模式
Roland Kuhn、Brian Hanafee、Jamie Allen / 何品、邱嘉和、王石冲、林炜翔审校 / 清华大学出版社 / 2019-1-1 / 98.00 元
《反应式设计模式》介绍反应式应用程序设计的原则、模式和经典实践,讲述如何用断路器模式将运行缓慢的组件与其他组件隔开、如何用事务序列(Saga)模式实现多阶段事务以及如何通过分片模式来划分数据集,分析如何保持源代码的可读性以及系统的可测试性(即使在存在许多潜在交互和失败点的情况下)。 主要内容 ? “反应式宣言”指南 ? 流量控制、有界一致性、容错等模式 ? 得之不易的关于“什么行不通”的经验 ? ......一起来看看 《反应式设计模式》 这本书的介绍吧!