揭秘Kubernetes网络迷宫：负载均衡、BGP、IPVS及其他导航指南

在 Kubernetes 的世界里，每天都能听到有关 ipvs 和 iptables 的对比，比如 pureLB 和 metalLB 的对比讨论，或是 overlay 和 underlay 的对比讨论，还有 Nodeport 和 Loadbalancer 的对比，等等。把这些来自不同来源的信息整合在一起并不容易。这就是我要在这里分享的内容。

你知道这些问题的答案吗？
所有的网络方面是如何被管理的？
pureLB是如何与CNI连接的？
ClusterIP服务是如何与IPVS连接的？
为什么我在使用Nodeport时，用netstat看不到打开的端口？

如果是的话就继续，否则也继续，你会感到惊讶的。

在我的脑海里，把20个网站和文章结合起来弄清楚Kubernetes是很难的，但我还是啃下来了，我想让你更容易理解Kubernetes。

我将讨论这些主题与Kubernetes之间的联系，并看看它们是如何集成的。
负载均衡、ipvs、iptables、BGP、桥接（bridge）、CNI、PureLB、端点、服务（svc）、覆盖网络（overlay）、底层（underlay）、ipip、kube-proxy、入口控制器（ingress controller）。

我们快点一步步来搞定

1- CNI、LB 控制器和 Kube-Proxy 之间的关系

CNI: 它通过为每个容器创建和配置网络接口来配置Kubernetes的网络。Kubelet调用CNI插件来设置网卡并分配IP地址。

CNI 有两种运行模式：

• 封装模式

• 底层模式

• 封装（覆盖）：代表像 VXLAN 和 IPSEC 这样的技术。它是 Layer-2 over Layer-3 网络，可以在多个 Kubernetes 节点之间使用。Layer 2 网络是隔离的，因此无需路由分发。它生成 IP 包头来提供 IP 数据包。此模型提供一个桥，连接工作节点和 Pod。管理通信的是 CRI。

• 未封装（即底层）: 这提供了一个 L3 网络来在容器之间路由数据包。需要使用 BGP 来管理路由分发，以分发 Pod 的路由信息。此模型涉及在工作节点之间扩展网络路由器，以便在这些节点之间路由数据包。

某个 CNI 可能同时使用了这两种架构。

LB控制器：MetalLB，PureLB，…。 提供了 Kubernetes 中 LoadBalancer 服务类型的功能。
在创建负载均衡（LB）服务时，分配的外部 IP 会被配置为主接口的一个辅助地址。这能让 BGP BIRD 路由器捕获该 IP 并添加路由、地址以及其他配置。

当新IP被分配时：

在overlay网络的情况下，会使用IPVS或iptables。

在underlay网络的情况下，也会使用路由表。

Kube-proxy: 维护 iptables、ipvs 等网络规则。它还会添加网络策略、NAT、转发规则等。

为了说明这一点，给你一个简单的例子：
当你创建一个服务时，kube-proxy会为iptables添加规则。

知道 netfilter 可以被 EBPF 替代
还有
IPtables 可以被 IPVS 替代

这部分的大概内容是:

• Kube-proxy: 维护 IPTABLES、IPVS 等规则。
• CNI: 提供底层网络的通用接口，路由流量至指定目的地，并执行其他相关功能。
• LB-controller: 提供负载均衡功能，并更新主机接口以添加额外的 IP 地址。

自定义桥(CBR)、虚拟以太网(Veth)、以太网（eth）以及整个网络配置由容器运行时（例如containerd、CRI-O和Mirantis）处理。大多数容器运行时接口(CRIs)使用容器网络接口(CNI)插件来实现这一点，包括Calico、Flannel和Cilium等插件。

因为它们都在同一个网络命名空间中，所以所有在 pod 内的容器共享相同的网络。

Kubernetes中的网络和进程间通信（IPC，Inter-Process Communication）由“暂停容器”负责处理。

在每个 pod 下会创建一个 Veth 接口，连接到 CBR，并进行 L2 路由。例如，从 pod1 到 pod2 的数据包（packet）会经过 CBR，NAT 在这种情况下不会发生。

pod 的 IP 地址如何在节点之间路由？
- 两个节点都在同一个网络里。（能够互相看到）
- CNI 在每个节点上分别为每个 pod 创建路由。

