Kubernetes集群排错指南：从基础到进阶
项目地址: https://gitcode.com/gh_mirrors/kub/kubernetes-handbook 前言
Kubernetes作为容器编排的事实标准，其集群状态的稳定性直接影响着业务系统的可靠性。本文将系统性地介绍Kubernetes集群常见故障的排查方法，帮助运维人员和开发者快速定位和解决集群问题。
集群状态异常概述
Kubernetes集群由多个核心组件组成，每个组件的异常都会导致不同层面的问题。以下是常见的集群异常情况及其影响：
核心组件故障影响
-
kube-apiserver异常
- 集群管理接口不可用
- 现有Pod和服务保持运行（不依赖API的部分）
- 无法执行kubectl命令
-
etcd集群故障
- 集群状态数据无法读写
- kubelet节点状态更新失败
- 可能导致调度器无法工作
-
控制器管理器/调度器异常
- Deployment、StatefulSet等控制器失效
- 新Pod无法被调度（Pending状态）
- 节点自动修复功能失效
-
节点/Kubelet问题
- 节点上Pod无法启动或终止
- 节点状态变为NotReady
- 监控数据缺失
集群健康检查方法论
第一步：检查节点状态
节点是Kubernetes集群的工作单元，节点状态是排查问题的第一切入点：
# 查看所有节点状态
kubectl get nodes
# 查看具体节点详情
kubectl describe node <node-name>
当节点状态为NotReady时，describe命令输出的Events部分通常会包含关键错误信息。
第二步：访问问题节点
对于云环境或物理机，可以通过以下方式访问问题节点：
- 直接SSH：如果有节点网络访问权限
- 通过SSH Pod：当无法直接访问时，可部署临时SSH服务
# ssh-pod.yaml示例
apiVersion: v1
kind: Pod
metadata:
name: debug-pod
spec:
containers:
- name: debug-container
image: alpine
command: ["/bin/sh", "-c", "sleep 3600"]
hostNetwork: true
nodeName: <目标节点名>
第三步：检查组件日志
根据部署方式不同，日志查看方法有所差异：
Systemd部署方式
journalctl -u kube-apiserver -l
journalctl -u kube-controller-manager -l
journalctl -u kubelet -l
Static Pod部署方式
# 获取kube-apiserver日志
kubectl -n kube-system logs $(kubectl -n kube-system get pod -l component=kube-apiserver -o name)
# 获取kube-controller-manager日志
kubectl -n kube-system logs $(kubectl -n kube-system get pod -l component=kube-controller-manager -o name)
常见问题深度解析
1. kube-dns CrashLoopBackOff
现象：
- kube-dns Pod不断重启
- 服务发现功能异常
排查步骤：
# 检查kube-dns各容器日志
kubectl -n kube-system logs <kube-dns-pod> -c kubedns
kubectl -n kube-system logs <kube-dns-pod> -c dnsmasq
典型错误及解决：
-
DNS转发超时：
skydns: failure to forward request "read udp 10.240.0.18:47848->168.63.129.16:53: i/o timeout"解决方案：
- 检查节点网络连通性
- 确保节点IP转发已开启：
sysctl net.ipv4.ip_forward=1 - 验证上游DNS服务器可达性
-
API服务器连接超时：
Failed to list *v1.Endpoints: Get https://10.0.0.1:443/api/v1/endpoints?resourceVersion=0: dial tcp 10.0.0.1:443: i/o timeout解决方案：
- 检查Pod到API服务器的网络连通性
- 验证网络插件配置
2. 节点NotReady问题
排查思路：
-
检查Kubelet服务状态：
systemctl status kubelet -
查看Kubelet日志：
journalctl -u kubelet -n 100 -f -
常见原因：
- PLEG不健康：Kubelet内部Pod生命周期事件生成器异常
- CNI插件未安装：网络插件缺失导致节点注册失败
- Docker引擎挂起：Docker无响应导致Kubelet功能异常
- 磁盘空间不足：镜像或日志占满磁盘空间
推荐方案： 部署Node Problem Detector（NPD）实时监控节点健康状态：
kubectl apply -f https://raw.githubusercontent.com/kubernetes/node-problem-detector/master/deployment/node-problem-detector.yaml
3. 资源监控异常
Dashboard无监控图表：
-
检查Heapster/metrics-server状态：
kubectl -n kube-system get pods -l k8s-app=metrics-server -
若无相关Pod，需部署metrics-server：
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
HPA自动扩展失效：
查看HPA事件：
kubectl describe hpa <hpa-name>
若出现FailedGetResourceMetric错误，通常是因为metrics-server未正确部署或无法提供CPU/内存指标。
进阶问题处理
1. 系统资源不足问题
/sys/fs/cgroup空间不足：
调整内核参数：
sudo sysctl fs.inotify.max_user_watches=524288
节点存储空间不足：
-
查找大体积镜像：
docker images --format '{{.Size}}\t{{.Repository}}:{{.Tag}}' | sort -h -r -
自动清理无用镜像：
docker system prune -af
2. 性能相关问题
大量ConfigMap导致性能下降：
优化方案：
- 调整kubelet配置：
configMapAndSecretChangeDetectionStrategy: Cache - 增加API服务器HTTP/2流限制：
--http2-max-streams-per-connection=10000
Kubelet内存泄漏：
典型表现：
- Kubelet内存持续增长
- 大量reflector相关metrics
解决方案：
- 禁用不必要的reflector metrics
- 升级到修复版本
最佳实践建议
-
集群设计原则：
- 控制平面高可用部署（多Master节点）
- Etcd集群使用持久化存储并定期备份
- 节点自动修复能力（云平台自动重启）
-
日常运维：
- 资源请求/限制合理配置
- 使用PodDisruptionBudget保护关键工作负载
- 定期检查节点资源使用情况
-
监控告警：
- 核心组件健康状态监控
- 节点资源水位告警
- 关键业务Pod可用性检查
结语
Kubernetes集群排错需要系统性的思维和方法。通过本文介绍的分层排查方法，从节点状态到组件日志，再到具体错误分析，可以高效定位大多数集群问题。同时，良好的集群设计和运维习惯能够有效预防问题的发生。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
