目录
1. 故障背景
2. 排查过程
第一步：定位 API Server 状态
第二步：查看关键日志
3. 根本原因分析
4. 解决方案
4.1 紧急恢复（释放空间）
4.2 恢复集群
5. 防范建议（长治久安）
总结
💡 提示：
1. 故障背景
在运维 Kubernetes 集群或使用 KubeSphere 平台时，突然发现执行kubectl命令报错，返回如下错误信息：
Bash
The connection to the server lb.kubesphere.local:6443 was refused - did you specify the right host or port?同时，查看kubelet日志发现大量connection refused报错，且伴随着容器启动失败的异常。
2. 排查过程
第一步：定位 API Server 状态
首先尝试检查控制平面组件的状态。由于 API Server 无法连接，我们登录 master 节点通过底层运行时查看：
Bash
# 如果是 Docker 环境 docker ps | grep kube-apiserver # 如果是 Containerd 环境 crictl ps | grep kube-apiserver发现 API Server 容器处于Exited状态，或者在不断重启。
第二步：查看关键日志
查看系统日志journalctl -u kubelet -f或/var/log/messages，发现了导致崩溃的“真凶”：
Plaintext
CreateContainerConfigError: "write /var/lib/kubelet/pods/.../etc-hosts: no space left on device" rsyslogd: file '/var/log/messages' write error - OS error: No space left on device这表明：Master 节点的磁盘空间已完全耗尽，导致kubelet无法为 Pod 创建必要的配置文件（如etc-hosts），进而导致 API Server 无法启动。
3. 根本原因分析
磁盘满导致 K8s 崩溃通常由以下几个原因引起：
日志文件过大：
/var/log/messages或/var/log/pods下的容器日志未配置滚动清理。镜像堆积：长期未清理无用的中间镜像或老旧版本镜像。
KubeSphere 日志组件压力：Fluentbit 或 Vector 在采集大量业务报错日志时，缓存可能占满磁盘。
未限制容器日志配置：Docker 默认不限制单个容器日志大小。
4. 解决方案
4.1 紧急恢复（释放空间）
在磁盘 100% 的情况下，首先要腾出空间让系统“喘口气”：
清理 Journal 日志（只保留最近 1 小时）：
Bashjournalctl --vacuum-time=1h清理无用镜像/容器：
Bash# Docker 环境 docker system prune -a -f # Containerd 环境 crictl rmi --prune清空大文件（而非直接删除）：
使用
Bash>定位并清空日志文件，避免因进程占用导致空间无法释放。find /var/log -type f -size +500M -exec sh -c '> "{}"' \;
4.2 恢复集群
空间释放后，重启相关服务：
Bash
systemctl restart kubelet等待几分钟，待 API Server 镜像重新拉起后，执行kubectl get nodes验证集群恢复。
5. 防范建议（长治久安）
为了防止此类问题再次发生，建议进行以下优化：
配置 Docker 日志滚动：在
JSON/etc/docker/daemon.json中加入限制。{ "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" } }磁盘预警：部署 Prometheus + Alertmanager 监控 master 节点的磁盘使用率，设置 80% 阈值报警。
独立分区：建议将
/var/lib/docker(或containerd) 挂载到独立的逻辑卷（LVM），防止容器数据撑爆系统盘。
总结
“Connection Refused” 只是表象，内核报错中的“No space left on device”才是根源。在维护 KubeSphere 等重型平台时，磁盘监控是稳定性的重中之重。
