前言:

分布式系统和微服务体系结构的挑战之一是自动检测不正常的应用程序,并将请求(request)重新路由到其他可用系统,恢复损坏的组件。健康检查是应对该挑战的一种可靠方法。使用 Kubernetes,可以通过探针配置运行状况检查,以确定每个 Pod 的状态。
.
摘要:Kubernetes 版本小于 v1.15 时支持 Readiness 和 Liveness 探针,在 v1.16 中添加了 startup 探针作为 Alpha 功能,并在 v1.18 中升级为 Beta。
.

一、探针类型介绍:

(1)、K8s中存在三种类型的探针:liveness probe、readiness probe和startup 探针。每类探针都支持三种探测方法

  • liveness探针:影响的是单个容器,如果检查失败,将杀死容器,根据pod的restartPolicy来操作。
  • readiness探针:影响的是整个pod,即如果pod中有多个容器,只要有一个容器的readiness探针诊断失败,那么整个pod都会处于unready状态。
  • startup探针:指示容器中的应用是否已经启动。如果提供了启动探针(startup probe),则禁用所有其他探针,直到它成功为止。如果启动探针失败,kubelet 将杀死容器,容器服从其重启策略进行重启。如果容器没有提供启动探针,则默认状态为成功Success。

(2)、这三种探针均具有以下参数:

  • initialDelaySeconds:容器启动后第一次执行探测是需要等待多少秒。
  • periodSeconds:执行探测的频率。默认是10秒,最小1秒。
  • timeoutSeconds:探测超时时间。默认1秒,最小1秒。
  • successThreshold:探测失败后,最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。
  • failureThreshold:探测成功后,最少连续探测失败多少次才被认定为失败。默认是3。最小值是1。

(3)、探针探测的结果有以下三者之一:

  • Success:Container通过了检查。
  • Failure:Container未通过检查。
  • Unknown:未能执行检查,因此不采取任何措施。

1、liveness probe(存活探针)

必要性:

在一个服务中,是存在进程在运行,但服务其实已经挂掉了,表现为端口监听失败、http请求失败等。所以需要存活探针

运行原理:

用于判断容器是否存活,即Pod是否为running状态,如果LivenessProbe探针探测到容器不健康,则kubelet将kill掉容器,并根据容器的重启策略是否重启。
如果一个容器不包含LivenessProbe探针,则Kubelet认为容器的LivenessProbe探针的返回值永远成功。

有时应用程序可能因为某些原因(后端服务故障等)导致暂时无法对外提供服务,但应用软件没有终止,导致K8S无法隔离有故障的pod,调用者可能会访问到有故障的pod,导致业务不稳定。
K8S提供livenessProbe来检测应用程序是否正常运行,并且对相应状况进行相应的补救措施。

注意,liveness探测失败并一定不会重启pod,pod是否会重启由你的restart policy 控制。

2、readiness probe(就绪探针)

运行原理:

用于判断容器是否启动完成,即容器的Ready是否为True,可以接收请求,如果ReadinessProbe探测失败,
则容器的Ready将为False,控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除,从此不再将任何请求调度此Pod上,直到下次探测成功。
通过使用Readiness探针,Kubernetes能够等待应用程序完全启动,然后才允许服务将流量发送到新副本。

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

3、Startup probe(启动探针)

运行原理:

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

二、探针探测方法介绍:

  • exec通过执行shell命令的方式,判断退出状态码是否是0,针对复杂检测或无HTTP接口的服务,命令返回值为0则表示容器健康。
  • tcpSocket:通过容器的IP和Port执行TCP检查,kubelet尝试打开容器上的某个端口,如果能够建立TCP连接,则表明容器健康。
  • httpGet通过发送http请求检查服务是否正常,每进行一次HTTP健康检查都会curl访问一次指定的URL,返回200-399状态码则表明容器健康,否则认为容器运转不正常。

1、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:访问服务器的端口名称或端口号。
livenessProbe:
httpGet:
path: /
port: 8080

2、TCP

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

readinessProbe:
tcpSocket:
port: 20

3、Command

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

readinessProbe:
exec:
command: ["/bin/sh", "-ec", "vault status -tls-skip-verify"]

三、用法实例:

点击查看代码
          readinessProbe:
httpGet:
path: {{ .Values.probe.readiness }}
port: {{ .Values.insInsuranceApi.service.targetPort }}
scheme: HTTP
failureThreshold: 3
initialDelaySeconds: 90
periodSeconds: 10
successThreshold: 3
timeoutSeconds: 1
livenessProbe:
httpGet:
path: {{ .Values.probe.liveness }}
port: {{ .Values.insInsuranceApi.service.targetPort }}
scheme: HTTP
failureThreshold: 3
initialDelaySeconds: 180
periodSeconds: 10
timeoutSeconds: 120

