记一次使用Flannel插件排错历程

Posted 李大鹅

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次使用Flannel插件排错历程相关的知识,希望对你有一定的参考价值。

记一次使用Flannel插件排错历程

原来使用的是Calico插件,这不准备学习K8s的网络,就准备换成Flannel了,然后噩梦就开始了。。。

直接使用kubectl apply -f 安装了flannel插件,使用kubectl get pod -n kube-system查看pod的运行状态,一切都能美好,接着就准备直接运行个Pod看是否正常,结果等了半天还是在创建,这肯定不正常了,就使用kubectl describe pod命令查看,结果发现报下面类型的错误:

Warning FailedCreatePodSandBox 7m48s kubelet, node1 Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "c71c64ed91ac3f408b7809a4a98117714a15fc45282efb136affc2469a9f9b61" network for pod "coredns-7ff77c879f-544jh": networkPlugin cni failed to set up pod "coredns-7ff77c879f-544jh_kube-system" network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes"), failed to clean up sandbox container "c71c64ed91ac3f408b7809a4a98117714a15fc45282efb136affc2469a9f9b61" network for pod "coredns-7ff77c879f-544jh": networkPlugin cni failed to teardown pod "coredns-7ff77c879f-544jh_kube-system" network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")]

嗯,看来是网络插件的问题,初步分析应该是Calico没有卸载干净。当初只是执行了kubeadm reset命令,接着就分别执行了下面的几个命令:

$ ipvsadm --clear
$ rm -rf /etc/cni/net.d/
$  rm -rf $HOME/.kube/config

接着重新安装flannel插件,安装完成后,执行kubectl get pod -n kube-system查看,结果发现coredns一直起不来。使用describe命令查看,发现报错信息和上面的类似。

继续翻,原来kubelet会从默认目录读取配置文件,如果有多个配置文件,那么它会应用按字母顺序首先出现的配置文件中的 CNI 插件,CNI的配置文件默认在/etc/cni/net.d/目录。

详细可以参考官方文档:https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/

这时候感觉有些眉目了,前面我们一直在操作master,而没有管node节点,进入node节点的/etc/cni/net.d/目,果然发现有calico的遗留。

删除后进行kubeadm reset,然后重新加入master,在master上执行kubectl get pod -n kube-system,发现终于正常了。

接着呢,就有开始验证是否能正常拉取镜像,就执行了下面的命令:

kubectl create deployment nginx --image=nginx:1.14-alpine

查看pod,结果发现还是不正常,这次报下面这种错误:

Warning FailedCreatePodSandBox 5m28s (x4 over 5m34s) kubelet, node1 (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "48c46e7e0d9198ff94721fba330cc9370f166c6d1c4181fb3543ef99461c4e8d" network for pod "nginx-55f8fd7cfc-4zbvl": networkPlugin cni failed to set up pod "nginx-55f8fd7cfc-4zbvl_default" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.3.1/24

从报错信息中看出,cni的ip地址不在10.244.3.1/24这个段。在node1上使用ip address查看IP信息。

从上图中可以看到flannel.1的网关是10.244.3.9/32。接着使用cat /run/flannel/subnet.env查看子网环境:

到这里问题就明确了,我们使用的Overlay network为Flannel,也就是说Pod的IP地址段应该在Flannel的subnet下,而现在我们看到cni0的IP地址段与flannel subnet地址段不同,所以就出现了问题。

接下来直接删除这个cni0这个错误网卡,删除后会自动重建。

$ ifconfig cni0 down
$ ip link delete cni0

最后在master上进行验证,问题解决。

以上是关于记一次使用Flannel插件排错历程的主要内容,如果未能解决你的问题,请参考以下文章

Kubesphere-DevOps-记一次流水线排错

记一次让人的喷血的排错经历

记一次 K8S 排错实战过程

记一次JavaWeb-Servlet排错过程

记一次企业高级组网中不正确配置PBR引发的环路排错

记一次类型设计的求索历程