networking - 当 pod 通过目标 pod 在同一主机上的服务与 pod 通信时，kubernetes 是否使用两次 conntrack？

Question

据我了解，当 POD 与服务对话时，IP 表已由 CNI 提供商更新(这可能特定于某些但不是所有 CNI 提供商)。 iptables 基本上提供了一个虚拟 IP，然后循环或分发(以某种方式)到后端临时 pod。这些 pod 可能位于同一主机上，也可能位于集群中的另一台主机上。此时(再次基于 CNI)conntrack 用于在将 svc-ip 重新映射到 POD 的 dest-ip 时保持 src 和 dst 直接。不过，我想知道的是，如果 dest pod 在同一台主机上，我不确定它是如何在返回路径上路由的。我怀疑仍然通过该服务然后可能使用 conntrack 作为返回路径。

当 pod 通过服务与目标 pod 在同一主机上的 pod 通信时，kubernetes 是否使用两次 conntrack？

Answer 1

在尝试解释这个主题时，我将使用 Calico 作为示例。

Conntrack 只需要从源 pod 到服务端点。您必须跟踪它以将其余流数据包发送到同一目标端点。返回路径始终只有一个选项:从目标 pod 到源 pod，这意味着即使在这里使用 conntrack 它也不会改变任何东西，因为返回路径由 NAT 表管理。

另外值得一提的是:

For both iptables and IPVS mode, the response time overhead forkube-proxy is associated with establishing connections, not the numberof packets or requests you send on those connections. This is becauseLinux uses connection tracking (conntrack) that is able to matchpackets against existing connections very efficiently. If a packet ismatched in conntrack then it doesn’t need to go through kube-proxy’siptables or IPVS rules to work out what to do with it.

你可以使用conntrack command line interface用于搜索、列出、检查和维护 Linux 内核的连接跟踪子系统。

例如:

conntrack -L 将以/proc/net/ip_conntrack 格式显示连接跟踪表:

 # conntrack -L
 tcp      6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=0 secmark=0 use=1
 tcp      6 431698 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34849 dport=993 packets=244 bytes=18723 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34849 packets=203 bytes=144731 [ASSURED] mark=0 secmark=0 use=1
conntrack v0.9.7 (conntrack-tools): 2 flow entries have been shown.

一个实际的例子是当您更改 Calico 的策略以禁止以前允许的流时。 Calico 只需检查允许流中的第一个数据包(在一对 IP 地址和端口之间)的策略，然后 conntrack 会自动允许同一流中的其他数据包，而无需 Calico 重新检查每个数据包。如果最近在先前允许的流上交换了数据包，因此该流的 conntrack 状态尚未过期，则该 conntrack 状态将允许相同 IP 地址和端口之间的更多数据包，即使在 Calico 策略已更改后也是如此。为避免这种情况，您可以使用 conntrack -D 手动删除相关的 conntrack 状态，然后使用 conntrack -E 以使用新的 Calico 策略观察连接事件。

来源:

• Linux Conntrack

• Connection tracking

• Kube-proxy modes

• Packet flow

希望对您有所帮助。