核心組件(API Server、Controller Manager、Scheduler、etcd)是Kubernetes集群的“大腦”,其健康狀態直接決定集群能否正常運行。
kubectl get componentstatuses
Healthy
(如scheduler Healthy ok
、controller-manager Healthy ok
、etcd-0 Healthy {"health":"true"}
)。若出現Unhealthy
或Unknown
,需檢查對應組件的日志(如journalctl -u kube-apiserver
)排查問題。節點是集群的工作單元,需確保所有節點處于Ready
狀態(表示節點與控制平面通信正常,可調度Pod)。
kubectl get nodes
STATUS
列為Ready
(如node-1 Ready control-plane 30d v1.27.0
、node-2 Ready worker 30d v1.27.0
)。若節點狀態為NotReady
,可能是kubelet服務異常、網絡斷連或磁盤空間不足。Pod是Kubernetes的最小調度單元,需確保系統Pod(如CoreDNS、kube-proxy)和業務Pod均處于Running
狀態(表示容器正在運行)。
kubectl get pods -A
(-A
表示查看所有命名空間)kube-system
命名空間下的coredns
、kube-proxy
)狀態為Running
,RESTARTS
次數為0(如coredns-78fcd69978-ckc9b Running 0 20d
);Running
,READY
列顯示預期副本數(如nginx-5c689d88bb-abcde Running 1/1 5m
)。Pending
(調度失敗,可能因資源不足)、CrashLoopBackOff
(應用不斷重啟,可能因鏡像問題或代碼崩潰),需進一步使用kubectl describe pod <pod-name>
分析原因。網絡是集群內Pod通信的基礎,需檢查DNS解析和Pod間通信是否正常。
busybox
)并測試域名解析:kubectl run -it --rm --image=busybox:1.28 busybox --restart=Never -- nslookup kubernetes.default
Server: 10.96.0.10
,Address: 10.96.0.10
,Name: kubernetes.default.svc.cluster.local
)。若解析失敗,可能是CoreDNS未正常運行。test-pod-1
、test-pod-2
),進入其中一個Pod并嘗試ping另一個Pod的IP:kubectl create deployment test-pod --image=nginx --replicas=2
kubectl get pods -o wide
kubectl exec -it test-pod-xxxxx -- /bin/sh
ping <test-pod-yyyyy的IP>
Kubernetes依賴的系統服務(如kubelet、etcd)需正常運行,可通過以下命令檢查:
systemctl status kubelet
(檢查kubelet服務狀態)、在控制平面節點上執行ETCDCTL_API=3 etcdctl endpoint health
(檢查etcd健康狀態)。kubelet
服務狀態為active (running)
;is healthy: successfully committed proposal
。若服務異常,需重啟對應服務(如systemctl restart kubelet
)。通過部署一個簡單的應用(如Nginx),驗證集群的部署、擴縮容和Service暴露功能:
kubectl create deployment nginx --image=nginx # 部署Nginx應用
kubectl get pods -w # 查看Pod狀態(等待變為Running)
kubectl expose deployment nginx --type=NodePort --port=80 # 暴露Service
kubectl get svc nginx # 獲取Service的NodePort(如30080)
Running
;curl
訪問<節點IP>:<NodePort>
(如http://192.168.1.100:30080
),能看到Nginx歡迎頁面。若無法訪問,可能是Service未正確暴露或防火墻攔截。