k8s-网络

Kubernetes (K8s) 网络解决方案是指在 Kubernetes 集群中实现容器网络通信的各种技术和工具。这些解决方案的设计目的是为了满足 Kubernetes 网络模型的要求，即：

1. 所有 Pod 都必须能够无需 NAT 就能互相通信。

2. 所有节点必须能够无需 NAT 就能与所有 Pod 通信。

3. Pod 在重新调度时保持相同的 IP 地址。

这些网络解决方案遵循 CNI（Container Network Interface）规范，提供插件以集成不同的网络技术。下面是一些主要的 Kubernetes 网络解决方案及其底层原理、优缺点：

Calico

• 原理 ：Calico 使用纯三层网络来提供 Pod 间通信，通过使用 IP 路由而不是覆盖网络，以减少网络复杂性和性能开销。它使用 BGP（边界网关协议）来广播和学习路由，支持网络策略来控制 Pod 间的流量。

• 优点 ：高性能，支持大规模集群；丰富的网络策略；直接使用物理网络，不需要封包解包的开销。

• 缺点：配置和管理相对复杂，对网络知识要求较高；在某些环境下（如较老的数据中心），对 BGP 的支持可能受限。

Flannel

• 原理：Flannel 是一个简单的覆盖网络解决方案，为每个 Pod 提供一个唯一的 IP。它使用 etcd 存储网络配置信息，支持多种后端，如 VXLAN、IPsec 和 AWS VPC。

• 优点：部署和配置简单，适合小型到中型集群；对新手友好。

• 缺点：性能不如基于路由的解决方案；覆盖网络可能会增加一些网络延迟。

Weave Net

• 原理：Weave Net 创建一个虚拟网络，连接不同 Docker 容器。它自动发现和管理集群中的容器，无需额外配置，支持网络策略，并提供服务发现机制。

• 优点：安装配置简单；自动处理网络分区和故障恢复；不依赖于集群底层的网络基础设施。

• 缺点：相较于其他解决方案，性能可能较低；在大规模集群中可能面临管理挑战。

Cilium

• 原理：Cilium 基于最新的 Linux 内核技术 BPF（Berkeley Packet Filter），提供网络安全、可观测性和负载均衡。它能够理解应用层（Layer 7）的协议，并在此基础上实施安全策略。

• 优点：提供应用层的网络策略和安全；支持多种网络模式，包括透明的服务网格；高性能和可扩展性；丰富的可观测性和监控功能。

• 缺点：较新的项目，社区相对较小；需要较新的 Linux 内核支持 BPF。

选择网络解决方案

选择合适的 Kubernetes 网络解决方案时，需要考虑以下因素：

• 集群规模：大型集群可能更适合使用 Calico 或 Cilium 这样的基于路由的解决方案。

• 性能需求：对于对网络性能有高要求的应用，基于路由的解决方案通常比覆盖网络性能更好。

• 网络策略：如果需要丰富的网络策略支持，Calico 和 Cilium 是较好的选择。

• 环境兼容性：需要考虑解决方案是否支持当前的基础设施和云环境。

• 易用性和管理：对于小型或测试环境，Flannel 或 Weave Net 可能因其简单性而更受青睐。

综合考虑这些因素后，你可以根据具体需求和偏好选择最合适的 Kubernetes 网络解决方案。

覆盖网络

覆盖网络（Overlay Network）是一种网络虚拟化技术，它在现有的网络基础设施之上创建了一个虚拟的网络层。这个虚拟网络使得网络上的设备（如服务器、容器或虚拟机）能够彼此通信，就像它们连接在同一个物理网络一样，即使实际上它们可能分布在不同的物理网络中。

工作原理

• 数据封装：覆盖网络通过封装原始数据包来工作。当数据从一个设备发送到另一个设备时，原始数据包会被封装在另一个数据包中。这个外层的数据包有自己的头部信息，指定了虚拟网络内的源地址和目的地址。

• 隧道技术：封装后的数据包通过隧道在物理网络中传输。这些隧道可以跨越不同的网络和互联网，允许分布在不同位置的设备安全地进行通信。

• 数据解封装：当封装的数据包到达目的地后，外层的数据包会被去除（解封装），恢复原始数据包，然后将其传递给接收设备。

常用技术

