1. 为什么“kubectl诊断命令”不是工具清单而是一套现场急救手册很多人第一次打开kubectl帮助文档看到kubectl get、kubectl describe、kubectl logs这些命令时下意识觉得“哦就是查点东西跟ls和cat差不多”。等真遇到 Pod 卡在Pending状态、Service 死活不通、Ingress 返回 503、或者 Deployment 滚动更新卡住不动——才猛然发现这些命令根本不是“查”而是“问诊”。你得知道该向哪个对象提问、问什么问题、怎么听它回答里的潜台词。我带过几期某高校的云原生实训课每次讲到诊断环节总有学员把kubectl get pods -A执行三遍截图发到群里说“都正常啊”结果一查describe发现 Events 里早写了FailedScheduling: 0/8 nodes are available: 8 Insufficient memory。这就是典型把“诊断”当“巡检”——只看表面状态不读系统反馈的病理信号。kubectl的诊断能力本质是 Kubernetes 控制平面与数据平面之间的一套标准化对话协议。每个命令背后都对应着 API Server 的特定资源视图、etcd 的状态快照、以及 kubelet 上的真实运行痕迹。它不像ping或curl那样只测通断而是能穿透四层抽象声明式配置 → 控制器 reconcile → 调度决策 → 容器运行一层层往下挖。比如kubectl rollout status不是简单轮询ReplicaSet数量而是监听Deployment的status.conditions字段变化kubectl wait的底层逻辑是 watch 一个资源的特定字段达到预期值而不是 sleep poll。所以这篇不叫“kubectl 常用命令速查表”而叫“常用 Kubernetes 诊断命令”——重点在“诊断”二字。它解决的不是“怎么打命令”而是“为什么打这个命令”“它在问谁”“回答里哪句话是关键病征”“如果答非所问下一步该换谁问”。我会按真实排障场景组织内容从集群层面健康检查到节点异常定位再到 Pod 启动失败的逐层拆解最后落到网络和服务连通性验证。每一步都附上我踩过的坑、实测有效的参数组合、以及那些官方文档里不会写的“潜规则”。你不需要背熟所有子命令但必须建立一套条件反射式的诊断路径看到什么现象 → 第一时间执行哪条命令 → 关注输出中哪几行 → 下一步该转向哪个对象。这才是真正能让你在凌晨三点面对告警时不慌、不乱、不瞎试的核心能力。2. 集群级健康扫描从kubectl get componentstatuses到kubectl cluster-info dump2.1componentstatuses的真相它早已名存实亡但仍有不可替代的价值很多老教程还在教kubectl get componentstatuses简称cs甚至把它列为“集群健康第一检”。但事实是自 Kubernetes v1.19 起cs已被标记为 deprecatedv1.22 彻底移除。原因很直接——它依赖的/healthz端点过于粗糙只能返回Healthy或Unhealthy二值结果且无法区分是 API Server 自身故障还是它依赖的 etcd 连接超时。更致命的是它完全不反映控制器管理器kube-controller-manager和调度器kube-scheduler的实际工作状态。这两个组件可能进程活着但因 leader election 失败或 informer 同步中断已停止处理任何事件。那是不是就该彻底抛弃它不。我在某公司生产环境排查一次持续 47 分钟的StatefulSet扩容失败时正是靠临时启用了--insecure-skip-tls-verify的cs命令快速确认了scheduler组件显示Unknown从而立刻锁定问题不在 etcd 或 API Server而在调度器自身。虽然它不能告诉你具体哪里坏了但它能帮你瞬间排除掉 70% 的干扰项。提示如果你的集群版本 v1.19cs仍可用但请务必配合kubectl get --raw/healthz?verbose使用。后者会返回详细健康检查链路例如[]ping ok []log ok []etcd ok []poststarthook/generic-apiserver-start-informers ok []poststarthook/start-apiextensions-controllers ok healthz check passed注意看etcd行——如果这里失败cs显示Unhealthy就有明确指向如果etcdOK 但cs仍Unhealthy问题大概率出在 API Server 的启动钩子poststarthook上。2.2kubectl cluster-info不只是地址更是控制平面的“心跳监测仪”kubectl cluster-info看似只是打印Kubernetes master和KubeDNS地址但它真正的价值在于“可连接性验证”。它的底层逻辑是尝试向~/.kube/config中当前 context 指定的server地址发起 HTTP GET 请求并检查响应头中的Content-Type: application/json和状态码是否为200。这意味着只要它能成功返回就证明三件事1你的 kubeconfig 配置正确2API Server 进程存活且监听端口3你的客户端网络能到达 API Server。我见过最典型的误用是运维同学在节点上执行cluster-info返回Unable to connect to the server第一反应是重启kube-apiserver。结果查了一圈发现是节点上的kube-proxy因配置错误未启动导致localhost:8080旧版 insecure port不可达——而他的kubeconfig恰好指向了这个地址。正确的做法是先执行kubectl config view --minify确认server:字段指向的是https://load-balancer-ip:6443这类高可用地址再检查本地网络策略是否放行了 6443 端口。注意cluster-info默认不验证证书。若需强制校验证书有效性加--insecure-skip-tls-verifyfalse参数注意是false不是true。这会触发标准 TLS 握手能暴露证书过期、域名不匹配等常见问题。2.3kubectl cluster-info dump诊断的“终极核武器”但必须学会精准引爆kubectl cluster-info dump是kubectl诊断体系里最强大也最危险的命令。它会导出整个集群的完整状态快照所有命名空间下的资源清单Pod、Service、ConfigMap 等、所有 Events、所有 Nodes 的详细信息、甚至 API Server 的启动参数。文件大小动辄数百 MB且包含敏感信息如 Secret 的 base64 编码值、ServiceAccount token。它的正确用法从来不是“全量 dump”而是“靶向采集”。核心技巧是使用--output-directory和--namespaces参数组合# 只导出 default 命名空间下与故障应用相关的资源 kubectl cluster-info dump \ --output-directory/tmp/diag-default \ --namespacesdefault \ --output-formatshort \ --include-namespacesdefault \ --exclude-resourcessecrets,serviceaccounts # 导出所有 Nodes 的详细信息不含 Pods kubectl cluster-info dump \ --output-directory/tmp/diag-nodes \ --use-protocol-buffersfalse \ --dump-node-logsfalse \ --dump-system-logsfalse \ --output-formatshort--output-formatshort是关键——它会跳过资源的metadata.managedFields和status字段大幅减小体积同时保留诊断必需的spec和metadata.annotations。--exclude-resources则用于剥离敏感资源避免安全审计风险。我在处理一次跨 AZ 的 Service 跨区访问延迟问题时就是靠cluster-info dump --namespaceskube-system --exclude-resourcespods,events快速获取了kube-proxyConfigMap 和所有Node的InternalIP、ExternalIP、Addresses字段最终发现某节点的InternalIP被错误配置为公网 IP导致kube-proxyiptables 规则生成异常。3. 节点级深度体检kubectl describe node与kubectl top node的协同解读3.1kubectl describe node一份浓缩的“节点病历”Events 是主诉Conditions 是体征kubectl describe node node-name的输出结构本身就是一份标准医疗报告。顶部的Name、Roles、Labels、Annotations是患者基本信息中间的Conditions是生命体征Ready、MemoryPressure、DiskPressure、PIDPressure、NetworkUnavailable下方的Addresses、Capacity、Allocatable是生理指标最底部的Events则是患者自述的主诉和病史。关键在于如何交叉比对。比如Conditions中Ready状态为False但Events里没有近期报错——这时要立刻检查kubectl get node node-name -o wide看INTERNAL-IP是否可达。我曾遇到一次ReadyFalseEvents空白最终发现是节点防火墙规则误删导致kubelet无法与 API Server 建立 websocket 连接kubelet日志里满屏dial tcp api-server-ip:6443: i/o timeout但describe不会显示这个。Capacity和Allocatable的差值是诊断资源争抢的黄金线索。Allocatable Capacity - Kube-reserved - System-reserved。如果Allocatable.memory比Capacity.memory少了整整 2Gi而你的kubelet启动参数里--system-reservedmemory1Gi那剩下的 1Gi 很可能被--kube-reserved占用。此时若 Pod 申请memory: 1.5Gi调度器会认为节点“内存充足”但实际运行时会因cgroup内存限制触发 OOMKilled。实操技巧用kubectl describe node | grep -A 5 Conditions:快速定位健康状态。重点关注Type: Ready对应的Status: True/False和Last Heartbeat Time。如果Last Heartbeat Time超过 40 秒未更新基本可判定kubelet与 API Server 失联。3.2kubectl top node不是“CPU 使用率”而是“节点负载压力指数”kubectl top node的数据来源是 Metrics Server它通过kubelet的/metrics/resource端点采集 cAdvisor 指标。这里有个巨大误区很多人把top node显示的cpu值当作 CPU 使用率百分比。错。它显示的是CPU 核心数的绝对值如320m 0.32 核单位是millicoresmmemory单位是字节如1.2Gi。真正的“压力”要看两个维度绝对值 vs Allocatabletop node的cpu值除以describe node中的Allocatable.cpu才是实际使用率。例如top node显示cpu: 2400mdescribe node显示Allocatable.cpu: 4则使用率为2.4 / 4 60%。历史趋势 vs 瞬时峰值top node是瞬时采样。我处理过一次“节点 CPU 100%”告警top node确实显示cpu: 3980m接近 4 核但kubectl top pod -A --sort-bycpu发现所有 Pod 加起来只用了2100m。最终定位是kubelet自身因大量evict操作导致 CPU 爆表——top node没骗人但top pod告诉你问题不在用户工作负载。kubectl top node --no-headers | awk {print $1, $2} | sort -k2 -nr | head -5这条命令能快速列出 CPU 消耗 Top5 的节点是横向对比节点负载的利器。配合kubectl get node -o wide的AGE字段还能发现新上线节点是否因kubelet初始化未完成导致top数据异常新节点top可能长时间为空。3.3kubectl get node -o wide与kubectl get node -o yaml从“宏观画像”到“基因图谱”kubectl get node -o wide是节点的“身份证”INTERNAL-IP、EXTERNAL-IP、OS-IMAGE、KERNEL-VERSION、CONTAINER-RUNTIME这些字段决定了它能跑什么、怎么跑、和谁通信。比如CONTAINER-RUNTIME: containerd://1.6.20意味着你要去/var/run/containerd/containerd.sock查容器如果是docker://20.10.23则要去/var/run/docker.sock。而kubectl get node -o yaml是节点的“基因图谱”里面藏着所有kubelet启动参数的镜像。重点看status.nodeInfo和spec字段status.nodeInfo.architecture和osImage告诉你能否运行 ARM 镜像status.nodeInfo.kernelVersion关系到 eBPF 程序兼容性spec.taints是调度的“禁区标识”NoSchedule类型污点会让 Pod 绕道而行status.allocatable的ephemeral-storage字段常被忽略却是EmptyDir和InitContainer磁盘空间的决定因素。我曾在一个混合架构集群里发现 x86 节点能正常运行的initContainer在 ARM 节点上始终CrashLoopBackOff。get node -o yaml显示status.nodeInfo.architecture: arm64但kubectl describe node的Conditions里NetworkUnavailable: True。顺藤摸瓜查到calico-nodeDaemonSet 的nodeSelector错误地指定了beta.kubernetes.io/archamd64导致 ARM 节点没部署网络插件——get node -o yaml的spec.taints里赫然写着node.kubernetes.io/network-unavailable:NoSchedule这就是describe node里NetworkUnavailable: True的根源。4. Pod 级故障精确定位kubectl describe pod的 Events 解码与kubectl logs的日志分层策略4.1kubectl describe podEvents 是时间线Status 是快照二者必须互证kubectl describe pod pod-name的输出是 Pod 故障诊断的“案发现场”。Events部分按时间倒序排列记录了从调度、拉镜像、创建容器到启动的全过程Status部分则是当前时刻的静态快照。二者必须交叉验证否则极易误判。经典案例Pod 状态为ImagePullBackOffEvents最后一条是Failed to pull image nginx:latest: rpc error: code Unknown desc failed to pull and unpack image docker.io/library/nginx:latest: failed to resolve reference docker.io/library/nginx:latest: failed to do request: Head https://registry-1.docker.io/v2/library/nginx/manifests/latest: dial tcp: lookup registry-1.docker.io on 10.96.0.10:53: read udp 10.244.1.10:53721-10.96.0.10:53: i/o timeout。表面看是 DNS 问题但Status里containerStatuses[0].state.waiting.reason是ImagePullBackOffmessage却写着Back-off pulling image nginx:latest。这里的关键是Events里的lookup registry-1.docker.io on 10.96.0.10:53——10.96.0.10是 CoreDNS 的 ClusterIP说明 DNS 查询请求发出去了但没收到响应。此时应立刻执行kubectl exec -it pod-name -- nslookup kubernetes.default.svc.cluster.local如果同样超时则确认是 CoreDNS 服务异常如果能解析则问题出在节点到 CoreDNS 的网络策略上。另一个高频陷阱是Pending状态。Events显示0/8 nodes are available: 8 node(s) had taints that the pod didnt tolerate.但Status的conditions里type: PodScheduled的status是False。这时不要急着删污点先kubectl get node --show-labels看节点labels是否缺失了 PodnodeSelector要求的标签。describe pod的Spec部分会清晰列出nodeSelector和tolerations而describe node的Labels和Taints是对照组。提示kubectl describe pod默认只显示最近 10 条 Events。如需查看更多加--show-events50参数。对于长期运行的 Pod建议用kubectl get events --field-selector involvedObject.namepod-name,involvedObject.namespacens获取全量事件流。4.2kubectl logs不止是--tail100而是分层日志采集的完整链条kubectl logs pod-name的默认行为是读取容器stdout和stderr的缓冲区。但生产环境的真相是日志远不止这一层。完整的日志链条包括应用层日志容器内进程写入 stdout/stderr 的日志kubectl logs主力容器运行时日志containerd或docker记录的容器生命周期事件crictl logs container-idkubelet 日志kubelet启动、停止、健康检查失败的日志journalctl -u kubelet -n 100系统日志内核 OOM Killer 日志dmesg -T | grep -i killed process。kubectl logs的核心参数是分层采集的钥匙--previous读取前一个容器实例的日志适用于 CrashLoopBackOff 场景--since1h按时间范围过滤避免海量日志刷屏--limit-bytes1048576限制单次读取大小防止 OOM-c container-name多容器 Pod 中指定容器describe pod的containerStatuses会列出所有容器名。我处理过一次诡异的InitContainer失败describe pod显示init-container-name状态为Completed但主容器卡在Waiting: PodInitializing。kubectl logs pod-name -c init-container-name为空。启用--previous后日志赫然出现timeout: failed to connect to database after 30s。原来 InitContainer 因数据库连接超时退出但退出码是 0脚本未正确处理超时kubelet认为它“成功完成”却忽略了它根本没达到初始化目标。这是--previous参数救场的经典案例。4.3kubectl logs的进阶-f流式跟踪与--prefix的上下文增强kubectl logs -f pod-name是实时跟踪的标配但容易忽略两个细节重连机制-f在网络抖动或 Pod 重建时会自动重连但重连后默认从最新日志开始丢失断连期间的日志。解决方案是加--since10s让每次重连都回溯 10 秒。多容器日志混杂kubectl logs -f pod-name -c app -c sidecar会将两个容器日志交织输出难以区分。此时--prefix参数是神器kubectl logs -f pod-name -c app -c sidecar --prefix会在每行日志前加上[app]或[sidecar]前缀瞬间理清日志归属。更进一步kubectl logs -f pod-name --since-time2023-10-01T12:00:00Z支持 RFC3339 时间戳适合在 Grafana 告警触发后精确回溯故障发生前后的日志。我习惯在 SRE 值班时把这条命令写成 aliasalias klogfkubectl logs -f --prefix --since30s30 秒窗口既能覆盖大部分瞬时故障又不会因日志过多卡顿。5. 网络与服务连通性验证kubectl port-forward、kubectl exec与curl的黄金三角5.1kubectl port-forward不是“端口映射”而是构建一条通往 Pod 的加密隧道kubectl port-forward pod-name 8080:80的本质是kubectl客户端在本地启动一个代理服务通过 API Server 的portforward子资源建立一条从本地8080端口到 Pod80端口的双向 TCP 隧道。这条隧道全程加密走 HTTPS且绕过了集群网络策略NetworkPolicy——因为流量不经过 CNI 插件而是由kube-apiserver和kubelet直接中转。这带来两个关键优势调试隔离你可以用curl http://localhost:8080/healthz直接测试 Pod 内部健康接口无需暴露 Service 或修改 NetworkPolicy协议穿透port-forward支持任意 TCP 协议不仅是 HTTP。kubectl port-forward pod-name 3306:3306可直连 MySQL Podkubectl port-forward pod-name 6379:6379可直连 Redis Pod。但陷阱在于port-forward的生命周期绑定于kubectl进程。一旦终端关闭或网络中断隧道即断。生产环境调试时我习惯加后台运行并用nohup保活nohup kubectl port-forward pod-name 8080:80 /dev/null 21 。更稳妥的做法是使用--address127.0.0.1默认或--address0.0.0.0允许局域网其他机器访问并配合socat做端口复用。注意port-forward不支持 UDP。若需调试 DNS 或 SIP 等 UDP 服务必须改用kubectl exec进入 Pod 执行nslookup或sip-test工具。5.2kubectl exec从“进入容器”到“模拟服务调用”的思维跃迁kubectl exec -it pod-name -- /bin/sh是入门操作但高手用法是把它变成“服务调用模拟器”。核心思路是在 Pod 内部用curl或telnet直接访问目标 Service验证 DNS 解析、网络连通性和后端服务状态。标准三步法DNS 解析验证kubectl exec pod-name -- nslookup my-service.default.svc.cluster.local。如果失败问题在 CoreDNS 或 Service 名称拼写TCP 连通性验证kubectl exec pod-name -- telnet my-service.default.svc.cluster.local 80。如果Connected说明网络和 Service 端口开放如果Connection refused说明后端 Pod 未监听该端口或 ServicetargetPort配置错误HTTP 层验证kubectl exec pod-name -- curl -v http://my-service.default.svc.cluster.local/healthz。-v参数显示完整 HTTP 交互包括响应头、重定向、TLS 握手详情。我处理过一次 Service 503 问题exec内curl返回503 Service Unavailable但describe service显示Endpoints正常。深入exec进入kube-proxyPod执行curl -v http://10.244.2.5:8080/healthz10.244.2.5是后端 Pod IP发现超时。最终定位是节点iptables规则被第三方安全软件篡改kube-proxy的KUBE-SERVICES链被跳过。5.3curl在集群内的“隐身模式”-H Host: xxx与--resolve的实战价值当 Service 使用Ingress且配置了host规则时curl http://my-service.default.svc.cluster.local可能返回404因为后端应用依赖Host头路由。此时kubectl exec内的curl必须带上Host头kubectl exec pod-name -- curl -H Host: my-app.example.com http://my-service.default.svc.cluster.local。更高级的技巧是--resolvekubectl exec pod-name -- curl --resolve my-app.example.com:80:10.96.123.45 http://my-app.example.com。10.96.123.45是 Service 的 ClusterIP。这相当于在 Pod 内部的 DNS 解析器里强行将my-app.example.com解析到该 IP绕过 CoreDNS直接验证 Service 到后端的链路。这在排查IngressController 与 Service 之间的 DNS 配置错误时是最快捷的验证方式。另一个隐藏技巧curl -k跳过 TLS 证书验证在调试 HTTPS Service 时必不可少。kubectl exec pod-name -- curl -k -v https://my-secure-service.default.svc.cluster.local-v会显示证书详情帮你确认是否用了正确的证书或是否因证书过期导致握手失败。6. 高级诊断组合技kubectl wait、kubectl rollout与自定义--field-selector的精准打击6.1kubectl wait告别while true; do kubectl get ...; sleep 2; done的原始时代kubectl wait是 Kubernetes 1.11 引入的声明式等待命令它用watch机制监听资源状态变化而非低效的轮询。其核心价值在于“条件触发”而非“时间等待”。基础语法kubectl wait --forconditioncondition-type resource-type/name。condition-type是关键不同资源支持的 condition 不同Pod:Initialized,Ready,ContainersReady,StartedDeployment:Available,Progressing,ReplicaFailurePersistentVolumeClaim:Bound最实用的组合是--forjsonpath{.status.phase}Running它能等待 Pod 进入Running阶段但describe pod显示phase: Running时容器可能还在Waiting状态。此时应改用--forconditionReady它等待的是status.conditions[?(.typeReady)].status True这才是真正的“就绪”。我编写 CI/CD 流水线时用kubectl wait --forconditionAvailable --timeout300s deployment/my-app替代了 shell 脚本轮询不仅提速 5 倍还消除了因sleep时间设置不当导致的误判。--timeout是安全阀避免无限等待。提示kubectl wait支持--all-namespaces和--selector可批量等待。kubectl wait --forconditionReady pod --selectorappmy-app --timeout120s会等待所有带appmy-app标签的 Pod 就绪。6.2kubectl rollout不只是status而是 Deployment 的“全生命周期仪表盘”kubectl rollout status deployment/name是滚动更新的“进度条”但它背后是监听Deployment的status.conditions字段。当type: Progressing的status为True时表示更新正在进行type: Available的status为True时表示新版本已就绪。但真正的高手用法是kubectl rollout history和kubectl rollout undo。rollout history不仅显示 revision还显示CHANGE-CAUSE如果设置了--record参数。kubectl set env deployment/my-app DEBUGtrue --recordrollout history就会记录kubectl set env deployment/my-app DEBUGtrue方便回溯变更。rollout undo的默认行为是回滚到上一个 revision但--to-revision2可指定任意 revision。更关键的是--dry-runclient -o yamlkubectl rollout undo deployment/my-app --to-revision2 --dry-runclient -o yaml会输出回滚后的 Deployment YAML让你在真正执行前预览所有变更避免误操作。我处理过一次因maxSurge设置过大导致节点资源耗尽的事故。rollout status显示Waiting for rollout to finish: 1 old replicas are pending termination...。rollout history显示当前 revision 3上一个 revision 2 的CHANGE-CAUSE是kubectl scale deployment/my-app --replicas10。立刻执行rollout undo --to-revision2并在回滚后用kubectl patch deployment/my-app -p {spec:{strategy:{rollingUpdate:{maxSurge:1,maxUnavailable:1}}}}修复策略。6.3--field-selectorkubectl的“SQL WHERE 子句”实现资源的精准狙击--field-selector是kubectl最被低估的高级功能它允许你基于资源的metadata字段进行服务器端过滤大幅减少客户端数据传输量。语法是--field-selector key1value1,key2value2。常用 field-selectormetadata.namename精确匹配名称metadata.namespacens限定命名空间比-n更底层status.phasePending筛选特定状态的 Podspec.nodeNamenode-name筛选运行在指定节点的 Podstatus.reasonEvicted筛选被驱逐的 Pod。实战案例排查一次大规模 Pod 驱逐事件。kubectl get pods --all-namespaces太慢且混杂大量正常 Pod。执行kubectl get pods --all-namespaces --field-selector status.reasonEvicted --outputwide瞬间列出所有被驱逐的 Pod 及其所在节点、驱逐时间。再结合kubectl describe node node-name的Conditions快速确认是DiskPressure导致。另一个妙用是--field-selector metadata.deletionTimestampkubectl get pods --all-namespaces --field-selector metadata.deletionTimestamp列出所有处于Terminating状态的 Pod帮助识别卡住的删除操作。配合kubectl get pods --all-namespaces --field-selector metadata.deletionTimestamp --outputjson | jq .items[] | select(.metadata.deletionTimestamp ! null) | .metadata.name可提取所有卡住 Pod 的名称批量清理。注意field-selector不支持模糊匹配或正则。如需name包含某字符串必须用kubectl get pods -A | grep pattern客户端过滤或改用--selector基于 labels。7. 诊断之外建立可持续的排障能力——我的个人经验与工具链沉淀7.1 诊断命令不是终点而是起点如何把kubectl输出转化为可复用的知识资产我坚持一个原则每一次成功的故障排查都必须沉淀为三条可执行资产一条可复用的诊断命令比如kubectl get pods --all-namespaces --field-selector status.phasePending --outputwide我把它保存为alias kget-pendingkubectl get pods --all-namespaces --field-selector status.phasePending --outputwide一份结构化的问题模板在团队 Wiki 创建《Pod 启动失败排查清单》按Pending、ContainerCreating、CrashLoopBackOff、ImagePullBackOff分类每类下列出必执行的 3 条命令及预期输出一个自动化检测脚本用 Bash 封装kubectl命令加入超时、重试、结果判断。例如check-cluster-health.sh会依次执行cluster-info、top node、get cs兼容旧集群、get events --sort-by.lastTimestamp并汇总成 HTML 报告。最有效的沉淀方式是把kubectl命令嵌入到kubectl插件中。Kubernetes 1.12 支持kubectl plugin机制。我开发了一个kubectl-diag插件输入kubectl diag pod pod-name它会自动执行describe podlogs --previousexec -- nslookup service-nameget events --field-selector involvedObject.namepod-name并将所有输出按模块整理到一个 Markdown 文件中附带分析建议。这比手动敲 10 条命令高效得多。7.2 避免“命令依赖症”理解kubectl
1. 为什么“kubectl诊断命令”不是工具清单而是一套现场急救手册很多人第一次打开kubectl帮助文档看到kubectl get、kubectl describe、kubectl logs这些命令时下意识觉得“哦就是查点东西跟ls和cat差不多”。等真遇到 Pod 卡在Pending状态、Service 死活不通、Ingress 返回 503、或者 Deployment 滚动更新卡住不动——才猛然发现这些命令根本不是“查”而是“问诊”。你得知道该向哪个对象提问、问什么问题、怎么听它回答里的潜台词。我带过几期某高校的云原生实训课每次讲到诊断环节总有学员把kubectl get pods -A执行三遍截图发到群里说“都正常啊”结果一查describe发现 Events 里早写了FailedScheduling: 0/8 nodes are available: 8 Insufficient memory。这就是典型把“诊断”当“巡检”——只看表面状态不读系统反馈的病理信号。kubectl的诊断能力本质是 Kubernetes 控制平面与数据平面之间的一套标准化对话协议。每个命令背后都对应着 API Server 的特定资源视图、etcd 的状态快照、以及 kubelet 上的真实运行痕迹。它不像ping或curl那样只测通断而是能穿透四层抽象声明式配置 → 控制器 reconcile → 调度决策 → 容器运行一层层往下挖。比如kubectl rollout status不是简单轮询ReplicaSet数量而是监听Deployment的status.conditions字段变化kubectl wait的底层逻辑是 watch 一个资源的特定字段达到预期值而不是 sleep poll。所以这篇不叫“kubectl 常用命令速查表”而叫“常用 Kubernetes 诊断命令”——重点在“诊断”二字。它解决的不是“怎么打命令”而是“为什么打这个命令”“它在问谁”“回答里哪句话是关键病征”“如果答非所问下一步该换谁问”。我会按真实排障场景组织内容从集群层面健康检查到节点异常定位再到 Pod 启动失败的逐层拆解最后落到网络和服务连通性验证。每一步都附上我踩过的坑、实测有效的参数组合、以及那些官方文档里不会写的“潜规则”。你不需要背熟所有子命令但必须建立一套条件反射式的诊断路径看到什么现象 → 第一时间执行哪条命令 → 关注输出中哪几行 → 下一步该转向哪个对象。这才是真正能让你在凌晨三点面对告警时不慌、不乱、不瞎试的核心能力。2. 集群级健康扫描从kubectl get componentstatuses到kubectl cluster-info dump2.1componentstatuses的真相它早已名存实亡但仍有不可替代的价值很多老教程还在教kubectl get componentstatuses简称cs甚至把它列为“集群健康第一检”。但事实是自 Kubernetes v1.19 起cs已被标记为 deprecatedv1.22 彻底移除。原因很直接——它依赖的/healthz端点过于粗糙只能返回Healthy或Unhealthy二值结果且无法区分是 API Server 自身故障还是它依赖的 etcd 连接超时。更致命的是它完全不反映控制器管理器kube-controller-manager和调度器kube-scheduler的实际工作状态。这两个组件可能进程活着但因 leader election 失败或 informer 同步中断已停止处理任何事件。那是不是就该彻底抛弃它不。我在某公司生产环境排查一次持续 47 分钟的StatefulSet扩容失败时正是靠临时启用了--insecure-skip-tls-verify的cs命令快速确认了scheduler组件显示Unknown从而立刻锁定问题不在 etcd 或 API Server而在调度器自身。虽然它不能告诉你具体哪里坏了但它能帮你瞬间排除掉 70% 的干扰项。提示如果你的集群版本 v1.19cs仍可用但请务必配合kubectl get --raw/healthz?verbose使用。后者会返回详细健康检查链路例如[]ping ok []log ok []etcd ok []poststarthook/generic-apiserver-start-informers ok []poststarthook/start-apiextensions-controllers ok healthz check passed注意看etcd行——如果这里失败cs显示Unhealthy就有明确指向如果etcdOK 但cs仍Unhealthy问题大概率出在 API Server 的启动钩子poststarthook上。2.2kubectl cluster-info不只是地址更是控制平面的“心跳监测仪”kubectl cluster-info看似只是打印Kubernetes master和KubeDNS地址但它真正的价值在于“可连接性验证”。它的底层逻辑是尝试向~/.kube/config中当前 context 指定的server地址发起 HTTP GET 请求并检查响应头中的Content-Type: application/json和状态码是否为200。这意味着只要它能成功返回就证明三件事1你的 kubeconfig 配置正确2API Server 进程存活且监听端口3你的客户端网络能到达 API Server。我见过最典型的误用是运维同学在节点上执行cluster-info返回Unable to connect to the server第一反应是重启kube-apiserver。结果查了一圈发现是节点上的kube-proxy因配置错误未启动导致localhost:8080旧版 insecure port不可达——而他的kubeconfig恰好指向了这个地址。正确的做法是先执行kubectl config view --minify确认server:字段指向的是https://load-balancer-ip:6443这类高可用地址再检查本地网络策略是否放行了 6443 端口。注意cluster-info默认不验证证书。若需强制校验证书有效性加--insecure-skip-tls-verifyfalse参数注意是false不是true。这会触发标准 TLS 握手能暴露证书过期、域名不匹配等常见问题。2.3kubectl cluster-info dump诊断的“终极核武器”但必须学会精准引爆kubectl cluster-info dump是kubectl诊断体系里最强大也最危险的命令。它会导出整个集群的完整状态快照所有命名空间下的资源清单Pod、Service、ConfigMap 等、所有 Events、所有 Nodes 的详细信息、甚至 API Server 的启动参数。文件大小动辄数百 MB且包含敏感信息如 Secret 的 base64 编码值、ServiceAccount token。它的正确用法从来不是“全量 dump”而是“靶向采集”。核心技巧是使用--output-directory和--namespaces参数组合# 只导出 default 命名空间下与故障应用相关的资源 kubectl cluster-info dump \ --output-directory/tmp/diag-default \ --namespacesdefault \ --output-formatshort \ --include-namespacesdefault \ --exclude-resourcessecrets,serviceaccounts # 导出所有 Nodes 的详细信息不含 Pods kubectl cluster-info dump \ --output-directory/tmp/diag-nodes \ --use-protocol-buffersfalse \ --dump-node-logsfalse \ --dump-system-logsfalse \ --output-formatshort--output-formatshort是关键——它会跳过资源的metadata.managedFields和status字段大幅减小体积同时保留诊断必需的spec和metadata.annotations。--exclude-resources则用于剥离敏感资源避免安全审计风险。我在处理一次跨 AZ 的 Service 跨区访问延迟问题时就是靠cluster-info dump --namespaceskube-system --exclude-resourcespods,events快速获取了kube-proxyConfigMap 和所有Node的InternalIP、ExternalIP、Addresses字段最终发现某节点的InternalIP被错误配置为公网 IP导致kube-proxyiptables 规则生成异常。3. 节点级深度体检kubectl describe node与kubectl top node的协同解读3.1kubectl describe node一份浓缩的“节点病历”Events 是主诉Conditions 是体征kubectl describe node node-name的输出结构本身就是一份标准医疗报告。顶部的Name、Roles、Labels、Annotations是患者基本信息中间的Conditions是生命体征Ready、MemoryPressure、DiskPressure、PIDPressure、NetworkUnavailable下方的Addresses、Capacity、Allocatable是生理指标最底部的Events则是患者自述的主诉和病史。关键在于如何交叉比对。比如Conditions中Ready状态为False但Events里没有近期报错——这时要立刻检查kubectl get node node-name -o wide看INTERNAL-IP是否可达。我曾遇到一次ReadyFalseEvents空白最终发现是节点防火墙规则误删导致kubelet无法与 API Server 建立 websocket 连接kubelet日志里满屏dial tcp api-server-ip:6443: i/o timeout但describe不会显示这个。Capacity和Allocatable的差值是诊断资源争抢的黄金线索。Allocatable Capacity - Kube-reserved - System-reserved。如果Allocatable.memory比Capacity.memory少了整整 2Gi而你的kubelet启动参数里--system-reservedmemory1Gi那剩下的 1Gi 很可能被--kube-reserved占用。此时若 Pod 申请memory: 1.5Gi调度器会认为节点“内存充足”但实际运行时会因cgroup内存限制触发 OOMKilled。实操技巧用kubectl describe node | grep -A 5 Conditions:快速定位健康状态。重点关注Type: Ready对应的Status: True/False和Last Heartbeat Time。如果Last Heartbeat Time超过 40 秒未更新基本可判定kubelet与 API Server 失联。3.2kubectl top node不是“CPU 使用率”而是“节点负载压力指数”kubectl top node的数据来源是 Metrics Server它通过kubelet的/metrics/resource端点采集 cAdvisor 指标。这里有个巨大误区很多人把top node显示的cpu值当作 CPU 使用率百分比。错。它显示的是CPU 核心数的绝对值如320m 0.32 核单位是millicoresmmemory单位是字节如1.2Gi。真正的“压力”要看两个维度绝对值 vs Allocatabletop node的cpu值除以describe node中的Allocatable.cpu才是实际使用率。例如top node显示cpu: 2400mdescribe node显示Allocatable.cpu: 4则使用率为2.4 / 4 60%。历史趋势 vs 瞬时峰值top node是瞬时采样。我处理过一次“节点 CPU 100%”告警top node确实显示cpu: 3980m接近 4 核但kubectl top pod -A --sort-bycpu发现所有 Pod 加起来只用了2100m。最终定位是kubelet自身因大量evict操作导致 CPU 爆表——top node没骗人但top pod告诉你问题不在用户工作负载。kubectl top node --no-headers | awk {print $1, $2} | sort -k2 -nr | head -5这条命令能快速列出 CPU 消耗 Top5 的节点是横向对比节点负载的利器。配合kubectl get node -o wide的AGE字段还能发现新上线节点是否因kubelet初始化未完成导致top数据异常新节点top可能长时间为空。3.3kubectl get node -o wide与kubectl get node -o yaml从“宏观画像”到“基因图谱”kubectl get node -o wide是节点的“身份证”INTERNAL-IP、EXTERNAL-IP、OS-IMAGE、KERNEL-VERSION、CONTAINER-RUNTIME这些字段决定了它能跑什么、怎么跑、和谁通信。比如CONTAINER-RUNTIME: containerd://1.6.20意味着你要去/var/run/containerd/containerd.sock查容器如果是docker://20.10.23则要去/var/run/docker.sock。而kubectl get node -o yaml是节点的“基因图谱”里面藏着所有kubelet启动参数的镜像。重点看status.nodeInfo和spec字段status.nodeInfo.architecture和osImage告诉你能否运行 ARM 镜像status.nodeInfo.kernelVersion关系到 eBPF 程序兼容性spec.taints是调度的“禁区标识”NoSchedule类型污点会让 Pod 绕道而行status.allocatable的ephemeral-storage字段常被忽略却是EmptyDir和InitContainer磁盘空间的决定因素。我曾在一个混合架构集群里发现 x86 节点能正常运行的initContainer在 ARM 节点上始终CrashLoopBackOff。get node -o yaml显示status.nodeInfo.architecture: arm64但kubectl describe node的Conditions里NetworkUnavailable: True。顺藤摸瓜查到calico-nodeDaemonSet 的nodeSelector错误地指定了beta.kubernetes.io/archamd64导致 ARM 节点没部署网络插件——get node -o yaml的spec.taints里赫然写着node.kubernetes.io/network-unavailable:NoSchedule这就是describe node里NetworkUnavailable: True的根源。4. Pod 级故障精确定位kubectl describe pod的 Events 解码与kubectl logs的日志分层策略4.1kubectl describe podEvents 是时间线Status 是快照二者必须互证kubectl describe pod pod-name的输出是 Pod 故障诊断的“案发现场”。Events部分按时间倒序排列记录了从调度、拉镜像、创建容器到启动的全过程Status部分则是当前时刻的静态快照。二者必须交叉验证否则极易误判。经典案例Pod 状态为ImagePullBackOffEvents最后一条是Failed to pull image nginx:latest: rpc error: code Unknown desc failed to pull and unpack image docker.io/library/nginx:latest: failed to resolve reference docker.io/library/nginx:latest: failed to do request: Head https://registry-1.docker.io/v2/library/nginx/manifests/latest: dial tcp: lookup registry-1.docker.io on 10.96.0.10:53: read udp 10.244.1.10:53721-10.96.0.10:53: i/o timeout。表面看是 DNS 问题但Status里containerStatuses[0].state.waiting.reason是ImagePullBackOffmessage却写着Back-off pulling image nginx:latest。这里的关键是Events里的lookup registry-1.docker.io on 10.96.0.10:53——10.96.0.10是 CoreDNS 的 ClusterIP说明 DNS 查询请求发出去了但没收到响应。此时应立刻执行kubectl exec -it pod-name -- nslookup kubernetes.default.svc.cluster.local如果同样超时则确认是 CoreDNS 服务异常如果能解析则问题出在节点到 CoreDNS 的网络策略上。另一个高频陷阱是Pending状态。Events显示0/8 nodes are available: 8 node(s) had taints that the pod didnt tolerate.但Status的conditions里type: PodScheduled的status是False。这时不要急着删污点先kubectl get node --show-labels看节点labels是否缺失了 PodnodeSelector要求的标签。describe pod的Spec部分会清晰列出nodeSelector和tolerations而describe node的Labels和Taints是对照组。提示kubectl describe pod默认只显示最近 10 条 Events。如需查看更多加--show-events50参数。对于长期运行的 Pod建议用kubectl get events --field-selector involvedObject.namepod-name,involvedObject.namespacens获取全量事件流。4.2kubectl logs不止是--tail100而是分层日志采集的完整链条kubectl logs pod-name的默认行为是读取容器stdout和stderr的缓冲区。但生产环境的真相是日志远不止这一层。完整的日志链条包括应用层日志容器内进程写入 stdout/stderr 的日志kubectl logs主力容器运行时日志containerd或docker记录的容器生命周期事件crictl logs container-idkubelet 日志kubelet启动、停止、健康检查失败的日志journalctl -u kubelet -n 100系统日志内核 OOM Killer 日志dmesg -T | grep -i killed process。kubectl logs的核心参数是分层采集的钥匙--previous读取前一个容器实例的日志适用于 CrashLoopBackOff 场景--since1h按时间范围过滤避免海量日志刷屏--limit-bytes1048576限制单次读取大小防止 OOM-c container-name多容器 Pod 中指定容器describe pod的containerStatuses会列出所有容器名。我处理过一次诡异的InitContainer失败describe pod显示init-container-name状态为Completed但主容器卡在Waiting: PodInitializing。kubectl logs pod-name -c init-container-name为空。启用--previous后日志赫然出现timeout: failed to connect to database after 30s。原来 InitContainer 因数据库连接超时退出但退出码是 0脚本未正确处理超时kubelet认为它“成功完成”却忽略了它根本没达到初始化目标。这是--previous参数救场的经典案例。4.3kubectl logs的进阶-f流式跟踪与--prefix的上下文增强kubectl logs -f pod-name是实时跟踪的标配但容易忽略两个细节重连机制-f在网络抖动或 Pod 重建时会自动重连但重连后默认从最新日志开始丢失断连期间的日志。解决方案是加--since10s让每次重连都回溯 10 秒。多容器日志混杂kubectl logs -f pod-name -c app -c sidecar会将两个容器日志交织输出难以区分。此时--prefix参数是神器kubectl logs -f pod-name -c app -c sidecar --prefix会在每行日志前加上[app]或[sidecar]前缀瞬间理清日志归属。更进一步kubectl logs -f pod-name --since-time2023-10-01T12:00:00Z支持 RFC3339 时间戳适合在 Grafana 告警触发后精确回溯故障发生前后的日志。我习惯在 SRE 值班时把这条命令写成 aliasalias klogfkubectl logs -f --prefix --since30s30 秒窗口既能覆盖大部分瞬时故障又不会因日志过多卡顿。5. 网络与服务连通性验证kubectl port-forward、kubectl exec与curl的黄金三角5.1kubectl port-forward不是“端口映射”而是构建一条通往 Pod 的加密隧道kubectl port-forward pod-name 8080:80的本质是kubectl客户端在本地启动一个代理服务通过 API Server 的portforward子资源建立一条从本地8080端口到 Pod80端口的双向 TCP 隧道。这条隧道全程加密走 HTTPS且绕过了集群网络策略NetworkPolicy——因为流量不经过 CNI 插件而是由kube-apiserver和kubelet直接中转。这带来两个关键优势调试隔离你可以用curl http://localhost:8080/healthz直接测试 Pod 内部健康接口无需暴露 Service 或修改 NetworkPolicy协议穿透port-forward支持任意 TCP 协议不仅是 HTTP。kubectl port-forward pod-name 3306:3306可直连 MySQL Podkubectl port-forward pod-name 6379:6379可直连 Redis Pod。但陷阱在于port-forward的生命周期绑定于kubectl进程。一旦终端关闭或网络中断隧道即断。生产环境调试时我习惯加后台运行并用nohup保活nohup kubectl port-forward pod-name 8080:80 /dev/null 21 。更稳妥的做法是使用--address127.0.0.1默认或--address0.0.0.0允许局域网其他机器访问并配合socat做端口复用。注意port-forward不支持 UDP。若需调试 DNS 或 SIP 等 UDP 服务必须改用kubectl exec进入 Pod 执行nslookup或sip-test工具。5.2kubectl exec从“进入容器”到“模拟服务调用”的思维跃迁kubectl exec -it pod-name -- /bin/sh是入门操作但高手用法是把它变成“服务调用模拟器”。核心思路是在 Pod 内部用curl或telnet直接访问目标 Service验证 DNS 解析、网络连通性和后端服务状态。标准三步法DNS 解析验证kubectl exec pod-name -- nslookup my-service.default.svc.cluster.local。如果失败问题在 CoreDNS 或 Service 名称拼写TCP 连通性验证kubectl exec pod-name -- telnet my-service.default.svc.cluster.local 80。如果Connected说明网络和 Service 端口开放如果Connection refused说明后端 Pod 未监听该端口或 ServicetargetPort配置错误HTTP 层验证kubectl exec pod-name -- curl -v http://my-service.default.svc.cluster.local/healthz。-v参数显示完整 HTTP 交互包括响应头、重定向、TLS 握手详情。我处理过一次 Service 503 问题exec内curl返回503 Service Unavailable但describe service显示Endpoints正常。深入exec进入kube-proxyPod执行curl -v http://10.244.2.5:8080/healthz10.244.2.5是后端 Pod IP发现超时。最终定位是节点iptables规则被第三方安全软件篡改kube-proxy的KUBE-SERVICES链被跳过。5.3curl在集群内的“隐身模式”-H Host: xxx与--resolve的实战价值当 Service 使用Ingress且配置了host规则时curl http://my-service.default.svc.cluster.local可能返回404因为后端应用依赖Host头路由。此时kubectl exec内的curl必须带上Host头kubectl exec pod-name -- curl -H Host: my-app.example.com http://my-service.default.svc.cluster.local。更高级的技巧是--resolvekubectl exec pod-name -- curl --resolve my-app.example.com:80:10.96.123.45 http://my-app.example.com。10.96.123.45是 Service 的 ClusterIP。这相当于在 Pod 内部的 DNS 解析器里强行将my-app.example.com解析到该 IP绕过 CoreDNS直接验证 Service 到后端的链路。这在排查IngressController 与 Service 之间的 DNS 配置错误时是最快捷的验证方式。另一个隐藏技巧curl -k跳过 TLS 证书验证在调试 HTTPS Service 时必不可少。kubectl exec pod-name -- curl -k -v https://my-secure-service.default.svc.cluster.local-v会显示证书详情帮你确认是否用了正确的证书或是否因证书过期导致握手失败。6. 高级诊断组合技kubectl wait、kubectl rollout与自定义--field-selector的精准打击6.1kubectl wait告别while true; do kubectl get ...; sleep 2; done的原始时代kubectl wait是 Kubernetes 1.11 引入的声明式等待命令它用watch机制监听资源状态变化而非低效的轮询。其核心价值在于“条件触发”而非“时间等待”。基础语法kubectl wait --forconditioncondition-type resource-type/name。condition-type是关键不同资源支持的 condition 不同Pod:Initialized,Ready,ContainersReady,StartedDeployment:Available,Progressing,ReplicaFailurePersistentVolumeClaim:Bound最实用的组合是--forjsonpath{.status.phase}Running它能等待 Pod 进入Running阶段但describe pod显示phase: Running时容器可能还在Waiting状态。此时应改用--forconditionReady它等待的是status.conditions[?(.typeReady)].status True这才是真正的“就绪”。我编写 CI/CD 流水线时用kubectl wait --forconditionAvailable --timeout300s deployment/my-app替代了 shell 脚本轮询不仅提速 5 倍还消除了因sleep时间设置不当导致的误判。--timeout是安全阀避免无限等待。提示kubectl wait支持--all-namespaces和--selector可批量等待。kubectl wait --forconditionReady pod --selectorappmy-app --timeout120s会等待所有带appmy-app标签的 Pod 就绪。6.2kubectl rollout不只是status而是 Deployment 的“全生命周期仪表盘”kubectl rollout status deployment/name是滚动更新的“进度条”但它背后是监听Deployment的status.conditions字段。当type: Progressing的status为True时表示更新正在进行type: Available的status为True时表示新版本已就绪。但真正的高手用法是kubectl rollout history和kubectl rollout undo。rollout history不仅显示 revision还显示CHANGE-CAUSE如果设置了--record参数。kubectl set env deployment/my-app DEBUGtrue --recordrollout history就会记录kubectl set env deployment/my-app DEBUGtrue方便回溯变更。rollout undo的默认行为是回滚到上一个 revision但--to-revision2可指定任意 revision。更关键的是--dry-runclient -o yamlkubectl rollout undo deployment/my-app --to-revision2 --dry-runclient -o yaml会输出回滚后的 Deployment YAML让你在真正执行前预览所有变更避免误操作。我处理过一次因maxSurge设置过大导致节点资源耗尽的事故。rollout status显示Waiting for rollout to finish: 1 old replicas are pending termination...。rollout history显示当前 revision 3上一个 revision 2 的CHANGE-CAUSE是kubectl scale deployment/my-app --replicas10。立刻执行rollout undo --to-revision2并在回滚后用kubectl patch deployment/my-app -p {spec:{strategy:{rollingUpdate:{maxSurge:1,maxUnavailable:1}}}}修复策略。6.3--field-selectorkubectl的“SQL WHERE 子句”实现资源的精准狙击--field-selector是kubectl最被低估的高级功能它允许你基于资源的metadata字段进行服务器端过滤大幅减少客户端数据传输量。语法是--field-selector key1value1,key2value2。常用 field-selectormetadata.namename精确匹配名称metadata.namespacens限定命名空间比-n更底层status.phasePending筛选特定状态的 Podspec.nodeNamenode-name筛选运行在指定节点的 Podstatus.reasonEvicted筛选被驱逐的 Pod。实战案例排查一次大规模 Pod 驱逐事件。kubectl get pods --all-namespaces太慢且混杂大量正常 Pod。执行kubectl get pods --all-namespaces --field-selector status.reasonEvicted --outputwide瞬间列出所有被驱逐的 Pod 及其所在节点、驱逐时间。再结合kubectl describe node node-name的Conditions快速确认是DiskPressure导致。另一个妙用是--field-selector metadata.deletionTimestampkubectl get pods --all-namespaces --field-selector metadata.deletionTimestamp列出所有处于Terminating状态的 Pod帮助识别卡住的删除操作。配合kubectl get pods --all-namespaces --field-selector metadata.deletionTimestamp --outputjson | jq .items[] | select(.metadata.deletionTimestamp ! null) | .metadata.name可提取所有卡住 Pod 的名称批量清理。注意field-selector不支持模糊匹配或正则。如需name包含某字符串必须用kubectl get pods -A | grep pattern客户端过滤或改用--selector基于 labels。7. 诊断之外建立可持续的排障能力——我的个人经验与工具链沉淀7.1 诊断命令不是终点而是起点如何把kubectl输出转化为可复用的知识资产我坚持一个原则每一次成功的故障排查都必须沉淀为三条可执行资产一条可复用的诊断命令比如kubectl get pods --all-namespaces --field-selector status.phasePending --outputwide我把它保存为alias kget-pendingkubectl get pods --all-namespaces --field-selector status.phasePending --outputwide一份结构化的问题模板在团队 Wiki 创建《Pod 启动失败排查清单》按Pending、ContainerCreating、CrashLoopBackOff、ImagePullBackOff分类每类下列出必执行的 3 条命令及预期输出一个自动化检测脚本用 Bash 封装kubectl命令加入超时、重试、结果判断。例如check-cluster-health.sh会依次执行cluster-info、top node、get cs兼容旧集群、get events --sort-by.lastTimestamp并汇总成 HTML 报告。最有效的沉淀方式是把kubectl命令嵌入到kubectl插件中。Kubernetes 1.12 支持kubectl plugin机制。我开发了一个kubectl-diag插件输入kubectl diag pod pod-name它会自动执行describe podlogs --previousexec -- nslookup service-nameget events --field-selector involvedObject.namepod-name并将所有输出按模块整理到一个 Markdown 文件中附带分析建议。这比手动敲 10 条命令高效得多。7.2 避免“命令依赖症”理解kubectl
单位体系与能量-力一致性新手完全指南)
