Kubernetes 三大探针及探针方式

原创已于 2023-02-03 18:16:37 修改 · 4.7k 阅读

41 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #运维

于 2022-06-29 18:49:42 首次发布

Kubernetes 专栏收录该内容

11 篇文章

订阅专栏

本文介绍了Kubernetes中的三种探针类型：启动探针、就绪探针和存活探针，用于监控和管理Pod的健康状态。启动探针确保应用启动完成，就绪探针决定容器是否接受流量，存活探针则在应用异常时重启容器。探针可通过exec、httpGet和tcpSocket三种方式进行检查，并通过配置项如initialDelaySeconds、periodSeconds等调整检查行为。文中通过实例展示了如何配置和使用这些探针，强调了它们在实际运维中的重要性。

一、探针背景介绍

1、编排工具运行时，虽说pod挂掉会在控制器的调度下会重启，出现pod重启的时候，但是pod状态是running，无法真实的反应当时pod健康状态，我们可以通过Kubernetes的探针监控到pod的实时状态。

二、Kubernetes三种探针类型

启动探针（Startup Probe）：判断容器内的应用是否启动完成（在启动探针判断成功前，就绪探针和存活探针将不会执行）

就绪探针（Readiness Probe）：判断容器是否已经就绪，若未就绪，容器将会处于未就绪，未就绪的容器，不会进行流量的调度。

存活探针（Liveness Probe）：判断容器内的应用程序是否正常，若不正常，K8s 将会重新重启容器。

三、探针的三种方式

exec：通过在容器内执行指定命令，来判断命令退出时返回的状态码，如果为 0 表示正常。

httpGet：通过对容器的 IP 地址、端口和 URL 路径来发送 GET 请求；如果响应的状态码在 200 ~ 399 间，表示正常。

tcpSocket：通过对容器的 IP 地址和指定端口，进行 TCP 检查，如果端口打开，表示正常。

四、配置项

initialDelaySeconds：等待我们定义的时间结束后便开始探针检查；

periodSeconds：探针的间隔时间；

timeoutSeconds：探针的超时时间，当超过我们定义的时间后，便会被视为失败；

successThreshold：探针的最小连续成功数量；

failureThreshold：探针的最小连续失败数量；

下面我们分别对这三种探针使用了不同的探针方式，主要是为了方便给大家做一个简单的介绍，并不是固定写法；同时，这三种探针是可以配合使用的；像一般比较常见的便是就绪探针和存活探针配合使用（启动探针是在 K8s 1.6 版本后增加的

五、探针使用介绍

1）启动探针

apiVersion: v1
kind: Pod
metadata:
  name: nginx-start-up
  namespace: probe
spec:
  containers:
  - name: nginx-start-up
    image: nginx:latest
    ports:
    - containerPort: 80
    startupProbe:
      failureThreshold: 3  #失败三次算探针失败
      exec:
        command: ['/bin/sh','-c','echo Hello World']
      initialDelaySeconds: 20  #延迟20s后进行第一次探针
      periodSeconds: 3 #间隔3s进行一次探针
      successThreshold: 1 #成功一次算探针ok
      timeoutSeconds: 2 #超时2s算失败一次

在这里插入图片描述
2）就绪探针

apiVersion: v1
kind: Pod
metadata:
  name: nginx-ready
  namespace: probe
  labels:
    app: nginx-ready   #验证就绪探针的关键参数
spec:
  containers:
  - name: nginx-ready
    image: nginx:latest
    ports:
    - containerPort: 80
    readinessProbe:
      failureThreshold: 3
      tcpSocket:
        port: 80
      initialDelaySeconds: 20
      periodSeconds: 3
      successThreshold: 1
      timeoutSeconds: 2

端口检测正常：
在这里插入图片描述
写一个nodeport类型进行流量验证

apiVersion: v1
kind: Service
metadata:
  name: ready-nodeport
  labels:
    name: ready-nodeport
  namespace: probe
spec:
  type: NodePort
  ports:
  - port: 88
    protocol: TCP
    targetPort: 80
    nodePort: 30880
  selector:
    app: nginx-ready

模拟流量结果是ok的
在这里插入图片描述
现在修改下就绪探针tcpSocket检测方式的端口为81模拟下探针失败，流量会不会走到该pod

显示81端口不通，ready状态为0，但pod是running的，请求一下结果如下，流量打入失败。就绪探针失败，是不会给该pod打入流量的。
在这里插入图片描述

3）存活探针

apiVersion: v1
kind: Pod
metadata:
  name: nginx-live
  namespace: probe
  labels:
    app: nginx-live
spec:
  containers:
  - name: nginx-live
    image: nginx:latest
    ports:
    - containerPort: 80
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: 80
        scheme: HTTP
      initialDelaySeconds: 20
      periodSeconds: 3
      successThreshold: 1
      timeoutSeconds: 2

在这里插入图片描述
生成一个nodeport类型service

apiVersion: v1
kind: Service
metadata:
  name: live-nodeport
  labels:
    name: live-nodeport
  namespace: probe
spec:
  type: NodePort
  ports:
  - port: 89
    protocol: TCP
    targetPort: 80
    nodePort: 30810
  selector:
    app: nginx-live

curl进行ip端口校验
在这里插入图片描述
修改httpget中port参数值为81，模拟存活探针失败，探针失败，会让pod进行重启。