避坑指南：重装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看到NetworkReady=false 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-KEY：
curl -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-*.rpm
3.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.conflist
4.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池或清理残留IP |
5. 安全清理集群的黄金法则
对于需要彻底重建的集群，建议采用以下安全清理流程：
优雅终止所有工作负载：
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data分层次清理资源：
# 删除用户命名空间（非系统） kubectl delete ns --all --wait=false # 清理持久化卷声明 kubectl delete pvc --all --wait=false系统级清理（谨慎操作）：
# 保留网络配置的清理方案 kubeadm reset --skip-phases=cleanup-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-app=kube-dns