• VXLAN (Virtual Extensible LAN)：一种广泛使用的覆盖网络技术，可以支持大规模的虚拟网络。

• NVGRE (Network Virtualization using Generic Routing Encapsulation)：另一种覆盖网络技术，使用 GRE 封装来虚拟化网络层。

• STT (Stateless Transport Tunneling)：专为虚拟化环境设计的覆盖网络协议，优化了数据中心内的通信。

优点

• 灵活性：覆盖网络允许你在不改变底层物理网络基础设施的情况下创建复杂的网络拓扑。

• 可扩展性：可以轻松跨越不同的物理网络和数据中心创建虚拟网络，支持大规模部署。

• 安全性：封装技术和隧道技术提供了数据传输的隔离和安全保护。

缺点

• 性能开销：数据封装和解封装过程增加了额外的计算开销，可能会影响网络性能。

• 复杂性：管理覆盖网络的复杂性随着网络规模和使用的技术而增加。

应用场景

覆盖网络在多种环境和用例中非常有用，尤其是在需要高度灵活性和跨网络通信能力的场景，例如：

• 云计算和数据中心：在不同物理位置的虚拟机或容器之间提供灵活的网络通信。

• 多租户环境：在共享的物理网络基础设施上创建隔离的网络环境，为每个租户提供独立的网络空间。

• 容器编排：在 Kubernetes 等容器编排系统中，覆盖网络使得跨主机的容器可以无缝通信。

覆盖网络通过提供额外的虚拟化网络层，解决了现代数据中心和云环境中网络通信和隔离的挑战，使得网络设计和管理更加灵活和动态。

VXLAN技术详解

好的，我们来详细解析一下 VXLAN（Virtual Extensible Local Area Network）。这是一个非常重要的网络 overlay 技术，尤其在云计算和大型数据中心领域。

一、什么是 VXLAN？为什么需要它？

VXLAN 是一种网络虚拟化技术，它通过在三层网络（IP）上叠加一个二层网络，来构建大型的、多租户的虚拟数据中心网络。

它主要为了解决传统数据中心网络面临的几个核心问题：

1. VLAN ID 数量限制 (4096个)：

   • 传统 VLAN 使用 12-bit 的 VLAN ID，最多只能划分 4094 个网络（0 和 4095 保留）。

   • 对于大型云服务商或多租户环境，这个数量远远不够。

2. 物理网络架构的局限性：

   • 传统二层网络依赖 STP（生成树协议）来防止环路，但这会导致大量的链路被阻塞，无法有效利用带宽。

   • 网络规模受限于 MAC 地址表大小，容易产生 MAC 地址表溢出。

3. 虚拟机迁移范围受限：

   • 虚拟机迁移通常需要在同一个二层域内进行。传统数据中心的三层边界成为了虚拟机动态迁移的"壁垒"，无法实现跨机房、跨数据中心的灵活迁移。

---

二、VXLAN 的核心原理

VXLAN 的解决思路是："在 UDP 中封装以太网帧"，从而将一个二层数据帧在一个三层网络基础上进行扩展。

1. 核心组件

• VTEP (VXLAN Tunnel End Point)：

  • VXLAN 的起点和终点，是进行封装和解封装的实体。

  • 通常存在于虚拟化主机的 Hypervisor（如 ESXi, KVM） 或支持 VXLAN 的物理交换机（如 Nexus 9000, Arista） 上。

  • 每个 VTEP 都有一个唯一的 IP地址，用于在底层 IP 网络中标识自己。

• VNI (VXLAN Network Identifier)：

  • 这是 VXLAN 的核心，用于隔离租户/网络。

  • 它是一个 24-bit 的字段，理论上可以支持 1600 万（2^24）个隔离的网络段，彻底解决了 VLAN ID 数量不足的问题。

  • 每个 VNI 代表一个独立的二层广播域，类似于一个 VLAN。

• VXLAN 隧道：

  • 在两个 VTEP 之间建立的逻辑通道。底层网络（Underlay Network）负责转发 VTEP 之间的封装后的 UDP 数据包，而对封装在内的原始以太网帧一无所知。

2. 报文封装与解封装

这是 VXLAN 的工作机制核心。我们通过一个例子来看：同一 VNI 下的两台虚拟机 VM1 和 VM2 在不同物理服务器上如何进行通信。