由于节点-1中的CBR没有pod4的MAC地址，数据包会通过路由表指定的接口发送。这可能是隧道、另一个接口（比如eth0）或其他接口，这确实取决于具体配置。

每个 Kubernetes 节点都有其自身的 CIDR，这使得流量可以被正确地路由到相应的节点。

当谈到服务时，IPTABLES/IPVS起着至关重要的作用。在Netfilter中，服务IP地址会随机变更为相关的pod IP地址（基于负载均衡算法）。Kube-proxy负责更新Netfilter规则并为服务分配pod IP地址。

当一个节点接收到带有指向服务的目标包时，在Netfilter中，规则会匹配该服务并将其路由到目标pod的IP地址。

可是怎么做到的？！

服务会更新端点切片，通过匹配服务选择器中指定的 pod 标签，更新端点切片中的 pod IP 地址。当选择器与 pod 的标签匹配时，相关的信息，例如 IP 地址、端口和协议等会被获取并注入到该服务关联的端点切片中。

记得：服务（Service）、端点、NodePort、负载均衡（LB）仅仅是IPTABLES/IPVS中的规则。

当我们通过名称调用服务时，会发生什么呢？ 到目前为止，我们只提到了基于 IP 的路由。

Kubernetes 实现了一个 DNS 服务器，通常是 CoreDNS 或 KubeDNS。
DNS Pod 作为 Kubernetes 服务暴露出来，它带有静态的 ClusterIP，并在每个容器启动时进行解析。
现在这就变得简单了，容器内的名称将由 Kubernetes DNS 服务器解析出来。

这是CNI（Calico）、IPVS、PURELB、IPIP（覆盖）和入口控制器在一张图中共同展示的图。

Calico: Calico 处理所有的网络，包括 IPIP 覆盖网络和 BGP 底层网络。

• 如前所述，所有 Pod 的 IP 地址都将分配给 CBR，即 kube-ipvs 桥接接口。
• 每个 Pod 都有自己的虚拟接口。
• tunl0（IPIP）是一个虚拟接口，它通过覆盖架构将节点相互连接起来。这意味着所有 Pod 的 IP 地址都通过此隧道传输。
• PureLB 是一个负载均衡控制器，它还通过实现 kube-lb0 作为虚拟接口，并为主接口添加次要 IP 地址来管理主机网络。
• PureLB 还兼容 BGP、OSPF 等路由协议。由于 Calico 已经部署了一个 BGP BIRD 路由器，PureLB 可以理解这一点，并且不会实现另一个 BGP 路由器。
• BGP 会抓取分配给接口的所有 IP 地址，并在路由表中定义这些 IP 地址的路由。

直到现在，当来自 pod-1 的 数据包 想要到达另一个节点上的 pod-5 时，kube-ipvs 无法提供它不知道的答案。因此下一层是 路由表，该路由表由 BGP 更新。由于我们有一个覆盖网络架构，所以 它 会通过 tunl0 被路由到期望的目的地。当你 调用这个服务 时，ipvs 规则 就会介入。

我们现在知道，在IPVS中，唯一相关的规则是端点、服务、NodePort和LB。基于这一点：

我们有一个用于 ingress 控制器的负载均衡器类型的服务，，这意味着 ingress 对外部是可访问的。当我们访问这个 IP 时，数据包会被导向到相应节点，然后 IPVS 会将它们转发到 NodePort（NAT）端口，以便在节点之间进行路由并找到正确的目标节点。

随后，NodePort 会关联到一个 ClusterIP，ClusterIP 可以识别 ingress 控制器 pod 的 IP 地址。这样设置的好处在于，一旦 ingress 控制器收到数据包，根据设定的规则，它会将数据包路由到所需服务，进而路由到目标 pod。

本文的目的不是对每个组件提供详细的解释，而是旨在为已经熟悉这些概念的人汇总信息，提供一个全面的概要。

我参考了几种资料，以下是一些供进一步了解：

https://medium.com/thermokline/comparing-k8s-load-balancers-2f5c76ea8f31

https://medium.com/@seifeddinerajhi/kube-proxy-and-cNI-the-hidden-components-of-kubernetes-networking-eb30000bf87a
kube-proxy 和 CNI：Kubernetes 网络中的隐藏组件

访问此链接：https://docs.tigera.io/calico/latest/networking/

点击这里查看详细信息: https://purelb.gitlab.io/docs/how_it_works/overview/