k8s强制停止pod（k8s强制删除pod命令）

k8s删除Pod一直处于Terminating状态

我这里的pod是与nfs有关，nfs挂载有问题导致POD有问题，执行完删除命令以后看到pod一直处于terminating的状态。这种情况下可以使用强制删除命令：kubectl delete pod [pod name] --force --grace-period=0 -n [namespace]注意：必须加-n参数指明naMESpace，否则可能报错pod not found。

K8S故障检查-Pod处于ContainerCreating状态

常见导致pod长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackoff”事件，表明镜像拉取存在问题。

面对k8s应用卡在ContainerCreating状态的困扰，我通过kubectl describe po命令获取到了关键的日志信息。

ContainerCreating：这种情况表示容器正在创建中，常见于配置问题导致的容器创建失败。例如，当使用docker服务时，可能会遇到节点上的kube-proxy、kubelet或docker服务重启后容器仍无法创建的情况。解决这类问题，通常需要检查服务的运行状态，确认资源是否充足，或者是否存在网络、存储配置问题。

一个pod的完整创建，通常会伴随着各种事件的产生，k8s种事件的种类总共只有4种：PodStatus 有一组PodConditions。PodCondition中的ConditionStatus，它代表了当前pod是否处于某一个阶段（PodScheduled，Ready，Initialized，Unschedulable），“true” 表示处于，“false”表示不处于。

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

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

要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe Node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。

Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。

查看节点机docker中的容器ID，前后不一样，确定是POD被杀掉后重启。通过容器的IP地址、端口号及路径调用HTTP get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康 。

在面临Docker容器被频繁kill掉，以及k8s中该节点pod被驱赶的情况时，要找出问题的根源，关键在于深入分析容器的运行状态、内存使用情况以及系统资源的分配状况。以下为解决此类问题时，可以采取的步骤与工具，帮助您更直观地找出问题所在。首先，要从容器输出和状态详情入手。

...容器经常被kill掉,k8s中该节点的pod也被驱赶,怎么分析?

在面临Docker容器被频繁kill掉，以及k8s中该节点pod被驱赶的情况时，要找出问题的根源，关键在于深入分析容器的运行状态、内存使用情况以及系统资源的分配状况。以下为解决此类问题时，可以采取的步骤与工具，帮助您更直观地找出问题所在。首先，要从容器输出和状态详情入手。

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

Pod被调度后，节点需拉取镜像以创建容器。拉取失败可能由镜像地址配置错误、集群免密配置问题、网络不通（公网访问策略、专有网络配置、镜像加速）、带宽不足或镜像体积过大导致。依赖项错误 常见错误状态：Error 在Pod启动前，Kubelet检查依赖关系，如PersistentVolume、ConfigMap和Secret。

宿主节点行为：如果Pod没有资源限制，可能会在宿主机中安装模拟内存不回收的工具，如bigmem。当分配内存时，宿主机用户使用内存增加，可用内存减少。当申请内存超过宿主机可用内存时，bigmem所在进程会被kill。查看宿主机日志可以发现，这是由cgroup限制触发的OOMKilled。

异常场景分析 调度失败 常见错误状态：Unschedulable 当Pod创建后进入调度阶段，Kubernetes调度器依据Pod的资源需求和调度规则选择节点。如果所有节点都无法满足Pod的需求，Pod将进入Pending状态。

K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据

首先，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。使用iptables跟踪请求路径，发现流量未经过预期路径，而是进入INPUT链，指向DNAT问题。

当 Pod 状态为 CrashLoopBackOff 时，表示容器在启动后立即崩溃或退出。这可能是容器配置错误、应用程序错误、内存不足或权限问题导致。排查此类问题时，需详细检查容器配置、应用程序日志、内存使用情况及权限设置。Pod 状态为 Failed 通常意味着容器已终止，并且至少一个容器以失败方式退出。

在。Pod 只要挂载持久化数据卷，Pod 重启之后数据还是会存在的。Pod 是 Kubernetes 中的最小调度单元，k8s 是通过定义一个 Pod 的资源，然后在 Pod 里面运行容器，容器需要指定一个镜像，这样就可以用来运行具体的服务。

Evicted：资源不足导致，需要监控存储和内存使用。CrashLoopBackOff：容器异常退出后又立即重启。Pod的重启策略通过spec字段的restartPolicy设定，常见值有Always（默认，异常退出即重启）、OnFailure（退出码非0时重启）和Never（不重启）。

当pod出现crash状态，容器频繁重启，使用kubelet logs 方法可能无法获取到所需日志时，可以采用kubectl previous参数进行解决。该参数的使用原理基于kubelet在pod失败后会保留前几个容器的失败记录。这为后续查看提供了前提条件。

在重启设备后，执行 systemctl status kube-apiserver 命令时，未发现该服务，表明配置文件可能存在错误，因此决定对K8S集群进行重构。在master端检查pod时，发现flAnnel和coreDNS未启动，容器启动失败。查看日志后，发现错误信息显示在Kubernetes集群中使用的Flannel网络插件遇到了问题，无法获取到所需的子网租约。

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进程，但问题并未解决，而是陆续在其他节点上重复出现。

5、Kubernetes 13 OS： CentOS 2009 Kernel： 94-elelrepo.x86_64 Docker： 6 线上告警提示集群中存在 2-3 个 K8s 节点处于 NotReady 的状态，并且 NotReady 状态一直持续。问题的解决可以通过两种方法，我们先来看看 A 方案。