Kubernetes探针原理详解的更多相关文章

  1. Docker Kubernetes 服务发现原理详解

    Docker Kubernetes  服务发现原理详解 服务发现支持Service环境变量和DNS两种模式: 一.环境变量 (默认) 当一个Pod运行到Node,kubelet会为每个容器添加一组环境 ...

  2. Kubernetes Pod 驱逐详解

    原文链接:Kubernetes Pod 驱逐详解 在 Kubernetes 中,Pod 使用的资源最重要的是 CPU.内存和磁盘 IO,这些资源可以被分为可压缩资源(CPU)和不可压缩资源(内存,磁盘 ...

  3. I2C 基础原理详解

    今天来学习下I2C通信~ I2C(Inter-Intergrated Circuit)指的是 IC(Intergrated Circuit)之间的(Inter) 通信方式.如上图所以有很多的周边设备都 ...

  4. Zigbee组网原理详解

    Zigbee组网原理详解 来源:互联网 作者:佚名2015年08月13日 15:57   [导读] 组建一个完整的zigbee网状网络包括两个步骤:网络初始化.节点加入网络.其中节点加入网络又包括两个 ...

  5. 块级格式化上下文(block formatting context)、浮动和绝对定位的工作原理详解

    CSS的可视化格式模型中具有一个非常重要地位的概念——定位方案.定位方案用以控制元素的布局,在CSS2.1中,有三种定位方案——普通流.浮动和绝对定位: 普通流:元素按照先后位置自上而下布局,inli ...

  6. SSL/TLS 原理详解

    本文大部分整理自网络,相关文章请见文后参考. SSL/TLS作为一种互联网安全加密技术,原理较为复杂,枯燥而无味,我也是试图理解之后重新整理,尽量做到层次清晰.正文开始. 1. SSL/TLS概览 1 ...

  7. 锁之“轻量级锁”原理详解(Lightweight Locking)

    大家知道,Java的多线程安全是基于Lock机制实现的,而Lock的性能往往不如人意. 原因是,monitorenter与monitorexit这两个控制多线程同步的bytecode原语,是JVM依赖 ...

  8. [转]js中几种实用的跨域方法原理详解

    转自:js中几种实用的跨域方法原理详解 - 无双 - 博客园 // // 这里说的js跨域是指通过js在不同的域之间进行数据传输或通信,比如用ajax向一个不同的域请求数据,或者通过js获取页面中不同 ...

  9. 节点地址的函数list_entry()原理详解

    本节中,我们继续讲解,在linux2.4内核下,如果通过一些列函数从路径名找到目标节点. 3.3.1)接下来查看chached_lookup()的代码(namei.c) [path_walk()> ...

随机推荐

  1. 还不会用springboot写接口?快看这里,手把手操作,一发入魂~

    1.springboot简介 Spring Boot 可以轻松创建可以"直接运行"的独立的.生产级的基于 Spring 的应用程序. 特征 创建独立的 Spring 应用程序 直接 ...

  2. Bellman-Ford算法 求有边数限制的最短路

    这个算法也是紧承我们之前讲过的关于图论的内容,我们在前面分析图的时候说过了对于不同的图论问题,我们会有不同的求解方法,那么这里我们讲到Bellman-Ford算法是用于解决有边数限制的求解最短路问题. ...

  3. 017tcpflow的简单用法

    tcpflow tcpflow是服务器上经常使用的一个小程序,它能够捕获tcp的数据流,并将其存储为方便分析和调试的格式.每一条tcp流都会被存储到独立的文件中,因此,典型的tcp流将会被分别存储为进 ...

  4. [SPDK/NVMe存储技术分析]003 - NVMeDirect论文

    说明: 之所以要翻译这篇论文,是因为参考此论文可以很好地理解SPDK/NVMe的设计思想. NVMeDirect: A User-space I/O Framework for Application ...

  5. CVE-2017-7269(IIS远程代码执行)

    利用CVE-2017-7269让IIS向自己的msf反弹一个shell 漏洞编号:CVE2017-7269 服务器版本:Windows server 2003 中间件:IIS6.0 攻击工具:meta ...

  6. [happyctf]部分writeup

    题目名称:sqltest所属:MISC考察点:盲注 眼力 耐心(好吧是废话) 附件下载下来 ,到手一个流量包,用wireshark打开,大致浏览了一下,抓的应该是盲注的数据流量. 这里有一个经验问题, ...

  7. OpenCV开发笔记(七十四):OpenCV3.4.1+ffmpeg3.4.8交叉编译移植到海思平台Hi35xx平台

    前言   移植opencv到海思平台,opencv支持对视频进行解码,需要对应的ffmpeg支持.   Ffmpeg的移植   Ffmpeg的移植请参考之前的文章:<FFmpeg开发笔记(十): ...

  8. 洛谷P1091 [NOIP2004 提高组] 合唱队形

    本题是一个简单的 LIS(最长上升子序列)问题     只是要求俩次最长上子序列而已   很容易的 首先由于是最长上升子序列 所以朴素法的动态规划表达式为  f[i] = max( f[i] , f[ ...

  9. mq 的缺点 ?

    系统可用性降低 系统引入的外部依赖越多,越容易挂掉,本来你就是 A 系统调用 BCD 三个系统的 接口就好了,人 ABCD 四个系统好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整?MQ ...

  10. mq 的缺点?

    (1)系统可用性降低 系统引入的外部依赖越多,越容易挂掉,本来你就是 A 系统调用 BCD 三个系统的接口就好了,人 ABCD 四个系统好好的,没啥问题,你偏加个 MQ 进来,万一MQ 挂了咋整?MQ ...