3

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

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

4

1 回答 1

2

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

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

另外值得一提的是：

对于 iptables 和 IPVS 模式，kube-proxy 的响应时间开销与建立连接相关，而不是您在这些连接上发送的数据包或请求的数量。这是因为 Linux 使用连接跟踪 (conntrack) 能够非常有效地将数据包与现有连接进行匹配。如果一个数据包在 conntrack 中匹配，那么它不需要通过 kube-proxy 的 iptables 或 IPVS 规则来确定如何处理它。

您可以使用conntrack 命令行界面来搜索、列出、检查和维护 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 状态，conntrack -D然后使用conntrack -E新的 Calico 策略来观察连接事件。

资料来源：

我希望这有帮助。

于 2020-07-01T12:00:46.227 回答