问题现象

在K8s集群内部署了一个推理实例，然后需要能从另外一个VPC访问。之前集群这么访问都是OK的，但是一个新建的集群发现不通，需要定位原因。

确定只是端口不通

首先我们在节点B里面curl 目标节点IP2+NodePort，发现是不通的。报错：Connection refused。

大家知道，Connection refused代表，报文到达对方了，但是对方拒收。说明指定的端口并没有在监听。通过ping命令也确实可以ping通IP2，也就网络本身没什么问题。

排除安全组

因为旧的集群是OK的，这个新集群有问题。先想到的是：看是不是新集群里面有什么安全组导致的报文被拒绝。查看VPC内的安全组，发现入方向和出方向都是放通的，没有ACL规则会拦截该源IP+端口。所以基本排除网络安全组导致的curl不通。

分析Iptables

确定不是安全组拦截，说明TCP报文能到节点上，于是登录到节点上面进行分析。首先网卡1的NodePort端口可以通，网卡2的NodePort端口却没反应，说明这个2号端口没有被“招待”到。

 iptables -t nat -nvL （可以先过滤端口筛选： | grep 32262 ）

可以看到，这条规则（B）匹配是：源IP是「任意」，目的IP是「任意」，因此规则本身没问题。那再看这条规则的“上家”入口：

可以看到，这里规则（A）是：源IP是「任意」，目的IP是「eth0」的，才能进入上一步的“规则B”的匹配。这就说明：如果目的IP地址是第2张网卡（eth1）的报文，压根不会进来。那肯定不会匹配到NodePort的规则进行“目的地址转换”了。如下图：

于是，我们回去看正常集群节点的规则。果然，好的节点的规则是这样的：

源IP是「任意」，目的IP是「任意」，都可以进一步执行“NodePort规则（B）匹配”。这就解释了为什么老集群可以通，新集群不能通的问题了。

临时规避

既然知道，入口的规则限死了只匹配eth0的IP，导致eth1的报文不执行匹配。那咱们直接给它插入一条规则（克隆这条规则，把目的IP改成第2张网卡的IP）：

首先，以“编辑模式”执行查询

iptables -t nat -S | grep KUBE-NODEPORTS

找出之前的规则，拷贝之。然后修改目的IP，补齐Iptables命令。

新插入一条“新规则”：

iptables -t nat -A KUBE-SERVICES -d 10.255.12.150/32 -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -j KUBE-NODEPORTS

执行后，使用第2张网卡进行端口转发功能OK了。

根因总结

其实你如果一开始就知道Kube-Proxy有个参数叫“nodeport-addresses”就是用来控制监听Host节点上哪个网卡的，很快就知道问题出在哪。

但是咱们这次定位过程是，提前不知道有这么个参数，是通过问题定位过程，再发现有这么参数的。虽然这样效率会低一点，但是这种定位过程依然也是有意义的，毕竟搞业务的部门，不能强依赖有人对Kube-Proxy底层组件细节很熟悉。

Ps：事后发现是这新集群的安装脚本，不知道被谁修改了。把监听所有网卡的配置给注释掉了（可能是某个小伙伴在进行什么测试）。

不过，也许这就是跟唐老师学习一些云网络的意义：不需要先知道病因，而是从病症开始，慢慢反推病因。