核心组件(API Server、Controller Manager、Scheduler、etcd)是Kubernetes集群的“大脑”,其健康状态直接决定集群能否正常运行。
kubectl get componentstatusesHealthy(如scheduler Healthy ok、controller-manager Healthy ok、etcd-0 Healthy {"health":"true"})。若出现Unhealthy或Unknown,需检查对应组件的日志(如journalctl -u kube-apiserver)排查问题。节点是集群的工作单元,需确保所有节点处于Ready状态(表示节点与控制平面通信正常,可调度Pod)。
kubectl get nodesSTATUS列为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未正确暴露或防火墙拦截。