【k8s】【网络】网络连通性问题排查

目前需要处理的大部分是网络连通性问题，这里的网络连通性问题一般指的是两个ip地址之间无法访问，而在k8s中主要包含三部分：

1. 节点 ip 无法访问
2. 容器 ip，也就是pod ip 访问不通
3. service ip , 也就是 service 的cluster ip 访问不通
   这里需要明确下的是，service 的 cluster ip 并不像 pod ip 和node ip 一样是一个完整的 ‘IP地址’，它只有加上service 的 port 才有意义；实际表现上看，我们去ping 一个service 的 cluster ip是永远无法ping到它的后端pod的，只有curl cluster_ip:port 才能验证 service的连通性。

一般专有云使用的是 iptables 模式的 kube-proxy，service 目前在k8s表现为几条 iptables 规则，并且由于kube-proxy 的稳定性是比较牢靠的，所以我们一般不会去直接怀疑 kube-proxy 配置的iptables 规则出了错，而是去看client 访问service 的后端pod、node ip 是否有问题，如此就将 service 的 cluster ip 连通性问题转化为了 pod ip、节点 ip 的连通性问题。（kubectl describe $service_name 可以获取后端pod ip）
这样网络连通性问题基本上就会转变成以下三种问题：
a. node 与 node 之间 ping 不通
b. node 与 pod 之间 ping 不通
c. pod 与 pod 之间 ping 不通

一、underlay网络，例：rama/terway-vlan 中，pod 与pod 之间 ping 不通
如果同网段之间跨节点的pod ping 不通的话，需要检查 pod 所在的节点是否都在一个vlan 中，即需要找物理网络配置的同学，检查容器网络使用网络的上联交换机端口是否进行了vlan相关配置

二、 underlay 网络，例：rama/terway-vlan 中，pod 与 node 之间 ping 不通
这种情况现在pod 中是否能ping通容器的网关，如果无法ping 通的话，即需要找物理网络配置同学，检查容器网络使用的网卡上联交互机是否进行了 vlan 相关设置，以及路由器是否正确配置，rama可以通过kubeclt get subnet 获取网段以及网关信息

三、pod中无法访问 service 的其他可能性
1.检查容器网段 cidr是否与 service cluster-ip/external-ip 网段的cidr是否有重叠