pod启动失败排查命令？ pod 命令？

使用metrics-server监控k8s的资源指标

1、在部署文件的第 139 行，追加参数 --kubelet-insecure-tls。修改后的配置如下所示。完成参数添加后，重新部署文件。随后，检查 Pod 运行状态，确认已正常启动。执行 kubectl top 命令成功获取资源指标。同时，通过代码方式获取资源指标，如使用相关工具或编写脚本进行监控。最后，推荐使用 DHorse 进行部署和监控应用，它能够有效管理 k8s 环境。

2、prometheus Server：部署在指定的节点上。Node Exporter：在Kubernetes集群的每个节点上安装，用于收集节点级的监控数据。部署kubestatemetrics：位置：部署在指定的节点上。功能：收集kubernetes API服务器的数据，并将这些数据转换为Prometheus可以理解的格式，用于监控Kubernetes资源的状态。

3、首先，需要搭建环境，确保所有的组件（Prometheus Server、Node Exporter、cAdvisor、kube-state-metrics）都运行在各自指定的节点上。例如，Prometheus Server部署在IP为191621的节点上，而Kubernetes集群的节点（如1916221213）则需要安装Node Exporter，用于收集节点级的监控数据。

4、预定义的pod CPU利用率：这是最常见的指标，当POD的CPU使用率超过预设阈值时，触发缩扩容操作。自定义Pod的原始值计算：允许用户定义自己的metrics，如内存使用率、请求数等，用于触发缩扩容。自定义对象的metrics：适用于更复杂的场景，允许基于集群内其他资源的metrics进行缩扩容决策。

重启虚机后,k8s的kube-apiserver无法正常启动的问题

1、在重启设备后，执行 systemctl status kube-apiserver 命令时，未发现该服务，表明配置文件可能存在错误，因此决定对K8S集群进行重构。在master端检查pod时，发现flAnnel和coreDNS未启动，容器启动失败。

2、K8s的apiserver无法启动可能由证书过期、容器名冲突、配置文件错误或服务未找到/端口未监听等原因导致。 证书过期：在K8s集群中，如果相关的证书（如CA证书、apiserver证书等）过期，会导致apiserver无法启动。此时，需要检查集群中所有相关证书的有效期，并及时更新过期的证书。

3、kube-apiserver报错，错误如下：这个错误指明了是与apiserver通信时认证失败造成的，接着就去找哪个组件报错说无法获取apiserver的资源，但是查了kube-Controller-manager、kube-scheduler、kube-proxy和kubelet都没有找到相关的错误。

4、ImagePullBackoffKubernetes Pod启动失败原因之一是运行时无法从注册表中检索容器镜像。这种情况意味着Pod不会启动，因为清单中至少有一个容器无法启动。当Pod遇到此问题时，kubectl get pods命令将显示Pod状态为ImagePullBackOff。镜像名称或标签输入错误时，可能会发生此错误。

k8s中Pod状态及问题排查方法

含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

解决方法：仔细检查Pod的yaml配置文件，确保语法正确且配置合理。可以使用kubectl describe pod 命令查看Pod的详细信息，以获取更多关于错误的信息。总结：Pod状态一直处于Pending通常是由于资源不足、调度问题、镜像拉取问题、权限问题或配置错误等原因导致的。

如果原因是Pod无法安装请求的卷，请确保清单适当地指定其详细信息并确保Pod可以访问存储卷。或者，如果该节点没有足够的资源，则手动从该节点删除Pod，以便将Pod调度到另一个节点上。否则，可以扩展节点资源容量。如果使用nodeSelector安排Pod在Kubernetes集群中的特定节点上运行，就会发生这种情况。

Pod健康检查介绍

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

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

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

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