发送过程 (封装 - Encapsulation)：

1. 原始帧：VM1 发送一个以太网帧，目标 MAC 是 VM2。

2. 到达源 VTEP：帧到达其所在的源主机（Host1）的 VTEP。

3. 学习与封装：

   • 源 VTEP 根据目标 MAC 地址和 VNI，查询它的转发表，找到目的 VTEP 的 IP 地址（即 Host2 的 VTEP IP）。

   • VTEP 将原始的二层以太网帧 作为一个数据载荷，加上一个 VXLAN 头部（包含 VNI）。

   • 再将 VXLAN 头部和原始帧一起封装到一个 UDP 数据包中。

   • 这个 UDP 数据包的外层再被封装上新的 IP 头部 （源 IP 是 Host1 的 VTEP IP，目标 IP 是 Host2 的 VTEP IP）和新的 MAC 头部。

4. 在底层网络传输：这个新的 IP 包（ often called the "Underlay Packet"）通过底层的三层 IP 网络进行路由和转发。底层网络设备（路由器、交换机）只关心外层的 IP 和 MAC 地址，完全不知道内部封装了什么。

接收过程 (解封装 - Decapsulation)：

1. 到达目的 VTEP：底层网络将数据包顺利路由到 Host2 的 VTEP。

2. 拆除外层头：Host2 的 VTEP 拆除外层的 IP、UDP 和 VXLAN 头部。

3. 交付原始帧：取出内部的原始以太网帧，并根据其 VNI 信息，将其转发给正确的目标虚拟机 VM2。

---

三、关键特性与优势

1. 巨大的规模支持：

   • 24-bit 的 VNI 提供了海量的逻辑网络数量，完美支持多租户。

2. 突破物理网络限制：

   • 虚拟机可以在任何被 IP 网络连通的位置之间迁移，因为 VXLAN 隧道可以跨越三层网络。这实现了大二层网络的扩展。

3. 更好地利用网络带宽：

   • 底层网络是 IP 路由网络，可以使用 ECMP（等价多路径路由） 等协议，让流量在多条路径上传输，充分利用所有可用链路，避免了 STP 的带宽浪费问题。

4. 与现有网络兼容：

   • 底层（Underlay）网络可以是任何 IP 网络，无需对现有网络架构做大的改动。 overlay 网络和 underlay 网络是解耦的。

---

四、VXLAN 的控制平面：如何学习 MAC 地址？

VXLAN 是二层技术，所以也需要像传统交换机一样学习 MAC 地址。主要有两种方式：

1. ** flood-and-learn (数据平面学习)**：

   • 对于未知的单播、广播或组播流量，VTEP 会将其在 VNI 内进行泛洪（复制一份并发送给该 VNI 的所有其他 VTEP）。

   • 目标主机收到后会回复，源 VTEP 从回复报文中就能学习到 (MAC地址, VTEP IP) 的映射关系，并存入自己的转发表。

   • 这是最传统的方式，但泛洪流量可能较大。

2. 使用控制平面（如 BGP EVPN）：

   • 这是现代数据中心更主流、更高效的方式。

   • 使用 BGP EVPN（Ethernet VPN） 协议作为控制平面。VTEP 之间通过 BGP 协议来交换和同步 (MAC地址, IP地址, VNI, VTEP IP) 的映射信息。

   • 优点：

     • 避免了泛洪：VTEP 预先通过 BGP 就知道了所有 MAC 地址的位置，无需泛洪学习。

     • 集成IP路由：EVPN 不仅可以通告 MAC 地址，还可以通告 IP 路由，实现了 integrated bridge and route功能。

     • 高可靠性：支持多活网关，提供更快的故障收敛。

---

五、总结：Overlay vs. Underlay

理解 VXLAN 的关键是理解这两个概念：

• Underlay Network（底层网络）：

  • 指的是物理网络，由物理路由器、交换机和链路组成。

  • 它负责使用传统的路由协议（如 OSPF, IS-IS, BGP）来转发 VXLAN 的封装包（即外层IP/UDP包）。

  • 它的目标是高效、可靠、低延迟。

