从半夜报警到十分钟定位故障：我用这25条K8s命令把线上服务救回来了
那次半夜三点，报警一串接一串，我心里像打翻了水桶。说实话，刚开始我也慌了，但回想起来最蠢的不是报警，而是没有第一时间确认上下文。先别急着重启任何东西，先用 kubectl config get-contexts 看看你究竟在操作哪个集群，接着用 kubectl config current-context 再确认一遍。我朋友小李当年就是在错误的 kubeconfig 上执行了 drain，导致生产流量短时中断，教训很深。记住这个顺序，许多灾难都能在最初的三分钟里被扼杀。
定位节点问题时，不要直接去删 Pod，先看全局信息。用 kubectl cluster-info 获取 API Server 状态，接着 kubectl get nodes -o wide 看节点 IP、角色和版本。如果某个节点异常，再用 kubectl describe node 找 CPU、内存、磁盘压力或 taint，必要时先把节点 cordon 掉，命令是 kubectl cordon ，等待排空后用 kubectl drain –ignore-daemonsets 迁出普通 Pod。说实话，drain 是救急利器，但也容易把状态ful应用拖垮，别忘了检查 PodDisruptionBudget，别用力过猛。
当 Pod 出问题，日志和事件是最直接的答案。先用 kubectl get pods –all-namespaces -o wide 看全局 Pod 状态，再用 kubectl describe pod 看事件和调度信息。若是多容器 Pod，用 kubectl logs -c 精准拉日志，想实时观察就用 kubectl logs -f 。有一次我同事张姐遇到 CrashLoopBackOff，她是先看 describe 才发现镜像拉取失败，缘由是 secret 过期，更新 secret 后用 kubectl rollout restart deployment 很快让服务回稳。
对于 Deployment 的溯源操作，历史版本和回滚是必备技能。用 kubectl rollout history deployment 看修订记录，若新镜像出问题可以用 kubectl rollout undo deployment 回退。想强制替换镜像时，用 kubectl set image deployment/ =，再用 kubectl rollout status deployment 监控更新进度。别把所有改动都直接在集群上做测试，先在命名空间里做灰度会安全得多。
网络和服务层面的问题常常隐藏得更深。用 kubectl get svc -o wide 和 kubectl get endpoints 来验证服务是否正确指向后端 Pod，遇到 DNS 解析疑问可以在任一 Pod 里执行 kubectl exec -it — nslookup 进行验证。端口转发用于本地调试超级方便，kubectl port-forward 8080:80 可以让你像访问本地服务一样调试 Pod 内部接口，不用每次都开外网或改 Ingress。
命名空间和权限常常被忽视，但它们决定了你能不能安全操作。用 kubectl get ns 看资源隔离情况，创建命名空间用 kubectl create ns ，查看角色和绑定用 kubectl get role -n 与 kubectl get rolebinding -n 。我见过一个线上事故，是由于同一组人既有创建权限又没有审计流程，资源被随手改了配置才引发的连锁反应。把权限最小化并搭配审计，会让集群更可控。
YAML 的导出与回滚是工程化运维的基础。需要把现有资源备份时，用 kubectl get -o yaml > file.yaml 导出，修改好再用 kubectl apply -f file.yaml 或 kubectl replace –force -f file.yaml 强制重建。自动化场景下，批量操作可以写成小脚本，例如在命名空间 myns 里批量重启所有 Deployment，我常用的写法是：for deploy in $(kubectl get deploy -n myns -o jsonpath='{.items[*].metadata.name}'); do kubectl rollout restart deploy $deploy -n myns; done。脚本能救命，但写脚本前先在一个非生产环境试一次。
观测缺失是许多故障反复出现的根源。先用 kubectl get events -A 排查集群事件，把事件时间按时间戳排序能快速定位变更源；若想看资源使用，kubectl top pod -A 和 kubectl top nodes 能告知你是否存在资源争抢，但这依赖 metrics-server，别忘了在集群里部署它。我的一个项目由于没有 metrics-server，团队在 CPU 抖动时根本看不到实时消耗，直到上了监控才把问题解决在萌芽期。
工具和流程同样重大。kubectx 能帮你快速切换上下文和命名空间，减少误操作概率；stern 在查看多 Pod 日志时超级高效，k9s 能在终端里像 GUI 那样管理资源，Lens 适合做桌面级诊断。说白了，熟练掌握一套工具链比记住一大堆命令更有价值。而长期来看，GitOps 和声明式运维会把许多手工操作变成可审计的流水线，但当流水线出问题时，上面这些命令依旧是快速破局的利器。
最后给出我常用的排障心法：先定上下文，再看事件流，最后抓日志与 metrics，然后快速回滚或隔离。这个顺序听起来平淡，但在慌乱时能让你少犯错。如果你想把这些命令变成肌肉记忆，可以把常用命令写到自定义脚本或在团队 Wiki 里做带场景的 SOP，遇到类似事故只按步骤走。未来几年云原生会走向更高的自动化和托管化，但排障的逻辑不会变，能把这些基础命令熟练运用的人依旧最值钱。
你最近一次让你记忆深刻的 K8s 故障是什么，最后你是怎么一步步把它解决的，说说你的细节和当时做过的命令吧？
暂无评论内容