cilium 路由模式：tunnel（默认）vs native

• tunnel（默认）
• native（云ENI|需要搭配云或者BGP路由器）
• aws 云内 eni
• google 别名 ip

native 模式可以简单概括为使用环境本身的路由能力：

• linux 内核
• 云上 VPC
• 使用 BGP 等路由技术

1. 一段话总结

文档详细介绍了 Cilium 的四种路由模式，包括：

• 默认的 Encapsulation（封装）模式（基于 VXLAN/Geneve 协议构建节点隧道 mesh，依赖节点间基础连通性，需开放特定 UDP 端口，存在 MTU 开销但配置简单、支持身份元数据传输）
• Native-Routing（原生路由）模式（依赖底层网络（IaaS VPC）路由 PodCIDR 能力，需配置内核路由或借助路由器/BGP daemon，无封装开销）
• AWS ENI模式（适用于 AWS 环境，Pod 使用 ENI IP 实现 VPC 内直接路由，支持安全组但受 ENI 数量限制）
• Google Cloud模式（基于GKE或自建集群，利用 Alias IP 实现 Pod IP 原生路由，结合 eBPF 提供负载均衡与策略 enforcement）

Encapsulation 最简单，其他要么是云上环境，要么需要借助路由器

同时分别说明了各模式的网络要求、优缺点、架构及配置参数。

3. 详细总结

二、各路由模式详细说明

1. Encapsulation（封装）模式

核心特性

• 默认模式：无需额外配置，Cilium 自动启用，依赖UDP-based封装协议（VXLAN 或 Geneve） 构建所有集群节点的隧道 mesh，节点间流量均通过封装传输。

网络要求

• 基础连通性：仅需节点间能互相访问，无需底层网络感知 PodCIDR。

• 端口与协议：底层网络及防火墙需允许封装数据包，具体端口如下表：

封装模式（Encapsulation Mode）	端口范围/协议（Port Range / Protocol）
VXLAN（默认）	8472/UDP
Geneve	6081/UDP

• IPv6 限制：若使用 IPv6 底层网络，集群必须为 纯IPv6集群 ，不支持双栈集群。

物理机使用 ipv4 提供租户网络即可，应该是支持双栈的

优缺点

类别	具体内容
优点	1. 简单性：底层网络拓扑无关，节点可跨多个路由/链路层域； 2. 地址空间：不受底层网络限制，PodCIDR 配置合理时单节点可运行大量 Pod； 3. 自动配置：与 K8s 等编排系统联动，新节点自动加入隧道mesh； 4. 身份上下文：支持传输源安全身份等元数据，减少远端节点身份查询。
缺点	MTU开销：封装头会占用带宽，VXLAN 协议每包额外消耗50字节，导致单连接最大吞吐量下降；可通过启用巨帧（Jumbo Frames） 缓解（1500 字节帧vs 9000 字节帧，相同 50 字节开销下效率更高）。

配置参数

参数名	作用与默认值
tunnel-protocol	设置封装协议，可选vxlan（默认）或geneve
underlay-protocol	设置底层 IP 协议，默认ipv4；ipv6仅支持纯 IPv6 集群，需底层网络支持
tunnel-port	设置封装协议端口，VXLAN默认8472，Geneve 默认6081

2. Native-Routing（原生路由）模式

核心特性

• 启用方式：通过配置routing-mode: native启用，不使用封装，而是依赖底层网络的路由能力转发数据包，将非本地端点的流量委托给 Linux 内核路由子系统处理（类似本地进程发包逻辑）。

网络要求

• 核心要求：连接集群节点的网络必须能路由PodCIDR（Pod 的 IP 段）。

• 路由实现方式（二选一）：

  • 依赖外部路由器：节点无需知晓所有 Pod IP，只需配置默认路由指向能路由所有 Pod 的路由器（常用于云厂商 VPC 内网络集成，如AWS、GCP）；

  • 节点间同步路由：每个节点需知晓所有其他节点的 Pod IP，并在 Linux 内核路由表中添加对应路由。若节点处于同一 L2 网络，可启用auto-direct-node-routes: true 自动处理；否则需额外组件（如 BGP daemon）分发路由（如 kube-router，已 deprecated）。

关键能力

• Cilium 会自动启用 Linux 内核的IP 转发功能，确保数据包能跨节点路由。

配置参数

