Kubernetes Pod故障诊断六步法：从Pending到CrashLoopBackOff的根因定位-北京尧图网络

简介本资源是一份面向Kubernetes运维工程师、云计算平台管理员及中高级DevOps实践者的故障排查实战笔记系统梳理k8s集群中五大类高频异常——连接异常集群级、通信异常网络插件/跨Pod、内部异常Node节点、应用异常代码/配置及典型Pod状态问题ContainerCreating、Pending、ImagePullBackOff等覆盖从现象识别、日志定位到根因修复的完整排错链路。文档为单个11.58MB的Word.docx文件结构清晰按五章组织每章含原理简析、故障归因、标准化诊断流程kubectlsystemctl日志组合命令及实操处置步骤如Node重置、Ceph插件安装、PV绑定排查等并附关键报错截图与处理思路总结。目前已有2879人学习下载适合需要快速响应生产环境故障、构建标准化排障能力的技术人员作为案头参考。1. 这不是“kubectl get pods 报错就重启 kubelet”的玄学笔记一份能直接抄进生产环境的 K8s 故障处理实战手册你刚收到告警coredns-7c5566588d-2x9fq状态是CrashLoopBackOffkubectl logs显示Loop (127.0.0.1:44222 - :53) detected for zone与此同时业务 Pod 全部Pendingkubectl describe node worker-03输出里赫然写着Taints: node.kubernetes.io/not-ready:NoSchedule更糟的是kubectl get pod -o wide里好几个 Pod 卡在ContainerCreatingdescribe一看全是FailedMount—— 后面跟着一行MountVolume.SetUp failed for volume ceph-pv : mount command failed...。这不是考试题这是凌晨两点你 Slack 里弹出的真实截图。这份文档不讲 Kubernetes 架构图、不画 control plane 数据流、不复述官方文档里“Pod 是最小调度单元”的定义。它只做一件事当你面对一个真实故障终端时手指该敲哪条命令、眼睛该盯哪行日志、心里该排除哪三类可能性。它覆盖了从ImagePullBackOff到Terminating的全状态链路把 51CTO 课程里零散的排查步骤拧成一条可执行、可验证、带参数解释和边界条件的流水线。适合刚通过 CKA 认证但没在千节点集群里修过半夜故障的运维工程师也适合想把 DevOps 流水线里“部署失败”环节从“重试三次”升级为“自动定位 root cause”的 SRE。它不承诺“一键修复”但保证你执行完每一步都能拿到一个明确的 yes/no 判断依据。2. Pod 全状态故障诊断流水线从 Pending 到 Terminating 的六步归因法Kubernetes 中 Pod 的状态不是装饰而是系统健康度的实时仪表盘。Running不代表服务可用Pending不等于资源不足CrashLoopBackOff更不是容器镜像的问题。真正的故障根因往往藏在状态转换的间隙里。本章将你手头那堆kubectl命令组装成一条有逻辑、有先后、有退出条件的诊断流水线。每一步都对应一个明确的决策点避免你在describe和logs之间无意义地反复横跳。2.1 第一步用kubectl get pod -o wide锁定物理锚点所有后续操作的前提是知道这个 Pod 被调度到了哪台物理节点Node上。这一步看似简单却是整个排查链的起点kubectl get pod nginx-deploy-5c7b4f8d9c-7xq2k -o wide # 输出示例 # NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES # nginx-deploy-5c7b4f8d9c-7xq2k 0/1 ContainerCreating 0 4m none worker-03 none none关键信息提取NODE列明确指向worker-03这是你接下来所有操作的物理靶心STATUS是ContainerCreating说明调度已完成但容器初始化卡在挂载或启动阶段IP为空印证了网络或存储层尚未就绪。为什么不能跳过如果你直接kubectl logs会得到Error from server (BadRequest): a container name must be specified for pod nginx-deploy-5c7b4f8d9c-7xq2k, choose one of: [nginx]—— 因为容器根本没创建出来logs命令连目标都没有。必须先确认 Node再深入该节点。2.2 第二步kubectl describe pod挖掘事件时间轴与资源约束describe是 Kubernetes 的“黑匣子”它不告诉你怎么修但会完整记录 Pod 从诞生到卡死的每一帧快照。重点不是通读而是按区块扫描kubectl describe pod nginx-deploy-5c7b4f8d9c-7xq2k输出中需聚焦三个区块Events事件时间轴这是最核心的线索区。查找Warning级别事件例如Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4m default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, 2 node(s) didnt match node selector. Warning FailedMount 3m50s kubelet, worker-03 MountVolume.SetUp failed for volume nfs-pv : mount failed: exit status 32解读逻辑FailedScheduling表明调度器已放弃原因直指node selector不匹配或节点污点而FailedMount则是ContainerCreating的直接原因且发生在worker-03上。两个 Warning 时间戳接近说明调度失败后系统尝试在其他节点调度未果最终落回worker-03并卡在挂载。Conditions状态条件检查Initialized、Ready、ContainersReady是否为True。若InitializedFalse说明 Init Container 失败需查Init Containers区块。Volumes卷配置核对PersistentVolumeClaim名称是否与kubectl get pvc输出一致StorageClass是否存在Access Modes如ReadWriteOnce是否与节点拓扑兼容。2.3 第三步登录目标 Node验证底层服务健康度当describe指向worker-03时你的战场立刻从控制平面切换到数据平面。此时kubectl已无能为力必须 SSH 登录该节点ssh worker-03 # 1. 检查 kubelet 服务状态它是 Node 上的“大脑” systemctl status kubelet --no-pager -l # 2. 检查容器运行时Docker 或 containerd systemctl status docker --no-pager -l # 若用 Docker # 或 systemctl status containerd --no-pager -l # 若用 containerd # 3. 检查系统资源瓶颈 free -h df -h top -bn1 | head -20参数说明与边界--no-pager -l强制输出完整日志避免less分页器截断关键错误df -h重点看/var/lib/kubelet/pods所在分区通常是/或/varUse%超过 85% 会触发 kubelet 自动驱逐top -bn1的load average若远超 CPU 核数说明节点已过载Pending状态大概率由此引发。血泪经验曾遇到kubelet状态显示active (running)但journalctl -u kubelet -n 100里滚动着failed to run Kubelet: unable to load bootstrap kubeconfig—— 这意味着证书失效systemctl restart kubelet只是徒劳必须重建 bootstrap token。2.4 第四步深挖 kubelet 日志定位挂载与网络根因describe中的FailedMount只是表象真正原因在 kubelet 日志里。路径因发行版和配置而异通用查找法# 查找最新 kubelet 日志文件CentOS/RHEL 习惯 ls -t /var/log/kubelet* | head -5 # 查看最近 200 行过滤关键词 journalctl -u kubelet -n 200 --no-pager | grep -E (mount|nfs|ceph|flannel|calico|error|failed) # 或直接 tail 日志文件 tail -n 200 /var/log/kubelet.log | grep -E (volume|attach|network)典型日志模式与对策rpc error: code Unavailable desc transport is closing常见于 etcd 集群脑裂或网络抖动需检查etcdctl endpoint healthnfs: RPC: Program not registeredNFS 客户端未安装yum install nfs-utilsCNI plugin not foundCNI 配置文件缺失或路径错误检查/etc/cni/net.d/下是否有.conf文件内容是否指向正确的插件二进制如/opt/cni/bin/flannelfailed to find plugin flannel in path [/opt/cni/bin]插件二进制缺失需从 flannel release 页面下载并chmod x。2.5 第五步跨组件联动验证——从 PV/PVC 到 StorageClass当挂载失败指向存储时单查 kubelet 日志不够必须向上游追溯 PV/PVC 绑定链# 1. 查看 PVC 状态与绑定详情 kubectl get pvc nginx-pvc -o wide # 输出关注 BOUND TO 列如default/nginx-pv kubectl describe pvc nginx-pvc # 2. 查看 PV 状态与节点亲和性 kubectl get pv nginx-pv -o wide kubectl describe pv nginx-pv # 3. 验证 StorageClass 动态供给能力 kubectl get sc nfs-sc -o yaml # 检查 provisioner 字段是否与实际部署的 provisioner 服务名一致如 nfs-subdir-external-provisioner.nfs-subdir-external-provisioner.svc.cluster.local避坑PV 绑定的四个致命陷阱现象kubectl get pvc显示Bound但 Pod 仍ContainerCreatingdescribe pod提示FailedAttachVolume。原因 1PV 的nodeAffinity与当前 Node 不匹配describe pv输出中nodeAffinity指定了topologyKey: topology.kubernetes.io/zone而worker-03的标签是topology.kubernetes.io/regioncn-north-1—— 区域与可用区不匹配导致无法挂载。解决kubectl edit pv nginx-pv修改nodeAffinity的topologyKey或values或给 Node 打上正确标签kubectl label node worker-03 topology.kubernetes.io/zonecn-north-1a。现象PVCBoundPVAvailabledescribe pv显示Reclaim Policy: Retain。原因 2PV 被手动删除后残留的 VolumeAttachment 对象kubectl get volumeattachment可能列出一个pending状态的va-xxx其spec.nodeName指向已下线的旧节点。解决kubectl delete volumeattachment va-xxx强制清理挂载残留。现象describe pvc显示VolumeMode: Block但应用容器内/dev/xvdb无法格式化。原因 3Block Volume 需要特权容器或特定 CSI 驱动支持检查 Pod YAML 中securityContext.privileged: true是否设置或 CSI 驱动是否启用block模式。解决改用Filesystem模式或升级 CSI 驱动版本。现象kubectl get sc显示nfs-sc存在但新 PVC 一直Pending。原因 4External Provisioner Deployment 的 ServiceAccount 权限不足kubectl describe deploy nfs-provisioner -n default查看Events若有FailedCreate且提示secrets is forbidden说明 RBAC 缺失。解决检查ClusterRoleBinding是否绑定到nfs-provisionerSA并确保ClusterRole包含secrets、persistentvolumes、persistentvolumeclaims的get/list/watch/create/delete权限。2.6 第六步状态终局判定与自动化脚本雏形完成前五步后你应能对 Pod 状态做出确定性归因。以下是一个可直接复用的 Bash 脚本框架它将上述逻辑封装为pod-diagnose.sh pod-name#!/bin/bash # pod-diagnose.sh: 快速定位 Pod 故障根因 POD_NAME$1 if [ -z $POD_NAME ]; then echo Usage: $0 pod-name exit 1 fi echo Step 1: Locate Node NODE$(kubectl get pod $POD_NAME -o jsonpath{.spec.nodeName}) echo Pod scheduled on node: $NODE echo Step 2: Describe Pod Events kubectl describe pod $POD_NAME 2/dev/null | awk /Events:/,/^\s*$/ {print} | grep -E (Warning|Normal) | head -10 echo Step 3: Check Node Resource Pressure ssh $NODE echo --- Memory ---; free -h; echo --- Disk ---; df -h /var/lib/kubelet; echo --- Load ---; uptime echo Step 4: Quick Kubelet Health ssh $NODE systemctl is-active kubelet; systemctl is-failed kubelet脚本价值它把人工判断压缩为grep -E (Warning|Normal)和systemctl is-failed这样的布尔值输出为后续接入 Prometheus Alertmanager 或 Jenkins Pipeline 埋下伏笔。真正的 SRE 不是记命令而是让命令自己说话。3. 网络故障的三层穿透法从 CNI 插件到 DNS 解析的深度排障Kubernetes 网络故障的恐怖之处在于它可能同时表现为Pod 无法访问外网、Service ClusterIP 无法解析、跨节点 Pod ping 不通三种症状而根因却只有一个——比如sysctl net.bridge.bridge-nf-call-iptables0。本章摒弃“先 ping 再 telnet”的粗放思路采用“控制平面 → 数据平面 → 应用平面”的三层穿透法每一层都提供可量化的验证手段和不可绕过的检查点。3.1 控制平面层验证 CNI 插件的部署完整性与配置一致性CNI 插件Calico/Flannel是集群网络的基石。它的故障不会报错只会让一切通信静默失效。验证必须从部署源头开始# 1. 检查 CNI 插件 Pod 状态以 Calico 为例 kubectl get pods -n kube-system | grep -E (calico|flannel) # 正常应为 Running且 READY 为 1/1 # 2. 检查 CNI 配置文件是否存在且语法正确 ssh master-node ls -l /etc/cni/net.d/ # 输出应包含 10-calico.conflist 或类似文件 ssh master-node cat /etc/cni/net.d/10-calico.conflist | jq .cniVersion # 验证 JSON 语法 # 3. 检查 Calico Node DaemonSet 的环境变量 kubectl get ds calico-node -n kube-system -o yaml | grep -A5 CALICO_IPV4POOL_CIDR # 确保 CIDR 与 kubeadm init 时指定的 pod-network-cidr 一致如 192.168.0.0/16关键参数说明CALICO_IPV4POOL_CIDR必须与kubeadm init --pod-network-cidr192.168.0.0/16完全一致否则 Calico 会分配冲突的 IPFELIX_IPINIPENABLED: true表示启用 IPIP 隧道适用于跨子网通信但会增加 20B 封包开销CALICO_NETWORKING_BACKEND: bird是 BGP 模式vxlan是隧道模式选择需与网络架构匹配。3.2 数据平面层抓包与路由追踪定位网络路径断裂点当kubectl exec -it busybox -- ping 10.96.0.10CoreDNS ClusterIP失败时问题不在 DNS而在网络路径。必须用tcpdump和ip route穿透三层# 在源 Pod 所在 Nodeworker-03上抓包 ssh worker-03 # 1. 找到 Pod 对应的 veth 接口假设 Pod IP 是 10.233.64.5 ip link show | grep -A1 veth.*5 # 输出如veth12345678if2 # 2. 抓取该 veth 接口的流量 tcpdump -i veth12345678 -n icmp -c 5 # 3. 同时在目标 Nodemaster-01上抓取 cali* 接口 ssh master-01 tcpdump -i cali001234567 -n icmp -c 5抓包结果解读若worker-03上有ICMP requestmaster-01上无任何包 → 问题在 CNI 隧道或 BGP 路由未建立若两端都有request但无reply→ 问题在目标 Pod 的 iptables 规则或网络策略NetworkPolicy若worker-03上无任何包 → 问题在 Pod 网络命名空间内的路由执行kubectl exec -it busybox -- ip route检查默认路由是否指向169.254.1.1 dev eth0Calico或10.233.64.1 dev eth0Flannel。路由追踪实操# 在 busybox Pod 内执行 kubectl exec -it busybox -- traceroute -n 10.96.0.10 # 正常应显示1 169.254.1.1 (Calico gateway) → 2 10.96.0.10 (CoreDNS) # 若卡在第一步说明 veth 到 host 的 bridge 未生效检查 brctl show 是否有 cni0/bridge0。3.3 应用平面层DNS 解析故障的精准切片与修复nslookup kubernetes.default.svc.cluster.local超时是最高频的故障。但corednsPod 状态为Running并不意味 DNS 正常。必须分层切片# 1. 验证 CoreDNS Pod 是否真在提供服务非仅状态 kubectl exec -it -n kube-system coredns-7c5566588d-2x9fq -- dig short kubernetes.default.svc.cluster.local 127.0.0.1 # 若返回空说明 CoreDNS 进程未监听或配置错误 # 2. 检查 CoreDNS 配置 ConfigMap kubectl get cm coredns -n kube-system -o yaml | grep -A10 forward # 关键字段forward . /etc/resolv.conf 表示将外部域名转发给宿主机 DNS # 3. 登录 CoreDNS Pod检查其挂载的宿主机 resolv.conf kubectl exec -it -n kube-system coredns-7c5566588d-2x9fq -- cat /etc/resolv.conf # 若包含 nameserver 127.0.0.1 → 必须修改这是死循环根源避坑DNS 故障的三大雷区现象dig 10.96.0.10 kubernetes.default.svc.cluster.local成功但nslookup失败。原因 1Pod 内 resolv.conf 的 search 域过多导致查询超时kubectl exec -it busybox -- cat /etc/resolv.conf输出search default.svc.cluster.local svc.cluster.local cluster.local当查询mysql时会依次尝试mysql.default.svc.cluster.local、mysql.svc.cluster.local、mysql.cluster.local最后一个超时拖垮整个查询。解决在 Pod YAML 中设置dnsConfig.searches精简为[default.svc.cluster.local]。现象dig 10.96.0.10 google.com超时但dig 114.114.114.114 google.com成功。原因 2CoreDNS forward 配置指向了错误的上游 DNSkubectl get cm coredns -n kube-system -o yaml中forward . 114.114.114.114被误写为forward . 127.0.0.1。解决kubectl edit cm coredns -n kube-system修正forward行保存后 CoreDNS 自动 reload。现象kubectl exec -it busybox -- nslookup kubernetes.default.svc.cluster.local返回server cant find kubernetes.default.svc.cluster.local: NXDOMAIN。原因 3CoreDNS 的 kubernetes 插件未启用或配置错误kubectl get cm coredns -n kube-system -o yaml中kubernetes cluster.local块缺失或pods insecure未设置。解决确保 ConfigMap 包含标准kubernetes块kubernetes cluster.local { pods insecure fallthrough in-addr.arpa ip6.arpa }3.4 网络策略NetworkPolicy的隐形杀手如何确认它正在生效NetworkPolicy是 Kubernetes 的防火墙但它默认不生效。很多“Pod 间无法通信”故障根源是用户启用了 Calico/Weave 等支持 NetworkPolicy 的 CNI却忘了部署calico-kube-controllers# 1. 检查 NetworkPolicy 控制器是否运行 kubectl get pods -n kube-system | grep controllers # 应看到 calico-kube-controllers-xxx # 2. 检查是否存在限制性 NetworkPolicy kubectl get networkpolicy --all-namespaces # 若输出非空且策略 spec.podSelector 匹配你的 Pod则需检查 ingress/egress # 3. 临时禁用策略验证生产慎用 kubectl delete networkpolicy policy-name -n namespace验证 NetworkPolicy 生效的黄金命令# 在源 Pod 内执行测试到目标 Service 的连通性 kubectl exec -it source-pod -- nc -zv nginx-svc 80 # 若返回 Connection refused说明网络可达但端口未开 # 若返回 timeout且 NetworkPolicy 存在则极大概率是策略阻断。3.5 Flannel VXLAN 模式的性能瓶颈与调优Flannel 默认的 VXLAN 模式虽简单但在高吞吐场景下会成为瓶颈。tcpdump抓包可见大量VXLAN封包iftop显示flannel.1接口流量远超业务需求# 1. 查看 Flannel 后端模式VXLAN 是默认 kubectl get cm kube-flannel-cfg -n kube-system -o yaml | grep backend # 2. 切换到性能更好的 host-gw 模式要求所有 Node 在同一二层网络 kubectl edit cm kube-flannel-cfg -n kube-system # 修改 backend.type: host-gw保存后删除 flannel Pod 触发重建 # 3. 验证模式切换成功 ssh worker-03 ip link show flannel.1 | grep -i vxlan\|host-gw # host-gw 模式下flannel.1 是普通 bridge无 VXLAN 封装开销调优参数说明host-gw模式要求所有 Node 的物理网卡在同一子网否则路由不可达DirectRouting模式Calico性能最优但需管理员配置 BGP Speaker复杂度高VXLAN 模式下可通过flanneld --ifaceeth1指定专用网卡避免业务流量争抢。4. 节点异常的硬核处置从 NotReady 到彻底重置的七步手术刀NodeNotReady不是警告而是集群的红色心跳暂停。它背后可能是磁盘爆满、kubelet 崩溃、内核 panic甚至是硬件故障。本章提供一套从诊断到根治的七步手术刀流程每一步都附带可执行的命令和不可妥协的退出条件。这不是“重启大法”而是精准切除病灶。4.1 第一步用kubectl describe node解析 NotReady 的元数据kubectl get node只显示NotReady真相藏在describe的细节里kubectl describe node worker-03重点关注三个区块Conditions状态条件查找ReadyFalse的原因如Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- Ready False 2023-10-05T02:15:22Z 2023-10-05T02:15:22Z KubeletNotReady runtime network not ready: NetworkReadyfalse reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized解读Reason: NetworkPluginNotReady直接指向 CNI 配置缺失而非 kubelet 本身故障。Allocatable可分配资源若allocatable.memory为0说明节点内存被耗尽kubelet 已触发eviction。Events事件查找NodeNotReady事件的时间戳与journalctl -u kubelet中的错误时间比对确认因果关系。4.2 第二步SSH 登录执行节点健康四件套一旦describe指向worker-03立即 SSH 登录执行标准化健康检查ssh worker-03 # 1. 检查 kubelet 进程与日志 systemctl status kubelet --no-pager -l | head -20 # 2. 检查容器运行时 systemctl status docker --no-pager -l | head -20 # 或 containerd # 3. 检查磁盘与 inode df -h df -i | awk $5 85 {print $0} # 4. 检查内存与 OOM killer dmesg -T | grep -i killed process | tail -5关键指标阈值df -i中Use%超过 90%说明大量小文件如容器日志、临时文件占满 inoderm -rf /var/log/containers/*可解燃眉之急dmesg输出Killed process xxx (java) total-vm:xxx, anon-rss:xxx, file-rss:xxx证明 OOM Killer 已介入需调整 Podresources.limits.memory或kubelet --eviction-hard参数。4.3 第三步kubelet 自检与证书续期systemctl status kubelet显示active (running)并不保险。kubelet 依赖 TLS 证书与 API Server 通信证书过期是NotReady的隐形杀手# 1. 检查 kubelet 证书有效期 openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text | grep -A1 Validity # 2. 检查 kubeconfig 证书 openssl x509 -in /etc/kubernetes/kubelet.conf -noout -text | grep -A1 Validity # 3. 若证书过期触发自动续期kubeadm 集群 sudo kubeadm certs renew kubelet sudo systemctl restart kubelet证书续期原理kubeadm certs renew会生成新证书并更新/var/lib/kubelet/pki/下的文件systemctl restart kubelet加载新证书。注意kubeadm init生成的证书默认 1 年有效期生产环境建议配置--cert-expiry10y。4.4 第四步CNI 插件深度修复——从配置到二进制当describe node显示NetworkPluginNotReady修复必须覆盖 CNI 全栈# 1. 检查 CNI 配置目录 ls -l /etc/cni/net.d/ # 应有 10-flannel.conflist 或 10-calico.conflist # 2. 检查 CNI 插件二进制 ls -l /opt/cni/bin/ # 必须有 flannel、loopback、portmap 等Flannel或 calico、loopbackCalico # 3. 重新部署 CNI以 Flannel 为例 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml # 4. 强制删除旧 Pod触发重建 kubectl delete pod -n kube-system -l appflannel避坑CNI 修复的四大死穴现象kubectl apply -f kube-flannel.yml后flannelPod 仍CrashLoopBackOff。原因 1Node 上缺少socat工具Flannel 的pre-starthook 依赖socat检查端口yum install socat即可。现象flannelPodRunning但kubectl get node仍NotReady。原因 2kubelet 启动参数未指定--cni-bin-dir/opt/cni/binps aux | grep kubelet查看启动命令若无此参数需编辑/var/lib/kubelet/kubeadm-flags.env添加--cni-bin-dir/opt/cni/bin然后systemctl restart kubelet。现象flannelPod 日志显示Failed to create SubnetManager: error retrieving pod spec for kube-system/kube-flannel-ds-amd64-xxxxx: Get https://10.96.0.1:443/api/v1/namespaces/kube-system/pods/kube-flannel-ds-amd64-xxxxx: dial tcp 10.96.0.1:443: i/o timeout。原因 3CoreDNS 未运行导致 Service ClusterIP 10.96.0.1 不可达先修复 CoreDNS再部署 Flannel。现象flannelPodRunning但ip addr show flannel.1无 IP。原因 4Flannel 配置中的Network与kubeadm init的--pod-network-cidr不一致kubectl get cm kube-flannel-cfg -n kube-system -o yaml中Network: 10.244.0.0/16必须与kubeadm init --pod-network-cidr10.244.0.0/16完全相同。4.5 第五步节点驱逐与安全重置的原子化操作当节点彻底不可用必须驱逐其上所有 Pod 并重置。kubeadm reset是危险操作必须原子化执行# 1. 驱逐所有 Pod保留 DaemonSet kubectl drain worker-03 --ignore-daemonsets --delete-local-data # 2. 在 worker-03 上执行重置务必在驱逐完成后 ssh worker-03 sudo kubeadm reset -f; sudo systemctl stop kubelet; sudo systemctl stop docker; sudo rm -rf /var/lib/kubelet/*; sudo rm -rf /etc/cni/net.d/; sudo ifconfig cni0 down; sudo ip link delete cni0; sudo systemctl start docker; sudo systemctl start kubelet; # 3. 重新加入集群获取新 token kubeadm token create --print-join-command # 输出如kubeadm join 192.168.1.100:6443 --token abc p a hrefhttps://download.csdn.net/download/qq_34953582/85727206 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p

Kubernetes Pod故障诊断六步法：从Pending到CrashLoopBackOff的根因定位

相关推荐

Kafka消费者组、Exactly-Once与事务：构建可靠消息链路的关键实践

空标题项目落地指南：从需求拆解到技术选型的实战方法论

MySQL命令实战指南：从安装部署到高并发故障排查

更多资讯

Python入门高频问题全解析：环境配置、导包、语法与并发

Ubuntu 20.04 WiFi 连接故障排查与 netplan/nmcli 实战配置

PPT公式导入XHEDITOR图文混排的完整方案：从格式探测到LaTeX渲染全链路实战

信息管理系统毕设全流程：从需求分析到Spring Boot+Vue项目落地

档案管理系统建设方案：用Word高效排版与自动化生成实战指南

Agent-Reach 实战：用 CLI 和 Python 打通 AI Agent 的触达层

今日更新

PHP htmlentities()函数用法讲解

AI Agent工程实战：从七要素到七个决策点的系统设计指南

AI入局芯片设计验证：验证收敛50倍加速的真相与应对

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？