pod健康检查失败原因？ pod容器健康检查？

K8S容器编排之Pod健康检测(1)

1、Kubernetes通过两种探针机制来监控pod的健康状态：LivenessProbe和ReadinessProbe。LivenessProbe关注容器是否存活，即使容器运行但无法正常响应请求，也会被重启；ReadinessProbe则检查容器是否准备好接收请求，不响应的POD会被从服务的Endpoint中移除。

2、运行超过30s后。文件被删除，所以被 健康 检测命中，pod根据重启策略重启 99s后已经从起了第二次 查看节点机docker中的容器ID，前后不一样，确定是POD被杀掉后重启。通过容器的IP地址、端口号及路径调用HTTP get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康 。

3、水平Pod自动伸缩和垂直Pod自动伸缩：根据需求自动调整Pod的数量和资源。集群自动伸缩：根据集群负载自动调整集群规模。镜像源和Pod优先级：控制镜像源：确保所有容器的镜像源可控，保证安全性。Pod优先级：决定不同服务运行的重要性，确保关键服务优先运行。

4、而在k8s使用的时候，会有的设计的是，将tomcat作为一个不变的镜像（它也不应该改变）而把 war 包作为另外一个容器，而这样个容器同时挂载同一个目录，将 webAPP 挂载的目录与 war包挂载的目录相同来达到目的，然后将他们放到同一个 pod 中。

K8s中Pod生命周期和重启策略

1、K8s中Pod生命周期包括五种状态，重启策略有三种。Pod生命周期状态： Pending：API Server已创建Pod，但容器镜像尚未运行。 Running：Pod中的所有容器都在运行中或正在启动中。 Succeeded：Pod中的所有容器已成功退出，并且不会重启。 Failed：Pod中的所有容器都已退出，且至少有一个容器是异常退出的。

2、Always策略：无论正常或非正常停止，容器均会重启。例如，正常关闭Tomcat服务后，Pod状态恢复正常，而非正常关闭时，容器会重启。Never策略：正常或非正常停止，容器都不会重启。停止Tomcat后，正常情况下容器状态保持，非正常时显示Error状态。

3、重启策略有三种：Always、OnFailure和Never。如果设置为Always，那么无论因为什么原因停止，Pod都会自动重启。如果设置为OnFailure，则只有Pod非正常停止时（例如，因为崩溃或被杀死）才会重启。如果设置为Never，则Pod在任何情况下都不会自动重启。

4、重启Pod：通常是由Pod内部的故障或错误触发的。当Pod中的容器因为某些原因（如程序崩溃、资源不足等）异常退出时，K8s会根据预设的重启策略（restartPolicy）来决定是否重启该Pod。这里的重启策略包括Always（总是重启容器）、OnFailure（当容器异常退出时重启容器）和Never（从不重启容器）^[1][2]^。

5、在Pod层面配置共享Volume，允许所有容器访问，保留持久数据，即使容器重启。容器间共享IP与端口空间，通过localhost相互发现。多容器Pod示例展示了共处容器与资源的打包管理，以及容器间通信与协调。Pod中设置重启策略，如Always，降低应用中断时间，适用于所有容器。

6、容器在其生命周期内也有Waiting、Running和Terminated等状态，以及针对不同状态的具体原因（Reason）描述。例如，容器状态为Terminated且原因CrashLoopBackoff，表示容器由于某种异常退出后，系统试图重启容器。

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

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

2、kubectl-debug的日常用法包括简单使用、进阶使用和自定义镜像配置。简单使用需要kubectl 10或更高版本，支持从PATH中自动发现插件。进阶使用包括排错init-container、诊断DNS解析、使用tcpdump抓包等。自定义镜像配置可以通过配置文件~/.kube/debug-config修改默认参数。

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

nginx内存配置报存

1、原因：缓存配置不当或后端响应异常。解决办法：检查缓存目录权限，限制单文件缓存大小，并启用gzip压缩来减少内存占用。系统级资源限制：原因：操作系统或容器平台对Nginx进程内存限制过低。

2、需升级至64位Nginx，并确保系统内存充足。php内存耗尽：PHP默认内存限制不足。可修改php.ini中的memory_limit，重启Nginx和PHP - FPM。配置文件BOM头错误：Windows记事本编辑配置文件添加了UTF - 8 BOM头，导致报错。需用工具将文件编码改为UTF - 8无BOM格式并重新保存。

3、缓存配置： proxycachepath命令：这是启用Nginx缓存的关键步骤，需要在最顶层的http节点下设置。它用于指定缓存保存的本地路径和共享内存区域的名称与大小。 内存区大小：proxycachepath命令中配置的内存区大小仅为缓存元数据的加载大小，而非限制缓存数据大小。如需限制缓存数据上限，需添加maxsize参数。

4、proxy_cache缓存设置#注：proxy_temp_path和proxy_cache_path指定的路径必须在同一分区proxy_temp_path /data0/proxy_temp_dir；#设置Web缓存区名称为cache_one，内存缓存空间大小为200MB，1天没有被访问的内容自动清除，硬盘缓存空间大小为30GB。

5、原理： 配置数据存储：配置数据通常存储在配置文件中。当配置需要变更时，更新配置文件，然后程序会自动重新加载这些配置。 热更新机制：与nginx的配置重载机制不同，一个类nginx工具可以通过监听一个本地端口来实现配置数据的热更新。这种方式既安全又实时，因为可以查看内存中的实时配置状态。

6、注意，在新老配置进程交替过程中，新老进程是同时存在的，如果是异常的请求出了问题，客户端长时间没有处理，会导致请求长时间占用在内存中，worker进程就会一直存在，解决这个问题的办法设置，可以设置worker_shutdown_timeout解决。

Pod健康检查介绍

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

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

3、Kubernetes通过两种探针机制来监控Pod的健康状态：LivenessProbe和ReadinessProbe。LivenessProbe关注容器是否存活，即使容器运行但无法正常响应请求，也会被重启；ReadinessProbe则检查容器是否准备好接收请求，不响应的Pod会被从服务的Endpoint中移除。

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

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

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

3、在实际应用中，通过合理配置这些探针，如使用LivenessProbe进行健康检查，可以确保容器运行正常。LivenessProbe支持通过执行shell命令、HTTP访问或TCP连接进行检查。而ReadinessProbe则用于判断容器是否准备好接收请求。StartupProbe则专注于容器启动阶段的稳定性，确保容器在启动后达到预期状态。

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

5、首先，我们来看看三种探针的使用场景和目的。ReadinessProbe和LivenessProbe用于监控应用健康性和稳定性，确保服务可用。StartupProbe则在容器启动阶段监控应用状态，确保在容器启动后应用能够正常运行。ReadinessProbe和LivenessProbe的使用方式支持多种探测方法，包括exec、HTTP和TCP。