kube-dns的iptable规则

Question

我查看了kube-dns使用的iptables规则，我对子链"KUBE-SEP-V7KWRXXOBQHQVWAT“感到有点困惑，该子链的内容如下：

我的问题是，当源IP地址(172.168.1.5)是kube地址时，为什么我们需要目标“kube”。据我理解，目标IP地址应该是kube的地址172.168.1.5，而不是源IP地址。由于所有DNS查询都来自其他地址(序列化)，因此DNS查询不能来自其本身。

# iptables -t nat -L KUBE-SEP-V7KWRXXOBQHQVWAT
Chain KUBE-SEP-V7KWRXXOBQHQVWAT (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  172.18.1.5           anywhere             /* kube-system/kube-dns:dns-tcp */
DNAT       tcp  --  anywhere             anywhere             /* kube-system/kube-dns:dns-tcp */ tcp to:172.18.1.5:53

这里是全链信息

# iptables -t nat -L KUBE-SERVICES
Chain KUBE-SERVICES (2 references)
target     prot opt source               destination
KUBE-MARK-MASQ  tcp  -- !172.18.1.0/24        10.0.62.222          /* kube-system/metrics-server cluster IP */ tcp dpt:https
KUBE-SVC-QMWWTXBG7KFJQKLO  tcp  --  anywhere             10.0.62.222          /* kube-system/metrics-server cluster IP */ tcp dpt:https
KUBE-MARK-MASQ  tcp  -- !172.18.1.0/24        10.0.213.2           /* kube-system/healthmodel-replicaset-service cluster IP */ tcp dpt:25227
KUBE-SVC-WT3SFWJ44Q74XUPR  tcp  --  anywhere             10.0.213.2           /* kube-system/healthmodel-replicaset-service cluster IP */ tcp dpt:25227
KUBE-MARK-MASQ  tcp  -- !172.18.1.0/24        10.0.0.1             /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-SVC-NPX46M4PTMTKRN6Y  tcp  --  anywhere             10.0.0.1             /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-MARK-MASQ  udp  -- !172.18.1.0/24        10.0.0.10            /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain
KUBE-SVC-TCOU7JCQXEZGVUNU  udp  --  anywhere             10.0.0.10            /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain
KUBE-MARK-MASQ  tcp  -- !172.18.1.0/24        10.0.0.10            /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain
KUBE-SVC-ERIFXISQEP7F7OF4  tcp  --  anywhere             10.0.0.10            /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain
KUBE-NODEPORTS  all  --  anywhere             anywhere             /* kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ADDRTYPE match dst-type LOCAL
# iptables -t nat -L KUBE-SVC-ERIFXISQEP7F7OF4
Chain KUBE-SVC-ERIFXISQEP7F7OF4 (1 references)
target     prot opt source               destination
KUBE-SEP-V7KWRXXOBQHQVWAT  all  --  anywhere             anywhere             /* kube-system/kube-dns:dns-tcp */ statistic mode random probability 0.50000000000
KUBE-SEP-BWCLCJLZ5KI6FXBW  all  --  anywhere             anywhere             /* kube-system/kube-dns:dns-tcp */
# iptables -t nat -L KUBE-SEP-V7KWRXXOBQHQVWAT
Chain KUBE-SEP-V7KWRXXOBQHQVWAT (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  172.18.1.5           anywhere             /* kube-system/kube-dns:dns-tcp */
DNAT       tcp  --  anywhere             anywhere             /* kube-system/kube-dns:dns-tcp */ tcp to:172.18.1.5:53

Answer 1

您可以将iptables中的kubernetes服务路由看作以下步骤：

通过probabilities)

• If循环保存所有kubernetes服务

• 如果您命中匹配的服务地址和IP，则进入服务链

• 服务链将随机从端点列表中选择端点(使用所选端点具有与通信量的源地址相同的IP，稍后将其标记为伪装(这是您询问的KUBE-MARK-MASQ )。换句话说，如果一个pod试图与服务IP对话，而该服务IP“解析”到该IP本身，我们需要稍后将它标记为伪装(实际的伪装目标在POSTROUTING链中，因为只允许在那里发生)，

• 对选定的端点和端口执行DNAT操作。无论是否发生这种情况都会发生。

如果您查看iptables -t nat -L POSTROUTING，将有一条规则是查找标记的数据包，这是伪装的实际发生的地方。

KUBE-MARK-MASQ规则必须存在的原因是针对发夹NAT。为什么有些涉及到细节的解释，但以下是我最好的尝试：

如果伪装没有发生，流量就会将吊舱的网络名称空间离开为(pod IP, source port -> virtual IP, virtual port)，然后被NAT发送到(pod IP, source port-> pod IP, service port)，并立即发送回吊舱。因此，该通信量将到达服务，其源为(pod IP, source port)。因此，当该服务回复时，它将回复(pod IP, source port)，，但是-- pod (真正的内核)--期望流量返回到原来发送流量的IP和端口，即(virtual IP, virtual port)，因此在返回的路上流量会被丢弃。