K8s v1.21.2部署contiv-vpp CNI出现CrashLoopBackOff及cni.sock缺失问题

根因说明 #

/var/run/contiv/cni.sock 是contiv-vswitch Pod正常运行后自动生成的Unix套接字文件，你当前master节点上的contiv-vswitch Pod持续处于CrashLoopBackOff状态，无法生成该文件，因此kubelet调用CNI插件创建Pod网络时直接报错。

分步操作 #

1. 排查contiv-vswitch崩溃原因 #

首先定位崩溃的contiv-vswitch Pod日志：

# 先确认Pod调度节点（可跳过，异常Pod固定运行在master节点）
kubectl describe pod contiv-vswitch-hnbzx -n kube-system
# 抓取vswitch容器日志
kubectl logs -n kube-system contiv-vswitch-hnbzx -c contiv-vswitch

根据常见报错场景对应处理：

• 场景1：巨页配置缺失
  Contiv-VPP运行依赖至少2G 2M大小的巨页，未配置会直接启动失败。
  配置方法：
  1. 登录master节点，编辑 /etc/default/grub 文件，在GRUB_CMDLINE_LINUX参数末尾添加如下配置：

     default_hugepagesz=2M hugepagesz=2M hugepages=1024 iommu=pt
     

  2. 执行 update-grub 生成引导配置，重启master节点
  3. 重启后验证配置生效：grep HugePages_Total /proc/meminfo，输出值≥1024即为正常
• 场景2：旧CNI残留配置冲突
  若之前部署过Flannel、Calico等其他CNI，残留配置会导致contiv-vswitch启动异常。
  清理方法：

  # 登录master和worker节点分别执行
  rm -rf /etc/cni/net.d/*
  rm -rf /opt/cni/bin/*
  

  清理完成后重新apply contiv-vpp部署yaml
• 场景3：版本不兼容
  Contiv-VPP v3.5以下版本不兼容K8s v1.21，需要使用v3.5及以上版本的部署包重新部署。

2. 验证CNI服务正常 #

待所有contiv-vswitch Pod状态变为1/1 Running后，登录master节点验证sock文件存在：

ls /var/run/contiv/cni.sock

文件存在则说明CNI服务恢复正常。

3. 恢复异常业务Pod #

删除状态异常的coredns Pod，让Deployment自动重建：

kubectl delete pods -n kube-system -l k8s-app=kube-dns

等待2分钟后执行kubectl get pods -n kube-system验证coredns状态变为Running即可。

内容的提问来源于stack exchange，提问作者Yang Handsome