• Overlay Network（叠加网络）：

  • 指的是逻辑网络，由 VTEP 和 VXLAN 隧道构成。

  • 它运行在 Underlay 网络之上，负责传输虚拟机的原始数据帧。

  • 它对 Underlay 网络的具体细节一无所知，只要求 IP 可达性。

VXLAN 通过清晰地分离 Overlay 和 Underlay，实现了网络的极大灵活性和可扩展性，是现代软件定义网络（SDN）和云计算基础架构的基石技术之一。

Flannel

Flannel 是一个简单的 Kubernetes 网络解决方案，用于为集群中的 Pod 提供一个覆盖网络。它让 Pod 能够无视底层网络基础设施，相互之间进行通信，就好像它们在同一个以太网交换机上一样。Flannel 是由 CoreOS 开发的，现在是 CNCF（云原生计算基金会）的一部分。

工作原理

Flannel 在 Kubernetes 集群的每个节点上运行一个代理进程，这些代理负责维护 Pod 网络的配置和状态。Flannel 使用一种中央数据存储（如 etcd）来保持集群的网络配置信息。

1. 网络分配：当 Flannel 启动时，它会从中央数据存储中获取一个全局网络配置，包括整个 Pod 网络的 CIDR。然后，Flannel 为每个加入集群的节点分配一个子网，确保节点间的子网不会重叠。

2. 数据封装：Flannel 使用数据包封装技术（如 VXLAN）在物理网络之上创建一个虚拟网络层。每当 Pod 间通信时，它的数据包会被封装在一个外部数据包中，然后通过物理网络路由到目的地节点，最后被解封装并传递给目标 Pod。

3. 路由配置：Flannel 会配置节点的路由表，以便封装后的数据包可以通过物理网络正确路由到目标节点。每个节点知道如何将封装的数据包路由到集群中的任何其他节点。

核心组件

• flanneld：Flannel 的主要代理，运行在 Kubernetes 集群的每个节点上。它负责分配子网、封装和解封装数据包以及更新路由表。

• etcd：用作 Flannel 的中央数据存储，存储网络配置和每个节点的子网分配信息。

特点

• 简单性：Flannel 旨在提供简单而又可靠的覆盖网络，易于安装和配置。

• 灵活性：支持多种后端，包括 VXLAN（默认）、IPSec、Direct routing 等，允许用户根据需要选择最适合他们环境的数据封装技术。

• 可扩展性：虽然 Flannel 更适合小到中等规模的集群，但它也可以通过适当的调整和优化支持较大的部署。

使用场景

Flannel 适用于需要简单、易于设置的 Kubernetes 网络解决方案的场景。它特别适用于：

• 小到中等规模的 Kubernetes 部署。

• 开发和测试环境，其中网络性能和高级网络特性不是首要考虑因素。

• 对网络解决方案的定制要求不高的环境。

总的来说，Flannel 提供了一种简单且有效的方式来实现 Kubernetes Pod 网络，使得 Pod 能够跨越不同节点进行通信，而无需考虑底层的网络基础设施细节。

Calico

Calico 是一个广泛使用的、开源的网络和网络安全解决方案，专为容器、虚拟机和原生主机环境设计，非常适用于大规模 Kubernetes 集群。它提供了高性能的网络通信以及高级的网络策略管理，使得它成为构建和维护大型、复杂 Kubernetes 集群网络的流行选择。

工作原理

Calico 的核心原理包括：

1. 纯三层网络：Calico 使用标准的 IP 路由而不是覆盖网络（如 VXLAN）来处理 Pod 间的通信，这意味着每个 Pod 都分配有一个唯一的 IP 地址。这种方法简化了路由过程，减少了封装和解封装的开销，提高了网络性能。

2. BGP（边界网关协议）：Calico 使用 BGP 来分发路由信息。在一个 Calico 网络中，每个节点都可以作为一个 BGP 对等体，它会向集群中的其他节点宣告自己所负责的 Pod IP 范围。这使得集群内的每个节点都能了解如何将流量路由到任何特定的 Pod，无论这个 Pod 位于哪个节点上。

3. 网络策略：Calico 提供了强大的网络策略管理功能，允许细粒度控制 Pod 间的通信。这些策略可以基于多种标准进行定义，包括命名空间、Pod 标签和选择器等。策略可以实施白名单或黑名单规则，以确保网络的安全性和合规性。

