我们的开发是远程docker进行打包，昨天早上一来发现打包的时候提示docker.io连接超时报错，于是便觉得应该是dockerhub被墙的问题，就在远程docker里面增加了registryMirrors的配置；改完之后顺手就重启了docker，于是打包没问题了；当我们把打包好的程序推送到测试服准备测试的时候，发现这个程序获取kubenetes的configmap总是获取失败；这让我们很困惑，怎么回事？每天都是这样打包，而且这次更新只是增加了一个log.info的函数，怎么就起不来了呢？

一开始不觉得是测试服的问题，在开发拼命找问题，找半天也没看到任何错误；才转过头来判断是不是测试服的kubenetes的问题？用kubectl get pods --all-namespaces -o wide的命令查看所有的pods的运行状态，发现其中一个系统插件出了问题

Calico 是一个CNI 插件，为Kubernetes 集群提供容器网络。 它使用Linux 原生工具来促进流量路由和执行网络策略。 它还托管一个BGP 守护进程，用于将路由分发到其他节点。 Calico 的工具作为DaemonSet 在Kubernetes 集群上运行。难怪因为这个插件出错，造成了我们整个kubenetes的瘫痪，无法去获取配置和外部连接等等相关的操作。便进去查一下这个容器出了什么情况

发现是在pull镜像的时候，与服务器连接不上，一开始便想应该要更换一下pod的镜像应该就可以。

便在kubesphere里面找出这个插件的yaml

把这几个image的地方更换为可以下载到的镜像地址，我们是用

registry.cn-beijing.aliyuncs.com/kubesphereio/cni:v3.23.2

替换了原来的之后，上传到测试服，使用kubectl apply -f xxx.yaml。

执行之后系统网络恢复，所有的pod可以正常获取kubenetes内部数据和外网连接。

折腾一天的事情终于解决。