背景
我司某个大数据集群在做完添加到集群联邦管理后，该集群的calico-node全部处于not ready 状态，导致集群中节点之前的跨节点容器网络不通。
操作
将大数据所在的k8s集群添加到集群联邦的控制平面后，我们为了做各个子集群之间的容器网络可以直通，同时在对应的大数据集群安装了submariner，submariner安装后，其中有一个route-agent组件会以daemonset的方式在每个节点上都启一个Pod，该Pod起来后会在对应的每个节点上创建一个vx-submariner的vxlan网卡
问题
地址为240.x.x.x，calico-node的配置的IP为aoto-detach，通过查看calico-node的日志发现，calico-node启动的时候选择到了240.x.x.x网卡来做为bgp peer member的通信地址，而这是一张虚拟的网卡，各个节点之前是不能直接通的，从而导致bird组件一直not ready，随后通过官方推介的方式将calico-node的配置修改IP_AUTODETECTION_METHOD=kubernetes-internal-ip，从起所有的calico-node，但是还是not ready，通过查看对应的日志，发现还是选择的240.x.x.x网卡
原因
通过查看calico-node flex对应的部分的代码，发现，calico-node起来后会通过获取自己所在的的node信息，然后根据node上的key为projectcalico.org/IPv4Address对应的IP来构建一个node struct当作peer member的ip暴露出来，所以即使配置IP_AUTODETECTION_METHOD=kubernetes-internal-ip，calico-node启动的时候还是会优先选择node的key为projectcalico.org/IPv4Address的annotation对应的值来作为bgp peer member的ip。经过查看node的对应的projectcalico.org/IPv4Address实际的值还是240.x.x.x
解决方式
去掉所有node的对应的annotation，然后从起所有calico-node的pod即可
kubectl annotate node --all projectcalico.org/IPv4Address-kubectl rollout restart daemonset/calico-node -n kube-system检查calico-node
kubectl get po -n kube-system |grep calico-node