4. IPAM（IP 地址管理）：Calico 提供了灵活的 IPAM 解决方案，支持静态和动态 IP 分配。Calico 可以与 Kubernetes 的 CNI 插件集成，自动为每个 Pod 分配 IP 地址，并确保这些地址在集群中的唯一性。

5. IPIP 封装（可选）：尽管 Calico 通常使用无封装的纯三层路由，但它也支持 IPIP 封装，以允许在不支持直接路由的环境中跨越不同子网的 Pod 通信。

特点

• 高性能和可扩展性：Calico 提供了接近原生网络性能的通信能力，非常适合需要高吞吐量和低延迟的应用，且能够轻松扩展到数千个节点。

• 细粒度的网络安全策略：Calico 允许你定义详细的网络安全规则，控制 Pod 之间的流量流动，从而增强集群的安全性。

• 跨平台兼容性：Calico 不仅支持 Kubernetes，还可以用于其他容器编排工具（如 Docker Swarm）和传统的 VM 或裸机环境，使其成为多环境中的理想选择。

使用场景

• 大规模 Kubernetes 集群：Calico 特别适合于大型或高密度的 Kubernetes 集群，需要高性能网络通信和复杂的网络策略管理。

• 多云和混合云环境：Calico 的灵活性使其适用于多云和混合云环境，能够跨越不同云平台和数据中心实现网络通信和策略一致性。

• 需要高级网络策略管理的应用：对于需要细粒度网络控制和安全隔离的应用，Calico 提供了强大的工具集。

总的来说，Calico 以其高性能、可扩展性和强大的网络策略功能，在 Kubernetes 环境中提供了一种高效的网络解决方案。

好的，我们来详细探讨一下在 Calico 网络中为 Pod 配置静态 IP 地址的实现方式。

在 Kubernetes 的默认设定中，Pod 的 IP 地址是由 CNI 插件（如 Calico）动态分配的，生命周期与 Pod 绑定，极不固定。但在某些特定场景下（如传统授权、基于IP的安全策略、外部服务依赖等），我们需要为特定的 Pod 分配一个固定不变的静态 IP。

Calico 提供了几种不同粒度和方法来实现静态 IP 分配，其核心原理是使用 Calico 的 IPAM（IP Address Management）并通过 Kubernetes 的注解（Annotation）来指定期望的 IP。

---

方法一：为单个 Pod 指定静态 IP（最常用）

这是最直接的方法，通过 Pod 的 annotations 字段向 Calico 的 IPAM 申请特定的 IP 地址。

实现步骤：

1. 确认 IP 在 Calico IP 池中 ： 首先，你想要的静态 IP 必须位于 Calico 配置的 IP 地址池（IPPool）范围内。否则，Calico 无法将其分配出去。 你可以使用 calicoctl get ippool -o wide 查看已配置的 IP 池。

2. 确保 IP 未被占用： 静态 IP 不能与已分配的 IP 冲突。你需要管理一个静态 IP 的分配列表，或者使用 Calico 的 API 来查询 IP 可用性。

3. 在 Pod 定义中添加注解 ： 在 Pod 的 metadata.annotations 中添加以下两个注解：

   • cni.projectcalico.org/ipAddrs: 请求一个指定的 IPv4 地址。

   • cni.projectcalico.org/ipAddrsv6: 请求一个指定的 IPv6 地址（如果适用）。

示例 YAML

apiVersion: v1
kind: Pod
metadata:
name: static-ip-pod
annotations:

核心注解：指定一个包含单个 IPv4 地址的 JSON 数组

cni.projectcalico.org/ipAddrs: "\\"192.168.0.100\\""
spec:
containers:

• name: myapp-container
  image: nginx
  ports:
• containerPort: 80

注意：如果你使用 Deployment，需要将 annotation 写在 PodTemplate 的 metadata 中。

但请注意，使用静态IP和 Deployment 的动态扩缩容理念相悖，通常用于 StatefulSet 或单 Pod。

重要注意事项：

• Deployment 与静态 IP ：通常不推荐 为 Deployment 中的 Pod 指定静态 IP。因为 Deployment 管理的 Pod 是可销毁和重建的，而新 Pod 会尝试申请相同的静态 IP，如果原 Pod 还未完全清理（IP 未释放），会导致冲突。静态 IP 更适合由 StatefulSet 或单例 Pod 使用。

