pod健康检查失败如何排查，pod检测

要想Pod好--健康检查少不了

深入解析kubernetes中的POD健康检查机制，确保服务可用性。从初次接触Kubernetes时的挫败经历开始，我们回顾了pod的生命周期、健康检查和重启策略。健康检查功能对于保障应用可用性和控制对外访问至关重要，分为存活探针、就绪探针和启动探针三种。选择合适探针需考虑应用启动阶段，确保应用在不同阶段都能顺利运行。

HTTP请求：向容器发起HTTP请求，根据响应状态码判断应用程序是否健康。 TCP连接：尝试与容器建立TCP连接，连接成功表示应用程序健康。 动作：若探测到应用程序不健康，kubelet将根据Pod配置中的重启策略进行重启。

在Kubernetes的生态系统中，Pod健康检查机制是确保容器健康运行的关键。默认情况下，kubelet依据容器运行状态来判断健康，但这不足以监控容器内部应用程序的健康状况，比如程序假死。由此引入了健康检查机制，它通过存活探测（livenessprobe）和就绪探测（readinessProbe）来监控容器的健康状态。

大概意思就是最开始前10s返回状态码200，10s过后就返回500的status_code了。所以当容器启动3秒后，kubelet开始执行健康检查。第一次健康监测会成功，因为是在10s之内，但是10s后，健康检查失败，因为现在返回的是一个错误的状态码了，所以kebelet将会杀掉和重启容器。

从入门到精通:掌握Kubernetes探针的使用技巧

探针参数如下：initialDelaySeconds，容器启动后第一次执行探测等待时间；periodSeconds，执行探测频率，默认10秒，最小1秒；timeoutSeconds，探测超时时间，最小1秒；successThreshold，探测失败后最少连续成功次数，最小值为1，liveness必须为1；failurethreshold，探测成功后最少连续失败次数，最小值为1。

Liveness Probe Liveness Probe 主要用于检测容器是否存活。当探测失败，Kubernetes 将自动重启容器，确保应用程序处于健康状态。

启动容器时，可以为 Kubernetes 配置一个等待时间，经过等待时间后才可以执行第 一次准备就绪检查。之后，它会周期性地调用探针，并根据就绪探针的结果采取行动。如果某个 pod 报告它尚未准备就绪，则会从该服务（Service）中删除该 pod。如果 pod 再次准备就绪，则重新添加 pod。

对于就绪探针，可以使用HTTP get请求作为检测方式。通过向容器的特定端口发送请求，并检查返回的状态码，Kubernetes可以判断容器是否已准备好接收流量。如果探测成功，容器将被标记为就绪；如果探测失败，则容器将被标记为未就绪。启动探针与就绪探针类似，但用于确保容器在启动后达到特定的状态。

云原生之K8S中Pod健康检测、服务可用性检查详解

通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器 健康 。 资源文件定义 访问8080端口，但是8080端口未开放，所以访问会超时，不能建立连接，命中检测，重启Pod 用于判断容器服务是否可用（Ready状态） ，达到Ready状态的Pod才可以接收请求。

健康 检测接口用于检测应用的 健康 状态，在K8S中，使用Readiness和Liveness分别来探测应用是否就绪和是否存活，如果未就绪或者未存活，K8S会采取相应的措施来确保应用可用。如果我们应用未定义好相应的 健康 检测接口，K8S就无法判断应用是否正常可用，整个应用对我们来说就是黑匣子，也就谈不上应用稳定性了。

Traefik 健康检查与故障转移依赖于健康检查机制，与 K8S 健康检查机制整合，确保负载均衡正常运行。部署方面，通过 docker 和 K8S 方式实现基本使用。Docker 下载镜像，创建配置文件，启动服务，测试请求验证响应。

CSI核心流程K8s在创建、挂载和卸载CSI存储卷时，经历以下阶段：创建卷（Provisioning）：管理员创建StorageClass，指定CSI插件。当用户创建PVC并指定StorageClass时，K8s为PVC添加特定注解。外部Provisioner根据注解创建PV。

Pod的健康检查

Pod健康检查是Kubernetes生态系统中确保容器健康运行的关键机制，主要包括存活探测和就绪探测。 存活探测： 目的：监控容器内部应用程序的健康状态，确保应用程序在异常情况下能被及时重启。 实现方式： 命令执行：通过执行容器内部的自定义命令，判断应用程序的健康状态。

在Kubernetes的生态系统中，Pod健康检查机制是确保容器健康运行的关键。默认情况下，kubelet依据容器运行状态来判断健康，但这不足以监控容器内部应用程序的健康状况，比如程序假死。由此引入了健康检查机制，它通过存活探测（livenessProbe）和就绪探测（readinessProbe）来监控容器的健康状态。

在下面的例子中，通过执行“cat /tmp/health”命令来判断一个容器运行是否正常。

K8S线上集群排查,实测排查node节点NotReady异常状态

1、K8S线上集群Node节点NotReady异常状态的排查方法主要包括以下几点：检查硬件资源：使用df m命令检查磁盘空间，确保有足够的空间供Node节点和Pod使用。使用free命令检查CPU使用率，确保CPU资源未被过度占用。使用top c命令查看CPU使用情况，确保无异常。

2、在项目中遇到的线上集群问题，特别是Kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中Pod的状态。

3、在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flannel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。

4、一次K8S集群中遇到的Too Many Open Files问题排查，起因是一个运行机器学习推理服务的节点出现Node NotReady异常，通过查看日志发现是因为dockerd进程打开的文件数过多导致。初步怀疑是由于root用户文件限制较小，将限制调整为655360后重启docker进程，但问题并未解决，而是陆续在其他节点上重复出现。