参数类别	参数名	作用与说明
必选参数	routing-mode	设为native，启用原生路由模式
	ipv4-native-routing-cidr	设置原生路由生效的 CIDR 段（格式：x.x.x.x/y）
可选参数	direct-routing-skip-unreachable	若运行 BGP daemon 且集群网络有多个原生子网，设为true可实现跨可用区 L2 连通，无需 BGP 路由器转发

3. AWS ENI模式

核心特性

• 适用场景：AWS 环境专属，通过配置--ipam=eni启用，Pod 使用 AWS ENI（弹性网络接口）的IP，该 IP 在 AWS VPC 内可直接路由，无需封装或 SNAT。

优缺点

类别	具体内容
优点	1. 简化路由：Pod IP 为 VPC 内原生路由 IP，跨 Pod 通信无需额外转发； 2. 安全组支持：Pod 可配置安全组，且按节点池分配（不同节点池的 Pod 可获不同安全组）； 3. 无需 SNAT：避免源 IP 伪装带来的复杂度。
缺点	1. 资源限制：ENI IP 数量受EC2实例类型限制（小实例类型可分配 IP 少，难以运行大量 Pod）； 2. API依赖：ENI 及 IP 分配需调用 EC2 API，存在速率限制（可通过Cilium Operator缓解）。

架构逻辑

• Ingress（入站流量） ：

  • 流量通过实例挂载的 ENI（节点上显示为ethN接口）接收；
  • I P路由规则指定“所有发往本地 Pod IP 的流量”使用主路由表（如规则：from all to 192.168.105.44 lookup main）；
  • 主路由表含精确匹配路由，将流量导向 Pod 对应的 veth 接口（如192.168.105.44 dev lxc5a4def8d96c5）；
  • 流量通过 veth 进入 Pod 前，经 Cilium eBPF 程序处理（ enforce 网络策略、反向负载均衡、提供可见性）。

• Egress（出站流量） ：

  • Pod 网络命名空间的默认路由指向节点路由器 IP（通过 Pod 内eth0/节点lxcXXXXXX veth对），路由器 IP 来自 ENI 网段（用于 Path MTU 的 ICMP 错误发送）；

  • 流量通过 veth 后、进入 Linux 路由层前，经 Cilium eBPF 程序处理（enforce策略、负载均衡、功能扩展）；

  • IP路由规则指定“来自单个 Pod 的流量”使用该 Pod IP 所属 ENI 的专属路由表（如规则：from 192.168.105.44 to 192.168.0.0/16 lookup 92）；

  • ENI 专属路由表含默认路由，将流量导向 VPC 路由器（通过 ENI 接口，如default via 192.168.0.1 dev eth2）。

配置参数

参数名	作用与说明
必选参数	ipam: eni
可选参数	enable-endpoint-routes: "true"
	auto-create-cilium-node-resource: "true"
	egress-masquerade-interfaces: eth+

4. Google Cloud 模式

核心特性

• 适用场景：Google Cloud 环境（GKE 集群或自建 K8s 集群），基于Native-Routing 配置，利用 Google Cloud 网络层能力，结合 eBPF 提供高性能与丰富功能。

关键能力

• 寻址（Addressing） ：Cilium 从节点的 PodCIDR 中为 Pod 分配 IP ，通过Google Cloud Alias IP ranges实现 Pod IP 在 GCP 网络内的原生路由，无需封装或额外路由分发。

• 伪装（Masquerading） ：所有不落在ipv4-native-routing-cidr（默认集群CIDR）内的流量，会被伪装为节点IP，确保公网可路由。

• 负载均衡（Load-balancing） ：无论 GKE 版本，ClusterIP 负载均衡均通过eBPF实现，性能高效。

• 策略与可见性（Policy & Visibility） ：NetworkPolicy enforcement（策略执行）与网络可见性均通过eBPF提供，功能全面。

配置参数

参数名	作用与说明
必选参数	gke.enabled: true
	ipv4-native-routing-cidr: x.x.x.x/y

部署参考

• 可参考“Cilium Quick Installation”指南完成 GKE 集群上的 Cilium 安装。

---

4. 关键问题

问题1：Cilium 的 Encapsulation 模式与 Native-Routing 模式在底层网络依赖和性能上有核心差异，具体差异是什么？如何根据集群环境选择这两种模式？

答案