• IP 管理：你需要自行管理静态 IP 的分配，避免冲突。Calico 不会像 DHCP 服务器一样为你保留和管理这些 IP。

• IP 池变更：如果你后续修改了 Calico 的 IP 池，已分配的静态 IP 如果不在新池范围内，可能会导致网络问题。

---

方法二：为整个命名空间或特定 Pod 选择 IP 池

如果你不是指定单个精确的 IP，而是希望 Pod 从某个特定的 IP 地址池中获取 IP（可以是动态的，但池子是固定的），可以使用以下注解：

• cni.projectcalico.org/ipv4pools: 指定 Pod 从哪个 IPv4 池中获取地址。

• cni.projectcalico.org/ipv6pools: 指定 Pod 从哪个 IPv6 池中获取地址。

值的格式是包含 IP 池名称的 JSON 数组。

示例：

apiVersion: v1
kind: Pod
metadata:
name: pool-pod
annotations:

让 Calico 从名为 'my-static-ip-pool' 的池中分配IP

cni.projectcalico.org/ipv4pools: "\\"my-static-ip-pool\\""
spec:
containers:

• name: myapp-container
  image: nginx

这种方法通常用于实现多租户网络隔离或不同业务使用不同网段，而不是严格意义上的"静态IP"，但它提供了另一种IP分配的控制维度。

---

方法三：使用 Calico 网络策略固定 WorkloadEndpoint IP

这是一种更底层、更手动的方法，一般不推荐，但有助于理解 Calico 的工作原理。

Calico 会为每个 Pod 创建一个对应的 WorkloadEndpoint 资源。你可以手动创建或修改这个资源，直接为其指定 IP 地址。

1. 禁用 Pod 的自动 IP 分配 ：在 Pod 注解中添加 cni.projectcalico.org/ipAddrs: "[]" 或使用特定配置。

2. 手动创建 WorkloadEndpoint ：使用 calicoctl 创建一个 WorkloadEndpoint 资源，并显式设置 spec.ipNetworks 字段为你想要的 IP。

这种方法非常繁琐，容易出错，且需要与 Pod 的生命周期紧密同步，因此仅在极端特殊场景下使用。

---

方法四：基于 StatefulSet 与 拓扑感知路由（现代、推荐用于有状态应用）

从 Kubernetes v1.23 开始，特性 TopologyAwareHints 和相关的服务机制不断成熟。虽然它主要服务于 Service 路由，但其理念是为有状态应用提供稳定的网络标识。

对于 StatefulSet，Pod 的主机名和 DNS 记录是稳定的（<pod-name>.<svc-name>.<namespace>.svc.cluster.local）。结合 Headless Service，应用程序可以通过 DNS 名称可靠地发现对端，而不需要关心其底层 IP 是否变化。

这是 Kubernetes 原生推崇的方式：通过 Service 名称和服务发现来解耦对静态 IP 的依赖。 静态 IP 应被视为最后的手段。

总结与推荐

方法	适用场景	优点	缺点
Pod 注解 (方法一)	为少数特定 Pod（如网络网关、硬件模拟器）分配固定 IP。	配置简单，直接明了。	需自行管理 IP，与 Deployment 不兼容，有冲突风险。
指定 IP 池 (方法二)	让一组 Pod 使用特定的 IP 段（如不同租户、不同环境）。	实现网络逻辑隔离。	不是真正的静态 IP，IP 仍会变。
StatefulSet + 服务发现	大多数有状态应用（数据库、中间件等）。	云原生，K8s 原生支持，通过 DNS 提供稳定标识。	IP 本身可能还是会变，但对应用透明。

最佳实践建议：

1. 优先使用 Service：绝大多数场景下，应使用 Kubernetes Service 来为 Pod 提供稳定的网络端点，而不是追求 Pod 本身的静态 IP。

2. 如必须使用静态 IP ：优先选择方法一（Pod 注解） ，并将其用于由 StatefulSet 或单例 Pod 管理的 Pod，并建立严格的 IP 地址管理流程以避免冲突。

3. 避免与 Deployment 混用：切勿轻易为 Deployment 配置静态 IP，这会破坏其自动修复和扩缩容的能力。