K8s就绪探针和存活探针

Kubernetes高级概念和应用 之 K8s就绪探针和存活探针

判断pod是否已经就绪,可以接流量了~

exec 去容器里执行命令来检查~



k8s pod 健康检查 liveness ,readiness,startup探针?

k8s pod 健康检查主要包括三种类型的探针:

  1. 存活探针(liveness probe):
    存活探针用于检查容器是否仍在健康运行。如果存活探针失败,Kubernetes 会根据 pod 规范中定义的重启策略(restartPolicy)重启容器。存活探针可以是 HTTP GET 请求、TCP 端口检查或执行命令。重启策略有三个可选值:

    • Always: 当容器终止退出后,总是重启容器(默认策略)。
    • OnFailure: 当容器异常退出时才重启容器。
    • Never: 当容器终止退出,从不重启容器。
  2. 就绪探针(readiness probe):
    就绪探针用于检查容器是否准备好接收流量。如果就绪探针失败,Kubernetes 会将 pod 标记为非就绪,且服务(Service)不会将流量路由到该 pod。就绪探针通常在容器启动后不久执行,以确保所有必要的初始化操作已经完成。

  3. 启动探针(startup probe):
    启动探针是 Kubernetes 1.16 版本引入的,用于在容器启动时执行的健康检查。启动探针允许你定义一个自定义的检查,以确保容器在开始接受流量之前已经完全初始化。如果启动探针失败,Kubernetes 会重启容器,直到探针成功为止。

这些探针提供了一种机制,让 Kubernetes 能够自动检测和响应容器的健康状态,确保应用程序的稳定性和可靠性。

如何查看pod中这些探针的信息

在 Kubernetes 中,可以通过几种方式来查看 Pod 中探针的相关信息:

  1. 查看 Pod 描述信息
    通过 kubectl describe pod <pod-name> 命令可以查看 Pod 的详细描述信息,其中包括探针的配置细节。

  2. 查看 Pod YAML/JSON 配置文件
    如果你知道 Pod 的配置文件路径,可以直接查看该文件。YAML 文件中会有 livenessProbereadinessProbestartupProbe 字段对应存活、就绪和启动探针的配置。

  3. 查看事件
    通过 kubectl get events --namespace <namespace> 命令可以查看集群的事件,其中会记录探针失败导致 Pod 重启等信息。

  4. 查看日志
    通过 kubectl logs <pod-name> 命令可以查看容器的日志输出,如果探针是通过执行命令的方式配置,失败时会在日志中体现。

  5. 使用 kubectl 插件
    一些第三方的 kubectl 插件如 kube-ops-view 等,可以以图形化的方式查看 Pod 中探针的配置和状态。

示例:

1
kubectl describe pod/nginx

将显示类似如下的探针配置:

1
2
Liveness:   http-get http://:80/healthz delay=5s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get http://:80/healthz delay=5s timeout=1s period=10s #success=1 #failure=3

总之,查看 Pod 探针配置的关键在于阅读 Pod 的 YAML/JSON 配置文件或使用 kubectl 相关命令检查细节信息。



但是我看了,并没有…

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
kb describe pod/taskon-sign-server-5fcc979f95-d5q8p
Name: taskon-sign-server-5fcc979f95-d5q8p
Namespace: benchtaskon
Priority: 0
Node: 172.22.0.47/172.22.0.47
Start Time: Thu, 21 Mar 2024 16:51:41 +0800
Labels: app=taskon-sign-server
pod-template-hash=5fcc979f95
Annotations: tke.cloud.tencent.com/networks-status:
[{
"name": "tke-bridge",
"interface": "eth0",
"ips": [
"10.8.0.237"
],
"mac": "ee:ff:cd:dd:e5:40",
"default": true,
"dns": {}
}]
Status: Running
IP: 10.8.0.237
IPs:
IP: 10.8.0.237
Controlled By: ReplicaSet/taskon-sign-server-5fcc979f95
Containers:
taskon-sign-server:
Container ID: docker://ecea887b3839a280c455c887f85cdd9939b5e8163d28078fead32842e5789c99
Image: reg.ont.io/taskon/signserver:v1.0.1.sleep2
Image ID: docker-pullable://reg.ont.io/taskon/signserver@sha256:c3bbf62631461c22544a06cd991a96a30c105fa7c1735296df2e2c0c3c975985
Port: <none>
Host Port: <none>
State: Running
Started: Thu, 21 Mar 2024 16:51:42 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/config from configjson-volume (rw)
/keystore from keystore-volume (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4p44g (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
configjson-volume:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: demo-taskon-sig-configjson
Optional: false
keystore-volume:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: taskon-sig-key
Optional: false
kube-api-access-4p44g:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events: <none>