在k8s中的故障排除实例2：启用br_netfilter。

欢迎来到解决在Kubernetes深渊中发现的神秘网络问题的旅程。本次话题对于那些对网络了解不深的人来说是非常具有挑战性的故障排除故事。

问题的发生 de

我在Kubernetes集群中遇到了一个罕见的问题，即Pod之间的名称解析不正常。当我使用dig命令执行DNS查询时，意外的数据源返回了响应。具体来说，;; reply from unexpected source: 10.200.2.177#53, expected 10.32.0.10#53是错误的信息。为什么我得到的响应不是我期望的CoreDNS服务的IP地址，而是托管Pod的节点的IP地址呢？

追寻原因

为了解决这个问题，我们调查了GitHub的Issue和社区论坛。总的来说，问题的核心与网络数据包的路由和过滤相关。在Kubernetes中，网络流量通常根据特定的规则和路径进行路由。然而，在特定条件下，这些数据包可能会采取意外的路径。

br_netfilter是什么？

现在，让我们解释一下br_netfilter模块的作用。该模块在Linux内核空间中运行，并提供了在通过网络桥接的流量上应用Netfilter规则（例如iptables规则）的功能。这样一来，无论是Pod之间还是不同网络段之间的通信，都可以进行流量控制和过滤。

在虚拟环境中进行的第二层网络操作。

在物理网络环境中，数据链路层（第二层）通过使用MAC地址来实现设备之间的通信。然而，在虚拟环境中，这些物理概念是通过软件进行仿真的。也就是说，即使没有实际的物理连接，基于MAC地址的通信和通过桥接连接的数据包转发等仍然会进行。

解决方案

作为解决这个问题的方法，建议启用br_netfilter模块。通过这个操作，可以对网络流量进行适当的过滤和路由规则，并且可以确保Pod之间的通信按照预期正常工作。

# br_netfilterを有効にする
sudo modprobe br_netfilter

此外，作为一种长期解决方案，您还可以将该模块添加到系统的启动设置中。

理想中的流量过滤和问题处理

让我们具体考虑一下在这种情况下，在Kubernetes集群内出现了流量问题。以下是预期流量和发生问题时流量的示例。

原本期望的交通流量：

1. DNS查询的开始：从Pod（例如：Pod A）向服务名称（例如：service.kubernetes）发出DNS查询。

请求的转发：此查询将转发到配置的DNS服务（在此情况下是运行CoreDNS的服务的Cluster IP，例如：10.32.0.10）。

名称解析和响应：CoreDNS接收查询，并将请求的服务名称解析为相应的IP地址（服务的Cluster IP）。然后，将解析结果返回给Pod A。

在这个过程中，流量将沿着明确的路径进行传输，并且响应将从期望的源（CoreDNS服务的IP）返回。

問題發生時的流量情況：

1. DNS查询的开始：同样，从Pod A发出DNS查询。

请求转发：查询被转发到CoreDNS，但出现了问题。

路由故障：响应应该返回到Pod A，但由于网络配置不正确，响应数据包的源IP被重写（NAT/Masquerading问题）。结果是，Pod A收到的响应不是来自CoreDNS的IP（10.32.0.10），而是来自另一个意外的地址（例如，节点的IP 10.200.2.177）。

错误发生：由于Pod A没有从预期的源接收到响应，它会忽略或将其视为错误。这是导致”来自意外来源的回复”错误的原因。

br_netfilter的作用和影响：

br_netfilter模块将Linux内核的网络过滤功能应用于桥接连接的流量（例如Pod之间的通信）。这意味着即使流量没有通过物理网络接口，IP表（iptables）规则也会应用于流量。

1. 如果启用了br_netfilter，则将强制执行所期望的操作：正确的iptables规则将被应用，特别是会正确执行数据包源IP地址的伪装。这将确保DNS响应保持正确的源IP地址（CoreDNS的集群IP），并使Pod A能够接受响应。

修复意外的路由问题：通过应用正确的路由和伪装规则来修正不正确源地址的响应。这将确保数据包以期望的源地址发送到Pod A，并使通信正常完成。

总的来说，启用br_netfilter对于容器编排系统如Kubernetes来说，是确保网络通信的一致性至关重要的。通过这样做，可以确保适当的通信路由在服务之间得以保证，解决了意外网络流量的问题。

总之

Kubernetes（k8s）需要依赖于br_netfilter模块或其类似功能，以确保内部网络正常运行。通过存在该模块（或具有相似功能的其他机制），Kubernetes能够准确控制Pod之间的通信和其他重要的网络操作。

br_netfilter在以下几个方面尤为重要：

1. Pod间通信：在Kubernetes环境中，不同Pod之间的流量通常通过使用Linux桥进行路由。如果没有br_netfilter，这个流量将绕过iptables规则，导致无法正确应用网络策略、NAT和其他网络功能。

网络策略应用：Kubernetes使用网络策略来控制Pod级别的流量流动。br_netfilter提供了路由来实际应用这些策略到流量上，以确保必要的安全性和隔离。

服务路由和负载均衡：Kubernetes的服务（特别是ClusterIP类型）通过使用iptables/NAT规则将流量路由到Pod上。这些规则通过br_netfilter模块应用到桥接连接的流量上来实现功能。

因此，br_netfilter在正确支持这些操作并确保Kubernetes网络的一致性和可靠性方面至关重要。如果未加载或配置不正确，可能会导致意外的网络问题、性能下降或安全漏洞。