避坑指南：重装K8S集群时，千万别乱删/etc/cni目录（附kubernetes-cni安装报错解决方案）

Kubernetes集群维护避坑手册关键目录保护与CNI故障深度解析当运维工程师面对一个需要重装的Kubernetes集群时往往会在清理旧环境时陷入该删什么、不该删什么的决策困境。去年我们团队就曾因误删/etc/cni目录导致整个生产环境集群瘫痪12小时——这个看似无害的操作引发了连锁反应所有节点状态变为NotReady容器网络彻底中断关键业务服务全部不可用。本文将基于这类血泪教训系统梳理Kubernetes集群维护中的高危操作禁区特别是CNI网络插件相关的核心目录与文件保护策略。1. /etc/cni目录的不可替代性解析在大多数Linux发行版中/etc目录是配置文件的集中存储位置但/etc/cni对于Kubernetes而言远不止是普通配置目录。这个不起眼的路径实际上是容器网络接口CNI的神经中枢存储着三大类关键数据网络插件配置文件如10-flannel.conflist等定义Pod网络子网、MTU等核心参数二进制插件包括bridge、host-local等基础插件和厂商定制插件状态文件记录网络分配情况和插件运行时状态当执行kubectl describe node看到NetworkReadyfalse reason:NetworkPluginNotReady报错时往往意味着kubelet无法从/etc/cni获取必要的网络配置。此时即便container runtime如Docker或containerd正常运行Pod也无法获得网络连接。关键提示即使使用kubeadm reset清理集群/etc/cni下的文件也不会被自动删除。手动删除该目录将导致网络插件需要完全重新安装和配置。2. 集群重装前的安全检查清单在执行集群节点格式化或重装前建议按照以下清单进行系统检查2.1 必须保留的目录结构目录路径关键内容影响范围/etc/kubernetes/kubelet配置、CA证书、bootstrap令牌所有控制平面组件/var/lib/kubelet/插件数据、卷挂载点、设备管理器状态Pod本地存储和硬件访问/var/lib/etcd/集群状态数据控制平面持久化状态/etc/cni/net.d/CNI配置文件所有Pod网络连接2.2 危险操作防护措施建立备份快照# 创建关键目录的压缩备份 tar -czvf k8s-critical-backup-$(date %Y%m%d).tar.gz \ /etc/kubernetes/ \ /var/lib/kubelet/ \ /etc/cni/ \ /var/lib/etcd/ # 验证备份完整性 tar -tf k8s-critical-backup-*.tar.gz | wc -l使用命名空间隔离# 为测试操作创建临时命名空间 kubectl create ns cluster-migration-test逐节点灰度操作先在一个非关键worker节点执行变更观察至少30分钟确保无异常再逐步推广到其他节点3. kubernetes-cni组件故障处理进阶方案当不得不重新安装kubernetes-cni时除了常见的--nogpgcheck绕过签名检查还有更安全的处理方式3.1 公钥信任的规范处理遇到Public key not installed警告时推荐以下标准流程从官方源获取RPM-GPG-KEYcurl -sSL https://packages.cloud.google.com/yum/doc/yum-key.gpg -o /etc/pki/rpm-gpg/RPM-GPG-KEY-kubernetes导入可信公钥rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-kubernetes验证签名有效性rpm -Kv kubernetes-cni-*.rpm3.2 多环境一致性保障对于需要批量操作的场景可使用Ansible Playbook确保操作一致性- name: Repair kubernetes-cni on all nodes hosts: k8s-cluster tasks: - name: Import Kubernetes GPG key rpm_key: key: https://packages.cloud.google.com/yum/doc/yum-key.gpg state: present - name: Reinstall kubernetes-cni yum: name: kubernetes-cni state: latest disable_gpg_check: no4. 集群网络健康状态深度诊断当节点出现NotReady状态时需要系统性地排查网络组件4.1 诊断流程图解检查kubelet日志journalctl -u kubelet --since 1 hour ago | grep -i cni验证CNI插件可执行性# 检查插件二进制是否存在且可执行 ls -l /opt/cni/bin/ stat /opt/cni/bin/bridge测试网络配置加载# 模拟CNI配置加载过程 CNI_PATH/opt/cni/bin \ NETCONFPATH/etc/cni/net.d \ /opt/cni/bin/bridge /etc/cni/net.d/10-flannel.conflist4.2 常见故障模式对照表症状表现可能原因修复方案cni config uninitialized/etc/cni/net.d/为空重新部署CNI插件配置failed to find plugin bridge/opt/cni/bin缺失插件安装kubernetes-cni包network plugin returns error配置与集群网络CIDR冲突检查flannel/Calico子网配置IPAM allocation failure节点IP段耗尽扩展CNI IP池或清理残留IP5. 安全清理集群的黄金法则对于需要彻底重建的集群建议采用以下安全清理流程优雅终止所有工作负载kubectl drain node-name --ignore-daemonsets --delete-emptydir-data分层次清理资源# 删除用户命名空间非系统 kubectl delete ns --all --waitfalse # 清理持久化卷声明 kubectl delete pvc --all --waitfalse系统级清理谨慎操作# 保留网络配置的清理方案 kubeadm reset --skip-phasescleanup-node # 选择性清理CNI配置 rm -rf /var/lib/cni/ rm -rf /var/run/flannel/在完成所有操作后重建集群时应优先验证网络组件状态kubectl get nodes -o wide kubectl -n kube-system get pods -l k8s-appkube-dns