kubernetes 探针（k8sprobe探针一篇讲透）
kubernetes 探针（k8sprobe探针一篇讲透）所有不同的 liveness probe 都可以使用这五个参数。如果需要，还可以自定义选项（等待回复的时间）、（标记容器健康的成功探测执行次数）和（标记容器不健康的失败探测执行次数）等timeoutSeconds选项successThreshold。failiureThreshold如果设置探针，kubelet将自动检查restartPolicy并重新启动容器，因此当应用程序配置为在失败时使容器崩溃时不需要设置探针。例如， NGINX 应用程序会快速启动并在遇到阻止其提供页面服务的问题时关闭。在这种情况下，您不需要进行活性查询。AlwaysOnFailure即可。每种类型的探针都有共同的可调字段：periodSeconds下面每个示例中的字段表示应该每kubelet 5 秒运行一次 liveness 探测。该initialDelaySeconds字段指示kubelet将第一个探测延迟 5
Kubernetes Liveness Probe：它是什么？Liveness 探测可确保容器内的应用程序处于活动状态并正常工作。
⚙️ Liveness 探针它们被用于kubelet确定何时重新启动容器。检测到崩溃或进入损坏状态的应用程序，在许多情况下，可以通过重新启动它们来纠正。
成功配置 liveness probe 后不会执行任何操作，也不会保留任何日志。kubelet如果失败，则记录事件，并根据restartPolicy设置杀死容器。
当 pod 看起来正在运行，但应用程序可能无法正常工作时，应该使用 liveness probe。pod 可能可以运行，但它是无效的，因为它无法处理流量。
如果设置探针，kubelet将自动检查restartPolicy并重新启动容器，因此当应用程序配置为在失败时使容器崩溃时不需要设置探针。例如， NGINX 应用程序会快速启动并在遇到阻止其提供页面服务的问题时关闭。在这种情况下，您不需要进行活性查询。AlwaysOnFailure即可。
每种类型的探针都有共同的可调字段：
- initialDelaySeconds：探测器在容器启动后的 initialDelaySeconds 后开始运行（默认值：0）
- periodSeconds：探测应该运行的频率（默认值：10）
- timeoutSeconds：探测超时（默认值：1）
- successThreshold：标记容器健康/就绪所需的成功探测次数（默认值：1）
- failureThreshold：当探测失败时，它会在认为不健康/未准备好之前尝试 failureThreshold 次（默认值：3）
periodSeconds下面每个示例中的字段表示应该每kubelet 5 秒运行一次 liveness 探测。该initialDelaySeconds字段指示kubelet将第一个探测延迟 5 秒。
如果需要，还可以自定义选项（等待回复的时间）、（标记容器健康的成功探测执行次数）和（标记容器不健康的失败探测执行次数）等timeoutSeconds选项successThreshold。failiureThreshold
所有不同的 liveness probe 都可以使用这五个参数。
还有哪些其他 Kubernetes 探针可用？虽然 Liveness 探针的使用将是本文的主要重点，但您应该知道 Kubernetes 还支持以下其他类型的探针：
⚙️ 启动探针它kubelet使用启动探测来帮助确定容器应用程序何时开始。启用后，这些确保启动探测不会通过禁用活动和就绪检查直到它们成功来阻碍应用程序启动。
这些对于启动缓慢的容器特别有用，因为kubelet当 liveness probe 失败时，它们可以防止在它们启动之前杀死它们。如果在同一端点上使用活性探测器，则将启动探测器设置得failureThreshold更大，以启用较长的启动时间。
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-api-deployment
spec:
template:
metadata:
labels:
app: test-api
spec:
containers:
- name: test-api
image: myrepo/test-api:0.1
startupProbe:
httpGet:
path: /health/startup
port: 80
failureThreshold: 30
periodSeconds: 10
当 Pod 启动并且探测失败时，Kubernetes 会failureThreshold在放弃之前尝试多次。在 liveness probe 的情况下放弃意味着重新启动 Pod。在就绪探测的情况下，Pod 将被标记为Unready。默认为3. 最小值为1。
启动探针的间隔说明- 0 - 10 秒：容器已经旋转起来但kubelet没有做任何事情等待initalDelaySeconds通过
- 10 - 20 秒：发送了第一个探测请求但没有返回响应，这是因为应用程序尚未建立 API，这是由于 2 秒超时导致的失败或立即出现 TCP 连接错误
- 20 - 30 秒：应用已经启动，但只开始获取凭据、配置等，因此对探测请求的响应是 5xx
- 30 - 210 秒：kubelet 一直在探测，但没有成功响应，并且正在达到failureThreshold. 在这种情况下，根据启动探测器的部署配置，pod 将在大约 212 秒后重新启动。
等待超过 3 分钟让应用程序以伪造的依赖项在本地启动可能有点过分！
如果您绝对确定读取机密、凭据以及与数据库和其他数据源建立连接不应该花费这么长时间，那么缩短此间隔也可能更好。这样做会减慢部署速度。
也许弄清楚您是否需要更多节点很重要。您不想在不需要的资源上浪费金钱。查看kubectl top节点，看看是否需要扩展节点。
如果探测失败，则记录事件，并根据kubelet设置杀死容器restartPolicy。
当容器重新启动时，您通常希望检查日志，了解应用程序运行不正常的原因。您可以使用以下命令执行此操作：
kubectl logs <pod-name> --previous
就绪探测
就绪探测器跟踪应用程序的可用性。如果失败，则不会将任何流量转发到 pod。当应用程序需要配置才能使用时，就会使用这些。此外，应用程序可能会遇到流量拥塞并导致探测器发生故障，从而阻止更多流量路由到它并允许它恢复。如果端点控制器失败，则端点控制器会将 pod 摘除。
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-api-deployment
spec:
template:
metadata:
labels:
app: test-api
spec:
containers:
- name: test-api
image: myrepo/test-api:0.1
readinessProbe:
httpGet:
path: /ready
port: 80
successThreshold: 3
如果就绪kubelet探测失败但活动探测成功，则发现容器尚未准备好接收网络流量，但正在朝该方向取得进展。
Kubernetes 探针的运行流程控制kubelet探针。在每个节点上执行的主要“节点代理”是kubelet.
应用程序需要支持以下处理程序之一才能有效地使用 K8S 探针：
- ExecAction处理程序：在容器内执行命令。如果命令返回状态码0，则诊断成功。
- TCPSocketActionhandler 尝试在特定端口上与 pod 的 IP 地址建立 TCP 连接。如果发现端口打开，则诊断成功。
使用 pod 的 IP 地址、特定端口和预定目的地，HTTPGetAction处理程序发送HTTP GET请求。如果给定的响应代码介于200和之间399，则诊断成功。
在 1.24 版本之前，Kubernetes 本身不支持 gRPC 健康检查。这让 gRPC 开发人员在部署到 Kubernetes 时有以下三种方法：
从 Kubernetes 版本 1.24 开始，如果您的应用程序实现了 gRPC 健康检查协议，则可以将 gRPC 处理程序配置为用于应用程序活动检查。kubelet要配置使用 gRPC 的检查，您必须启用GRPCContainerProbe feature gate。
当对kubelet容器进行探测时，它会根据诊断是成功、不成功还是由于某些其他原因不完整来回答Success、或Failure。Unknown
如何设置探测在定义探测之前，您应该检查 Pod 及其容器的系统行为和典型启动时间，以便您可以选择适当的阈值。此外，随着基础设施或应用程序的变化，探测器的选择也应随之改变。例如，使用更多系统资源的 pod 配置可能会影响需要为探测器配置的值。
实际处理程序：一些示例ExecAction处理程序：它在实践中有何用处？它允许您在容器内使用命令来控制 pod 中计数器的生命状态。借助此选项，您可以检查容器操作的多个方面，例如文件的存在、它们的内容和其他选择（可在命令级别访问）。
ExecAction在 pod 的 shell 上下文中执行，如果执行返回任何不同于0（零）的结果代码，则视为失败。
下面的示例演示了如何使用该exec命令和 cat 命令来查看路径中是否存在文件/usr/share/liveness/html/index.html。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness:0.1
ports:
- containerPort: 8080
livenessProbe:
exec:
command:
- cat
- /usr/share/liveness/html/index.html
initialDelaySeconds: 5
periodSeconds: 5
如果没有文件，容器将被重新启动，并且 liveness 探测将失败。
TCPSocketAction处理程序：它在实践中有何用处？在此用例中，liveness probe 使用 TCP 处理程序来确定端口是否8080处于活动状态和打开状态。kubelet使用此配置，您的容器将尝试通过在指定端口上打开套接字来连接到。
apiVersion: v1
kind: Pod
metadata:
name: liveness
labels:
app: liveness-tcp
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness:0.1
ports:
- containerPort: 8080
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
如果 socket 挂掉并且 liveness 探测失败，容器将重新启动。
HTTPGetAction处理程序：它在实践中有何用处？此案例演示了将向/health端口上的路径发送 HTTP GET 请求的 HTTP 处理程序8080。200和之间的值400表示探测成功。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness:0.1
livenessProbe:
httpGet:
path: /health
port: 8080
httpHeaders:
- name: Custom-Header
value: ItsAlive
initialDelaySeconds: 5
periodSeconds: 5
探测失败，如果收到超出此范围的代码，则重新启动容器。您可以使用该httpHeaders选项定义要传输的任何自定义标头。
gRPC 处理程序：它在实践中有何用处？gRPC 协议正在成为云原生微服务之间通信的通用语言。如果您今天正在将 gRPC 应用程序部署到 Kubernetes，您可能想知道配置健康检查的最佳方式。
此示例演示如何2379使用 gRPC 健康检查协议检查端口响应能力。必须指定端口才能使用 gRPC 探测。如果健康端点设置在非默认服务上，您还必须指定服务。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-gRPC
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness:0.1
ports:
- containerPort: 2379
livenessProbe:
grpc:
port: 2379
initialDelaySeconds: 5
periodSeconds: 5
如果 gRPC 套接字挂掉并且 liveness 探测失败，容器将重新启动。
由于gRPC 内置探针没有错误代码，因此所有错误都被视为探针失败。
以错误的方式使用 liveness probes 可能会导致灾难请记住，如果 liveness 探测失败，容器将重新启动。与就绪探针不同，在活性探针中检查依赖关系并不是传统做法。
要确定容器本身是否已停止响应，应使用活性探测器。
活性探测的缺点是可能无法验证服务的响应能力。例如，如果一项服务维护两台 Web 服务器，一台用于服务路由，另一台用于状态路由，例如就绪性和活性探测或指标收集，则该服务可能会延迟或无法访问，而活性探测路由响应没有任何问题。活性探测器必须以与依赖服务类似的方式使用该服务才能使其有效。
就像就绪探测器一样，考虑随时间变化的动态是至关重要的。如果 liveness-probe 超时时间太短，响应时间的轻微增加（可能由负载的短暂上升引起）可能会迫使容器重新启动。重新启动可能会给支持该服务的其他 pod 带来更大的压力，从而导致进一步的活性探测故障级联并恶化该服务的整体可用性。
这些级联故障可以通过按客户端超时顺序配置活动探测超时并使用宽容failureThreshold计数来防止。
Liveness 探测可能有一个小问题，即容器启动延迟随时间变化（请参阅上面有关数学的信息）。随着服务的增长，资源分配的变化、网络拓扑结构的变化或负载的增加都可能导致这种情况。
如果initialDelaySeconds选项不足并且由于 Kubernetes 节点故障或 liveness 探测失败而导致容器重新启动，则应用程序可能永远不会启动或可能会在反复销毁和重新启动之前部分启动。容器的最大初始化时间应大于该initialDelaySeconds选项。
一些值得注意的建议是：- 将依赖项排除在活性探测之外。Liveness Probes 应该价格合理并且具有一致的响应时间。
- 为了使系统动态可以暂时或永久地改变而不会导致过多的活性探测失败，活性探测超时应该被保守地设置。考虑将客户端超时和 liveness-probe 超时设置为相同的值。
- 为了确保即使启动动态随时间变化也能可靠地重启容器，应保守地设置 initialDelaySeconds 选项。
通过在发现特定测试失败后自动重启容器，将活动探测器与就绪和启动探测器适当集成可以提高 Pod 的弹性和可用性。有必要理解应用程序以便为它们指定适当的替代方案。