• 底层网络依赖差异：

  • Encapsulatio n模式：仅需节点间能互相访问（基础IP/UDP连通性），无需底层网络知晓 PodCIDR；但需开放特定 UDP 端口（VXLAN:8472，Geneve:6081），且 IPv6 底层仅支持纯 IPv6 集群。
  • Native-Routing 模式：依赖底层网络能路由 PodCIDR，需通过“节点指向外部路由器”或“节点间同步路由（如BGP）”实现；无需开放额外端口，但需配置 Linux 内核路由或依赖外部组件（如BGP daemon）。

• 性能差异：

  • Encapsulation 模式：因封装头（如 VXLAN 每包 50 字节）存在MTU开销，单连接最大吞吐量低于Native-Routing 模式，需通过巨帧缓解。
  • Native-Routing 模式：无封装开销，依赖底层网络原生路由，性能更优。

• 选择依据：

  • 若底层网络难以配置 PodCIDR 路由（如跨多个L2/L3域、无BGP能力），或追求配置简单性，选Encapsulation 模式；

  • 若底层网络支持 PodCIDR 路由（如云厂商网络、自建 BGP 集群），且对网络性能要求高，选 Native-Routing 模式。

问题2：在 AWS 环境中使用 Cilium 的 AWS ENI 模式，Pod 的 IP 分配与流量转发逻辑是什么？该模式存在哪些资源限制，如何缓解？

答案

• Pod IP 分配逻辑：通过配置ipam: eni启用 ENI IPAM 后端，Cilium 从 AWS EC2 实例挂载的 ENI 中为 Pod 分配 IP，该 IP 属于 AWS VPC 的 IP 段，可在 VPC 内直接路由，无需S NAT。

• 流量转发逻辑：

  • 入站（Ingress）：ENI（ethN）接收流量→IP 路由规则指向主路由表→主路由表将流量导向 Pod 的 veth接口→eBPF 程序处理（策略、负载均衡）→进入 Pod；
  • 出站（Egress）：Pod 默认路由指向节点路由器 IP（通过 veth 对）→流量经 veth 后由 eBPF 处理→IP路由规则指向 ENI 专属路由表→专属路由表将流量导向 VPC 路由器（通过ENI）。

• 资源限制与缓解方案：

  • ENI IP 数量限制：每个 EC2 实例可挂载的 ENI 数量及每个 ENI 可分配的 IP 数量受实例类型限制（如t3.micro 仅支持 2 个 ENI、每个 ENI 最多 10 个IP），导致单节点 Pod 数量受限；缓解方案：选择 ENI 配额更高的 EC2 实例类型（如m5.large）。

  • EC2 API 速率限制：ENI 创建、IP 分配需调用 EC2 API，高频操作可能触发 API 速率限制；缓解方案：使用 Cilium Operator 组件，通过批量操作、缓存等机制减少 API 调用频率，降低速率限制影响。

问题3：Google Cloud 环境中，Cilium 的 Google Cloud模 式如何实现 Pod IP 的原生路由？该模式相比其他模式，在负载均衡和网络策略上有哪些独特优势？

答案

• Pod IP 原生路由实现方式：Cilium 从 Kubernetes 节点的 PodCIDR 中为 Pod 分配 IP，结合Google Cloud Alias IP ranges功能，将 Pod IP 与节点的主网卡（如eth0）关联；Google Cloud 网络层自动识别 Alias IP，将发往 Pod IP 的流量直接路由到对应节点，无需封装或额外路由分发，实现原生路由。

• 负载均衡优势：无论 GKE 集群版本，ClusterIP 类型的服务负载均衡均通过eBPF技术实现，相比传统 iptables 负载均衡：

  • 减少流量转发层级（无需经过内核 iptables 链），降低延迟；
  • 支持更灵活的负载均衡策略，且性能更稳定（无 iptables 规则膨胀问题）。

• 网络策略优势：

  • 基于 eBPF 的实时 enforcement：网络策略（如入站/出站规则）通过 eBPF 程序在数据包进入/离开Pod 时实时生效，响应速度快于传统 iptables；
  • 细粒度可见性：eBPF 可采集 Pod 流量的详细指标（如源 IP、目的 IP、端口、流量大小），结合Cilium 的监控功能，提供更全面的网络可见性，便于问题排查。

参考

docs.cilium.io/en/stable/n…