指定它为网关，它就成为网关了么

近期排查故障，遇到非常有意思问题。两个故障前后相叠，同时指向了一个思考问题：“指定它为网关，它就成为网关了么？”

经过

---

先遇到关于虚拟机指定宿主机作为网关的问题，后来又接触到k8s集群因calico插件引起的新节点加入问题。最终发现，其实归结起来看起来，都与网关有点关系，我先来捋一捋 :)

初始，新节点加入由calico为网络接口插件的k8s集群网络，使用kubectl get nodes显示节点已成为“Ready”状态。但是，在新节点上部署了App后，App并不能提供服务，不能被正常访问。

首先，想到的就是，看看calico 涉及的几个pod启动状态如何，确实在新节点上，calico-node显示没有进入"Ready"状态！

由于k8s已显示node加入成功，以及可以部署应用，所以，基本上可以断定，k8s层面已经连接完毕，但是，calico层面却出现了问题，而且问题主要在于calico插件！

那么，是什么问题呢？

光靠猜是不行的，需要一点透明信息，需要看看苦主提供了什么信息出来 ：）

这也是Linux世界通常坚持的原则。你想观察到什么，基本上就可以观察到什么！

信息是透明的，所以，查错也是容易的！

我想，开源的世界，基本上都应遵从这样的精神吧 ......

通过k8s提供的describe和logs命令观察calico-node输出信息，指向calico-node通过BGP不能与伙伴通信，具体输出E文：

“calico/node is not ready: BIRD is not ready: BGP not established with *”

   对比，其它正常集群节点，除了自身的黑洞路由外，还有一条bird路由信息指向peer，而且正好路由的CIDR部分，就是另外一个peer的黑洞路由，见红色字体部分！

   蓝色字体部分的IP反应的是peer的集群节点网络的IP，也就是在提供了网关信息，这里先按下不表 : 0

# 自身的calico黑洞路由，与calico的IP分配相关

blackhole 172.27.200.128/26 proto bird

# 其它peer节点

172.27.200.192/26 via 172.26.200.37 dev enp0s8 proto bird

根据这个发现，在新加入节点上只能发现自身的黑洞路由，而且其它旧节点上也不存在新加入节点的bird路由，所以，calico吐出的日志信息，不能与peer连接是具有事实根据的。

依据输出信息，查阅网上资料，多指向与calico的环境变量设置“IP_AUTODETECTION_METHOD”有点关系，根据

自动探测IP环境变量 设置类型为can-reach，重新操作，新旧节点之间就通畅了！

IP_AUTODETECTION_METHOD=can-reach=[k8s-master-node-dns|k8s-master-node-IP]

总结

---

   在这里，讲到的素材，虽然是由calico组建的k8s集群网络遭遇的问题，但更让我思考的是，路由上指定网关后，就自动成为网关的问题？包括，前面虚拟机指定宿主机的IP作为网关，宿主机就可以自动具有网关功能么？

   我们知道，没有无缘无故的爱，也没有无缘无故的恨，查验这些 via gatewayip到达的节点，无一例外，在IP所在的网卡，都提供ip_forward功能！

   在linux中，如果ip_forward功能开启，则只要是这台主机上的IP，报文到达网关IP所在网卡后，都可以被转发到目的IP所在的其它网卡上去。

   这其实是最简单的网关功能，因为它只跨了下网卡，并没有跨越主机！

    而且，k8s用calico网络插件，使得集群IP之间可以直接通信，背后的秘密，也就在于，路由发布，以及与简单网关功能的相互结合！

   ！完结 ！

后期进展2.0

---

如果在Linux网关上与其他系统软件配合，就可以成为比较完整意义上的网关

• ip route 路由
• iptables 过滤器和NAT技术
• ip tunel隧道