当 pod 通过目标 pod 在同一主机上的服务与 pod 通信时，kubernetes 是否使用两次 conntrack？
Does kubernetes use conntrack twice when a pod talks to a pod through a service where the destination pod is on the same host?
据我了解，当 POD 与服务对话时，IP 表已由 CNI 提供商更新（这可能特定于某些但不是所有 CNI 提供商）。 iptables 基本上提供了一个虚拟 IP，然后循环或分发（以某种方式）到后端临时 pods。这些 pods 可能位于集群中的同一台主机或另一台主机上。此时（再次基于 CNI）conntrack 用于在将 svc-ip 重新映射到 POD 的 dest-ip 时保持 src 和 dst 直接。不过，我想知道的是，如果 dest pod 在同一台主机上，我不确定它是如何在 return 路径上路由的。我怀疑仍然通过该服务，然后可能将 conntrack 用于 return 路径。
当 pod 通过服务与目标 pod 在同一主机上的 pod 通信时，kubernetes 是否使用两次 conntrack？
我将以 Calico 为例来解释这个主题。
只有从源 pod 到服务端点才需要 Conntrack。您必须跟踪它以将其余流数据包发送到同一目标端点。 return 路径始终只有一个选项：从目标 pod 到源 pod，这意味着即使在此处使用 conntrack 它也不会改变任何内容，因为 return 路径由 NAT table.
另外值得一提的是：
For both iptables and IPVS mode, the response time overhead for
kube-proxy is associated with establishing connections, not the number
of packets or requests you send on those connections. This is because
Linux uses connection tracking (conntrack) that is able to match
packets against existing connections very efficiently. If a packet is
matched in conntrack then it doesn’t need to go through kube-proxy’s
iptables or IPVS rules to work out what to do with it.
您可以使用 conntrack command line interface 来搜索、列出、检查和维护 Linux 内核的连接跟踪子系统。
例如：
conntrack -L 将以 /proc/net/ip_conntrack 格式显示连接跟踪 table：
# 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 策略观察连接事件。
来源：
希望对您有所帮助。
据我了解，当 POD 与服务对话时，IP 表已由 CNI 提供商更新（这可能特定于某些但不是所有 CNI 提供商）。 iptables 基本上提供了一个虚拟 IP，然后循环或分发（以某种方式）到后端临时 pods。这些 pods 可能位于集群中的同一台主机或另一台主机上。此时（再次基于 CNI）conntrack 用于在将 svc-ip 重新映射到 POD 的 dest-ip 时保持 src 和 dst 直接。不过，我想知道的是，如果 dest pod 在同一台主机上，我不确定它是如何在 return 路径上路由的。我怀疑仍然通过该服务，然后可能将 conntrack 用于 return 路径。
当 pod 通过服务与目标 pod 在同一主机上的 pod 通信时，kubernetes 是否使用两次 conntrack？
我将以 Calico 为例来解释这个主题。
只有从源 pod 到服务端点才需要 Conntrack。您必须跟踪它以将其余流数据包发送到同一目标端点。 return 路径始终只有一个选项：从目标 pod 到源 pod，这意味着即使在此处使用 conntrack 它也不会改变任何内容，因为 return 路径由 NAT table.
另外值得一提的是：
For both iptables and IPVS mode, the response time overhead for kube-proxy is associated with establishing connections, not the number of packets or requests you send on those connections. This is because Linux uses connection tracking (conntrack) that is able to match packets against existing connections very efficiently. If a packet is matched in conntrack then it doesn’t need to go through kube-proxy’s iptables or IPVS rules to work out what to do with it.
您可以使用 conntrack command line interface 来搜索、列出、检查和维护 Linux 内核的连接跟踪子系统。
例如：
conntrack -L 将以 /proc/net/ip_conntrack 格式显示连接跟踪 table：
# 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 策略观察连接事件。
来源：
希望对您有所帮助。