Kubernetes之Probe探针

这里介绍Kubernetes中的Probe探针

abstract.png

概述

Probe探针是由kubelet对容器执行的定期诊断。具体地,Probe探针支持以下几种实现方式:

1. Exec

在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功

2. grpc

使用gRPC执行一个远程过程调用,目标应该实现gRPC健康检查。 如果响应的状态是SERVING,则认为诊断成功;gRPC探针是一个alpha特性,必须先启用GRPCContainerProbe特性门控

3. HTTP GET

对容器的IP 地址上指定端口、路径执行HTTP GET请求。如果响应的状态码大于等于200且小于400,则诊断被认为是成功的

4. TCP Socket

对容器的IP地址上的指定端口执行TCP检查。如果端口打开,则诊断被认为是成功的;如果远程系统(容器)在打开连接后立即将其关闭,这算作是健康的

Readiness Probe 就绪探针

用于指示容器是否准备好为请求提供服务。因为有些应用在启动后不是立即可以投入使用的,其需要需要一定的初始化时间以用于数据加载预热等操作。如果就绪探针报告失败,则会从Service的Endpoints列表中移除该Pod的IP地址。其中,初始延迟之前的状态值默认为失败;如果未指定就绪探针,则默认状态为成功

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
# 创建应用的RS资源

apiVersion: apps/v1
# 资源类型
kind: ReplicaSet
metadata:
name: my-rs-apple-app
spec:
# 副本数量
replicas: 2
# 标签选择器
selector:
matchLabels:
company: Apple
# Pod模板
template:
metadata:
# 标签信息
labels:
company: Apple
spec:
# 容器信息
containers:
# 容器名称
- name: my-apple-app
# 镜像信息
image: luksa/kubia
# 仅用于展示容器所使用的端口
ports:
- containerPort: 8080
protocol: TCP
# 就绪探针: Exec探针
readinessProbe:
# 容器启动后多久开始进行探测, Unit: s
initialDelaySeconds: 20
# 探针等待响应的时限, 超时则本次探测失败。Unit: s
timeoutSeconds: 2
# 探测周期, Unit: s
periodSeconds: 20
# 连续探测1次成功表示成功
successThreshold: 1
# 连续探测5次失败表示失败
failureThreshold: 5
# Exec探针: 就绪探针将定期执行 ls /var/ready 命令
# 如果文件存在,则ls命令的返回值为0。此时就绪探针就会成功
# 如果文件不存在,则ls命令的返回值为非零。此时就绪探针就会失败
exec:
# 设置容器启动时执行的命令、参数
command:
- ls
- /var/ready

---

# 创建应用的Service资源
apiVersion: v1
# 资源类型
kind: Service
metadata:
name: apple-service
spec:
# 标签选择器
selector:
company: Apple
ports:
- port: 12345 # 服务监听端口
targetPort: 8080 # 服务将请求转发到的目标端口

创建上述资源后,不难发现该RS的2个Pod的均为未就绪

figure 1.jpeg

当我们对某个Pod容器按照探针指定的路径建立文件/目录后,稍后即会发现该Pod的状态即为就绪。同时相应服务的Endpoints列表中也会包含该Pod的IP。说明此时该Pod已经准备就绪,可以通过Service资源对外提供服务

figure 2.jpeg

需要注意的是,由于Readiness Probe 就绪探针是定期执行的。故即使由于此前就绪探针执行成功,进而使得该Pod状态为就绪状态了。后续一旦就绪探针执行失败,则该Pod的状态会再次变为未就绪。直到就绪探针执行成功为止,Pod状态才会再次发生更新

Liveness Probe 存活探针

指示容器是否正在运行。如果存活探针结果为失败,则kubelet会杀死该容器并根据重启策略来决定是否需要重启该容器。如果容器不提供存活探针,则默认为成功。不难看出通过存活探针可以很方便地对我们的应用加入心跳机制,保障高可用性。下面即是一个典型的配置示例。值得一提的是,对于存活探针而言,其并不会等待就绪探针执行成功后,才开始进行探测。换言之,就绪探针与存活探针之间在执行时机上没有任何的依赖、关联

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: v1
# 资源类型
kind: Pod
metadata:
# Pod 名称
name: my-kubia-pod-3
spec:
# 容器信息
containers:
# 容器名称
- name: my-kubia-3
# 镜像信息
image: luksa/kubia
# 仅用于展示容器所使用的端口
ports:
- containerPort: 8080
protocol: TCP
# 存活探针: HTTP GET探针
livenessProbe:
# 容器启动后多久开始进行探测, Unit: s
initialDelaySeconds: 20
# 探针等待响应的时限, 超时则本次探测失败。Unit: s
timeoutSeconds: 2
# 探测周期, Unit: s
periodSeconds: 20
# 连续探测1次成功表示成功
successThreshold: 1
# 连续探测5次失败表示失败
failureThreshold: 5
# HTTP GET探针请求的路径、端口信息
httpGet:
path: /
port: 8080

Startup Probe 启动探针

指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会先被禁用,直到此探针成功为止。显然该探针十分适用于启动换成非常缓慢的应用。如果启动探测失败,则kubelet会杀死该容器并根据重启策略来决定是否需要重启该容器。如果容器没有提供启动探针,则默认为成功。下面即是一个典型的配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: v1
# 资源类型
kind: Pod
metadata:
# Pod 名称
name: my-kubia-pod-9
spec:
# 容器信息
containers:
# 容器名称
- name: my-kubia-9
# 镜像信息
image: luksa/kubia
# 仅用于展示容器所使用的端口
ports:
- containerPort: 8080
protocol: TCP
# 启动探针: HTTP GET探针
startupProbe:
# 容器启动后多久开始进行探测, Unit: s
initialDelaySeconds: 20
# 探针等待响应的时限, 超时则本次探测失败。Unit: s
timeoutSeconds: 2
# 探测周期, Unit: s
periodSeconds: 20
# 连续探测1次成功表示成功
successThreshold: 1
# 连续探测5次失败表示失败
failureThreshold: 5
# HTTP GET探针请求的路径、端口信息
httpGet:
path: /
port: 8080

参考文献

  1. Kubernetes in Action中文版 Marko Luksa著
  2. 深入剖析Kubernetes 张磊著
0%