1. 项目背景与核心价值在容器化部署成为主流的今天Kubernetes 集群的稳定性直接关系到业务连续性。去年我们团队在为客户部署生产级 K8s 集群时曾因遗漏内核参数调优导致节点频繁崩溃。这个惨痛教训让我们意识到集群预检不是可选项而是必选项。预检的本质是系统性风险排查就像飞行员起飞前的检查清单。通过本文总结的 28 项关键检查项我们成功将集群部署失败率从 37% 降至 2% 以下。这些经验适用于任何基于 Kubernetes 的部署场景特别是生产环境首次部署集群版本升级节点扩容/缩容跨云迁移场景2. 预检体系设计原理2.1 分层检查模型我们将检查项划分为三个层级形成金字塔式检查体系[应用层检查] ▲ [K8s组件层检查] │ ▲ [基础设施层检查]基础设施层是根基包含节点资源配额CPU/内存/磁盘内核参数vm.swappiness、fs.file-max网络插件兼容性MTU 设置、CNI 版本存储卷类型支持是否需要 iscsi-initiatorK8s组件层关注控制平面组件版本匹配kube-apiserver 与 etcd 版本差RBAC 权限配置避免过度授权Admission Controller 启用状态PodSecurityPolicy 等应用层侧重资源请求/限制配置防止内存泄漏导致节点雪崩Pod 反亲和性规则避免单点故障HPA 指标采集可用性确保自动扩缩容生效2.2 自动化检查工具链手动检查容易遗漏我们基于开源工具构建了自动化流水线# 检查流程示例 kube-bench → sonobuoy → custom-check-script → report-generator工具选型考量kube-benchCIS 基准检查必备但需注意默认规则过于严格生产环境应自定义config.yaml过滤不适用项sonobuoy官方插件化工具适合网络性能测试通过netperf插件并发负载测试模拟 1000 Pod 创建自定义脚本补足工具链空白比如# 检查节点时间同步偏差 def check_ntp(): for node in kubectl.get_nodes(): offset ssh(node, ntpdate -q pool.ntp.org | grep offset) if float(offset.split()[7]) 0.1: alert(f{node} 时间偏差超过 100ms)3. 关键检查项实战解析3.1 内存计算陷阱许多团队只关注requests/limits设置却忽略系统预留。实际可用内存公式可用内存 节点总内存 - kube-reserved - system-reserved - eviction-threshold - 内核占用我们遇到过典型问题某节点 16GB 内存设置requests14GB却仍被调度最终因 OOM 崩溃。根源在于未计算内核占用约 500MBkubelet 默认eviction-hard100Mi系统进程占用 1.2GB正确做法# kubelet 配置示例 --system-reservedcpu500m,memory1Gi --kube-reservedcpu200m,memory500Mi --eviction-hardmemory.available500Mi3.2 网络插件兼容性检查不同网络插件对内核要求差异巨大插件类型内核模块依赖典型问题Calicoip_set, xt_set丢包率高于 5%CiliumBPF 相关内核版本 4.9 无法运行Flannelvxlan, bridgeMTU 不匹配导致分片检查脚本示例# 检查 Calico 依赖模块 lsmod | grep -E ip_set|xt_set || echo 需加载内核模块 # 测试 MTU 兼容性 ping -s 1472 -M do ${API_SERVER_IP} # 1472 28 15004. 典型故障排查手册4.1 证书过期预警K8s 集群证书过期是灾难性的。我们开发了定期检查脚本# 检查所有证书有效期 certs [apiserver, etcd, front-proxy] for cert in certs: expiry openssl x509 -in /etc/kubernetes/pki/${cert}.crt -noout -enddate if (expiry.date() - datetime.now()) timedelta(days30): alert(f{cert} 证书 30 天内过期)避坑经验使用kubeadm certs check-expiration官方工具为不同证书设置不同有效期CA 可长达 10 年apiserver 建议 1 年4.2 节点 NotReady 根因分析通过预检可提前发现 80% 的潜在故障。常见原因排查表现象检查命令解决方案kubelet 无法启动journalctl -u kubelet检查证书路径或 cgroup 驱动容器网络不通crictl pods确认 CNI 插件已安装磁盘压力过高df -h /var/lib/docker清理镜像或扩容存储5. 预检报告生成技巧人工阅读原始日志效率低下我们采用三级报告体系执行摘要1 页 PDF通过/失败检查项统计关键风险项如证书 7 天内过期集群健康评分0-100详细报告Markdown 格式## [节点] worker-01 检查结果 - [通过] 内存压力测试承受 1000 Pod 创建 - [警告] 磁盘 inode 使用率 92%建议清理日志 - [失败] conntrack 表满需调整 nf_conntrack_max原始数据包tar.gz 归档所有检查命令的 stdout/stderr系统状态快照/proc/meminfo等性能指标Prometheusnode-exporter数据报告生成工具推荐Pandoc将 Markdown 转 PDF/HTMLGoTemplate动态生成可视化报告Grafana集成检查指标长期监控6. 持续改进实践预检不是一次性动作我们建立了反馈闭环问题归档所有检查失败项录入 Jira标记根本原因规则迭代每月更新检查项例如新增对 Kubernetes CVE 的检测优化资源计算公式自动化修复对已知问题实现自愈如# 自动清理 Docker 镜像 if $(df /var | awk {print $5} | grep -q 9[0-9]%); then docker image prune -a --force fi最后分享一个真实案例某金融客户集群在预检中发现etcd未启用 TLS及时修复避免了潜在的数据泄露风险。这再次证明好的预检机制是稳定性的第一道防线。