以下是針對CentOS系統上Kubernetes集群的系統性故障排查流程,涵蓋從集群狀態到具體組件的多個維度:
首先確認集群基礎狀態是否正常,這是排查故障的第一步:
kubectl get nodes命令,確保所有節點處于Ready狀態(若節點為NotReady,需進一步檢查kubelet服務);kubectl get pods --all-namespaces,關注Pending(調度失?。?、Error(運行錯誤)、CrashLoopBackOff(容器反復崩潰)等異常狀態的Pod。kubectl get events --sort-by=.metadata.creationTimestamp查看集群近期事件(如Pod調度失敗、節點資源不足等),事件會記錄故障的關鍵線索;journalctl查看Kubernetes核心組件的日志,定位具體錯誤:
journalctl -u kubelet -f(kubelet服務日志,涉及Pod生命周期管理);journalctl -u kube-proxy -f(kube-proxy服務日志,涉及網絡轉發);journalctl -u kube-apiserver -f(API Server日志,涉及集群控制平面操作)。網絡問題是Kubernetes常見故障類型,需重點排查:
ping <node-ip>測試節點之間網絡是否通暢;iptables -L檢查防火墻規則,確保Kubernetes相關端口(如6443/API Server、10250/kubelet)未被阻止;kubectl get pods -n kube-system查看插件Pod是否正常運行(狀態應為Running)。存儲問題會導致Pod無法啟動或數據丟失,需確認:
kubectl get pv(持久卷)、kubectl get pvc(持久卷聲明),確保PVC已綁定PV且狀態為Bound;kubectl get storageclass檢查存儲類是否正確配置(如默認存儲類是否存在);systemctl status nfs-server)。資源不足是Pod異常的常見原因,需監控節點與Pod的資源使用情況:
kubectl top nodes查看節點CPU、內存使用率;使用free -g(內存)、df -h(磁盤)確認系統資源是否充足;kubectl describe pod <pod-name>查看Pod的資源請求(requests)與限制(limits),若資源不足,需調整配置或擴容節點。容器日志能直接反映應用運行狀態,需精準定位:
kubectl logs <pod-name> -n <namespace>查看Pod內主容器日志;若Pod有多個容器,需指定容器名(kubectl logs <pod-name> -c <container-name> -n <namespace>);-f參數實時跟蹤日志輸出(如kubectl logs -f <pod-name>);kubectl exec -it <pod-name> -n <namespace> -- /bin/bash(若容器無bash,可替換為sh)。kubectl debug命令創建臨時調試Pod,進入容器環境檢查問題(如kubectl debug -it <pod-name> --image=busybox --target=<container-name>);node-problem-detector(Kubernetes官方工具),監控節點內核錯誤、硬件故障等問題,并通過Event上報。Kubernetes組件版本不兼容會導致集群異常,需確認:
kubectl version查看客戶端與服務端版本;dmesg -T查看內核日志(-T參數顯示人類可讀時間),檢查是否有與Kubernetes相關的內核錯誤(如網絡驅動問題);top(CPU)、free -m(內存)、iotop(磁盤IO)監控系統資源,排除系統級瓶頸。以上方法覆蓋了CentOS環境下Kubernetes故障排查的全流程,可根據具體故障現象選擇對應步驟逐步定位問題。操作前建議備份重要數據(如/etc/kubernetes目錄),避免誤操作影響集群穩定性。