K8S- Calico

Calico概述

Calico介绍

Calico是Kubernetes中广泛使用的网络插件，提供高性能、高可扩展性的网络解决方案。它基于BGP（边界网关协议）或IPIP隧道实现容器间通信，支持网络策略（NetworkPolicy）以增强安全性。

Calico的优点

• 高性能：基于三层路由（BGP）直接转发数据包，避免传统Overlay网络的性能损耗。
• 灵活性：支持多种网络模式（BGP/IPIP），适应不同场景需求。
• 强隔离性：通过NetworkPolicy实现细粒度的网络策略控制。
• 跨平台兼容：支持Kubernetes、OpenStack等平台。

Calico的缺点

• BGP依赖：在非BGP环境中需依赖路由反射器（RR），增加复杂度。
• IPIP开销：IPIP模式存在封装/解封装开销，性能略低于纯BGP。

Calico优势

• 无NAT，直接路由减少延迟。
• 支持大规模集群，路由表通过BGP自动分发。

---

Calico结构组成

架构

Calico核心组件包括：

• Felix：运行在每个节点上的代理，负责路由配置、ACL规则和状态报告。
• BIRD：BGP客户端，分发路由信息到集群节点。
• etcd/ Kubernetes API：存储网络配置和策略数据。

名词解释

• WorkloadEndpoint ：Pod的网络接口（如cali123456）。
• HostEndpoint：物理机或虚拟机的网络接口。
• IP Pool：分配给Pod的IP地址范围。

组网原理

• 每个Pod分配唯一IP，节点通过BGP交换路由信息。
• 数据包直接通过节点路由表转发，无需Overlay封装（BGP模式）。

Calico工作原理

1. Felix监听API Server，创建Pod时分配IP并配置本地路由。
2. BIRD将节点路由广播给其他节点或路由反射器（RR）。
3. 跨节点通信时，数据包通过节点间路由直达目标Pod。

---

Calico网络模式

BGP概述

• BGP模式：直接使用节点物理网络作为底层，通过BGP协议广播Pod路由。
• IPIP模式：在跨子网时通过IP隧道封装数据包，解决BGP路由不可达问题。

BGP两种模式

• Full-mesh：每个节点与其他节点建立BGP连接，适合小规模集群。
• Route Reflector（RR）：中心化路由反射器，减少BGP连接数，适合大规模集群。

BGP工作流程

1. 节点通过BGP交换Pod子网路由信息。
2. 目标Pod的IP匹配路由表后，数据包直接转发到目标节点。

Route Reflector模式

• 指定少数节点作为RR，其他节点仅与RR同步路由。
• 避免Full-mesh的O(n\^2)连接问题。

IPIP模式概述

• 跨子网通信时，原始IP包封装在另一个IP包中（源/目标为节点IP）。
• 解封装由目标节点完成，转发给Pod。

Pod1访问Pod2流程（BGP模式）

1. Pod1发送数据包到目标Pod2 IP。
2. 节点1根据路由表将数据包直接发送到节点2（通过物理网络）。
3. 节点2接收后转发给Pod2。

Pod1访问Pod2流程（IPIP模式）

1. Pod1发送数据包到Pod2 IP。
2. 节点1发现目标跨子网，封装数据包（外层IP为节点2）。
3. 节点2解封装后转发给Pod2。

---

Calico优势与劣势对比

BGP模式

• 优势：高性能、低延迟，无需封装。
• 劣势：要求底层网络支持BGP或静态路由配置。

IPIP模式

• 优势：跨子网通信无需BGP支持。
• 劣势：封装开销导致性能下降。

适用场景

• BGP：同子网或可控网络环境。
• IPIP：云服务商等不可控网络环境。

代码示例（Calico策略）：

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  selector: all()
  types:
  - Ingress
  - Egress

数学公式（IPIP封装开销）：

封装后包大小 = 原始包大小 + IP头（20字节）

Calico 概述

Calico 是一套开源的网络和网络安全方案，专为容器、虚拟机及宿主机之间的连接设计，支持 Kubernetes、OpenShift、Docker EE 和 OpenStack 等平台。其核心特点是基于纯三层网络模型，通过路由规则控制数据流，避免 Overlay 网络的额外开销。

优点

• 高性能：纯三层网络减少广播流量，资源利用率更高。
• 灵活性：支持端点漂移和 ACL 规则，适配多云和混合环境。
• 简单性：无隧道技术，路径更短，调试方便。

缺点

• 规模限制：路由数量与容器数量成正比，可能超出硬件处理能力。
• 运维复杂：节点上存在大量 iptables 规则和路由条目。
• 功能缺失：不支持 VPC 和流量控制，存在带宽抢占风险。

架构组成

Calico 采用分布式路由架构，核心组件包括：

• vRouter：运行在每个节点上的轻量级路由引擎，基于 Linux 内核转发数据。
• BGP 协议 ：用于传播路由信息，小规模部署可直接对等互联，大规模需引入 BGP Route Reflector 集中管理路由。

关键设计

• 无 Overlay：通过标准 IP 路由实现通信，避免 VLAN 或 VXLAN 的限制。
• 可扩展性：借鉴互联网路由模型，天然支持大规模部署。
• 低依赖：仅需三层网络可达，适配 VM、容器及裸金属场景。

适用场景

• 需要高性能网络：如金融、AI 训练等低延迟场景。
• 混合环境：跨云或虚拟机与容器共存的架构。
• 安全敏感场景：支持网络策略（NetworkPolicy）实现微隔离。

性能对比

• 资源开销：比 Overlay 网络（如 Flannel VXLAN）节省约 20% CPU 资源。
• 延迟优势：直连路由比隧道模式降低约 30% 的延迟。

注：实际性能因环境而异，建议通过基准测试验证。

Calico 架构组件解析

Calico 是一个基于 BGP（Border Gateway Protocol）的云原生网络解决方案，主要用于 Kubernetes 和其他容器编排平台。其架构包含多个核心组件，协同工作以实现高效的网络通信和安全策略管理。

核心组件及功能

Felix

负责本地节点上的网络配置，包括路由规则和 iptables 规则的更新。Felix 与每个节点上的 Agent 交互，确保 Pod 的网络策略和路由正确实施。

BGP Client (Bird)

作为 Calico 的 BGP 客户端，负责与其他节点或 BGP Route Reflector 交换路由信息。通过 BGP 协议，节点间动态学习 Pod 的路由，实现跨节点通信。

confd

监控 etcd 或 Kubernetes API 的数据变化，动态生成 BGP 配置（如 Bird 的配置文件）。确保网络策略或拓扑变更时，BGP 配置能及时更新。

ETCD

存储 Calico 的全局网络状态，包括 IP 分配、网络策略和节点路由信息。在 Kubernetes 集成模式下，也可直接使用 Kubernetes 的 API Server 替代 etcd。

Route Reflector (可选)

在大规模集群中，BGP Route Reflector 可减少节点间的 BGP 对等连接数，优化路由分发效率。替代全互联（full-mesh）模式，降低网络复杂度。

Kernel

依赖 Linux 内核的路由表和 iptables 实现数据包转发和过滤。Calico 通过内核路由表直接转发 Pod 流量，无需 overlay 网络，性能更高。

数据流示例

1. Pod 通信

   • Pod1（NodeA）访问 Pod3（NodeB）时，流量通过 caliXXX 虚拟接口进入主机网络栈。
   • Felix 配置的路由表将流量导向 NodeB 的 IP，通过物理网卡 eth0 发出。
   • NodeB 的 BGP Client 已学习到 Pod3 的路由，流量经 caliXXX 接口到达 Pod3。

2. 安全策略

   • iptables 规则由 Felix 动态管理，实施网络策略（如允许 Pod1 访问 Pod2，但拒绝访问 Pod4）。

关键接口与资源

• caliXXX：Calico 为每个 Pod 创建的虚拟接口，用于隔离 Pod 流量。
• eth0：节点的物理网络接口，用于跨节点通信。
• Routes：内核路由表存储 Pod 子网信息，由 Felix 和 BGP Client 协同维护。

优势与适用场景

• 性能：纯三层方案，避免 overlay 网络开销。
• 灵活性：支持网络策略、跨云部署和混合网络。
• 扩展性：通过 BGP 与现有数据中心网络集成。

如需进一步优化，可结合 Calico 的 IPIP 隧道或 eBPF 数据平面选项。

Calico 架构组件解析

Calico 是一个基于 BGP（Border Gateway Protocol）的云原生网络解决方案，主要用于 Kubernetes 和其他容器编排平台。其架构包含多个核心组件，协同工作以实现高效的网络通信和安全策略管理。

核心组件及功能

Felix

负责本地节点上的网络配置，包括路由规则和 iptables 规则的更新。Felix 与每个节点上的 Agent 交互，确保 Pod 的网络策略和路由正确实施。

BGP Client (Bird)

作为 Calico 的 BGP 客户端，负责与其他节点或 BGP Route Reflector 交换路由信息。通过 BGP 协议，节点间动态学习 Pod 的路由，实现跨节点通信。

confd

监控 etcd 或 Kubernetes API 的数据变化，动态生成 BGP 配置（如 Bird 的配置文件）。确保网络策略或拓扑变更时，BGP 配置能及时更新。

ETCD

存储 Calico 的全局网络状态，包括 IP 分配、网络策略和节点路由信息。在 Kubernetes 集成模式下，也可直接使用 Kubernetes 的 API Server 替代 etcd。

Route Reflector (可选)

在大规模集群中，BGP Route Reflector 可减少节点间的 BGP 对等连接数，优化路由分发效率。替代全互联（full-mesh）模式，降低网络复杂度。

Kernel

依赖 Linux 内核的路由表和 iptables 实现数据包转发和过滤。Calico 通过内核路由表直接转发 Pod 流量，无需 overlay 网络，性能更高。

数据流示例

1. Pod 通信

   • Pod1（NodeA）访问 Pod3（NodeB）时，流量通过 caliXXX 虚拟接口进入主机网络栈。
   • Felix 配置的路由表将流量导向 NodeB 的 IP，通过物理网卡 eth0 发出。
   • NodeB 的 BGP Client 已学习到 Pod3 的路由，流量经 caliXXX 接口到达 Pod3。

2. 安全策略

   • iptables 规则由 Felix 动态管理，实施网络策略（如允许 Pod1 访问 Pod2，但拒绝访问 Pod4）。

关键接口与资源

• caliXXX：Calico 为每个 Pod 创建的虚拟接口，用于隔离 Pod 流量。
• eth0：节点的物理网络接口，用于跨节点通信。
• Routes：内核路由表存储 Pod 子网信息，由 Felix 和 BGP Client 协同维护。

优势与适用场景

• 性能：纯三层方案，避免 overlay 网络开销。
• 灵活性：支持网络策略、跨云部署和混合网络。
• 扩展性：通过 BGP 与现有数据中心网络集成。

如需进一步优化，可结合 Calico 的 IPIP 隧道或 eBPF 数据平面选项。

Felix的核心功能

Felix作为Calico的核心组件，主要负责节点层面的网络管理与策略实施。其功能涵盖接口配置、路由规则下发、ACL策略管理及系统状态监控。

接口管理通过内核编程实现，确保主机间ARP请求与IP转发正常处理。路由规则直接写入Linux内核的FIB表，维护跨主机通信的数据转发路径。

ACL规则被注入内核网络栈，强制实施安全策略防止流量绕过监管。状态监控模块实时收集网络异常信息，并通过etcd存储供全局可视。

分布式数据存储

Etcd作为分布式键值存储，承担集群路由信息的持久化任务。生产环境推荐至少三个节点组成高可用集群，通过Raft协议保证数据一致性与故障容忍。

编排系统集成

Orchestrator plugin提供与云平台的深度集成能力。Kubernetes通过CNI插件接口与Calico交互，OpenStack则利用Neutron插件实现网络自动化配置。

BGP路由分发

Bird作为标准BGP客户端，动态同步节点路由信息。当Felix更新内核FIB时，Bird自动捕获变化并通过BGP协议广播至整个集群。

大规模部署采用BGP Router Reflector拓扑，将全网状连接优化为星型结构。RR节点作为路由中枢，显著降低N²规模带来的连接数压力。

管理工具集

Calicoctl提供命令行界面进行策略配置与状态查询，支持YAML/JSON格式的声明式管理。该工具可直接与etcd或Kubernetes API交互实现配置下发。

名词	作用
endpoint	接入到calico网络中的网卡称为endpoint
AS	网络自治系统，通过BGP协议与其它AS网络交换路由信息
ibgp	AS内部的BGP Speaker，与同一个AS内部的ibgp、ebgp交换路由信息。
ebgp	AS边界的BGP Speaker，与同一个AS内部的ibgp、其它AS的ebgp交换路由信息。
workloadEndpoint	虚拟机、容器使用的endpoint
hostEndpoints	物理机(node)的地址

Calico 与 Flannel host-gw 模式的对比分析

Calico 和 Flannel 的 host-gw 模式均基于路由表实现容器网络通信，但核心差异在于路由信息的维护方式。

Flannel host-gw 依赖 flanneld 进程静态维护路由表，需人工或脚本更新路由信息。Calico 通过 BGP（Border Gateway Protocol）动态分发和同步路由信息，实现集群内节点间路由的自动化管理。

Calico 的组网原理

Calico 的核心是通过 IP 路由实现跨节点容器通信，每个容器或虚拟机被分配一个 workload-endpoint（wl）。其数据转发流程如下：

容器 A 发送数据包时，根据本地路由表匹配目标容器 B 的 IP，路由表指向节点 B 的物理网卡 IP。节点 A 通过物理网络将数据包转发至节点 B，节点 B 根据本地路由表将数据包送达容器 B。

BGP 在 Calico 中的作用

Calico 的每个节点作为 BGP Speaker，通过 BGP 协议广播本节点容器子网的路由信息。其他节点学习并更新路由表，形成全集群路由拓扑。BGP 的路径选择算法（如最短路径）可优化流量走向，支持大规模集群的扩展。

性能与扩展性优势

相比 Flannel host-gw，Calico 的 BGP 动态路由避免了中心化组件的性能瓶颈，适合大规模集群。BGP 的成熟生态支持路由策略、多路径负载均衡等高级功能，适用于多云或混合云场景。

典型应用场景示例

跨可用区部署时，Calico 可通过 BGP 与底层网络设备对接，实现容器网络与物理网络的无缝集成。结合 RR（Route Reflector）角色可优化大规模集群的 BGP 路由收敛速度。

+--------------------+ +--------------------+

| +------------+ | | +------------+ |

| | | | | | | |

| | ConA | | | | ConB | |

| | | | | | | |

| +-----+------+ | | +-----+------+ |

| |veth | | |veth |

| wl-A | | wl-B |

| | | | | |

+-------node-A-------+ +-------node-B-------+

| | | |

| | type1. in the same lan | |

| +-------------------------------+ |

| |

| type2. in different network |

| +-------------+ |

| | | |

+-------------+ Routers |-------------+

| |

+-------------+

#从ConA中发送给ConB的报文被nodeA的wl-A接收，根据nodeA上的路由规则，经过各种iptables规则后，转发到nodeB。

#如果nodeA和nodeB在同一个二层网段，下一条地址直接就是node-B，经过二层交换机即可到达。

#如果nodeA和nodeB在不同的网段，报文被路由到下一跳，经过三层交换或路由器，一步步跳转到node-B。

核心问题是，nodeA怎样得知下一跳的地址？

答案是node之间通过BGP协议交换路由信息。

每个node上运行一个软路由软件bird，并且被设置成BGP Speaker，与其它node通过BGP协议交换路由信息。

可以简单理解为，每一个node都会向其它node通知这样的信息:

我是X.X.X.X，某个IP或者网段在我这里，它们的下一跳地址是我。

通过这种方式每个node知晓了每个workload-endpoint的下一跳地址。

2.4、Calico 工作原理

Calico把每个操作系统的协议栈认为是一个路由器，然后把所有的容器认为是连在这个路由器上的网络终端，在路由器之间跑标准的路由协议------BGP的协议，然后让它们自己去学习这个网络拓扑该如何转发。所以Calico方案其实是一个纯三层的方案，也就是说让每台机器的协议栈的三层去确保两个容器，跨主机容器之间的三层连通性。

对于控制平面，它每个节点上会运行两个主要的程序，一个是Felix，它会监听ECTD中心的存储，从它获取事件，比如说用户在这台机器上加了一个IP，或者是分配了一个容器等。接着会在这台机器上创建出一个容器，并将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。绿色部分是一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，你们路由的时候得到这里来。

由于Calico是一种纯三层的实现，因此可以避免与二层方案相关的数据包封装的操作，中间没有任何的NAT，没有任何的overlay，所以它的转发效率可能是所有方案中最高的，因为它的包直接走原生TCP/IP的协议栈，它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则，所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。

Calico 网络模式详解

BGP 边界网关协议

BGP（Border Gateway Protocol）是互联网上核心的自治路由协议，用于在不同自治系统（AS）之间交换路由信息。与传统的内部网关协议（IGP）不同，BGP基于策略路由而非简单的度量指标（如跳数或带宽）。在Calico中，BGP用于节点间的路由通告，确保Pod之间的跨节点通信高效可靠。

Route Reflector 模式（RR）

默认情况下，Calico采用Node-to-Node Mesh全互联模式，每个节点与其他所有节点建立BGP连接。这种模式在小型集群中表现良好，但随着集群规模扩大，连接数呈指数增长（N×(N-1)/2），导致资源消耗过大。

Route Reflector模式通过引入一个或多个中心化路由反射器（RR）优化拓扑：

• 普通节点仅与RR建立BGP连接，无需与其他节点直连。
• RR负责反射路由信息，减少全网状连接的需求。
• 适用于中大型集群，显著降低BGP连接数和运维复杂度。

IPIP 模式

IPIP（IP in IP）是一种隧道技术，将原始IP包封装在另一个IP包中传输。其特点包括：

• 跨子网通信：当Calico节点位于不同子网时，IPIP隧道可穿透底层网络限制。
• 性能权衡：封装和解封装会引入少量CPU开销，但避免依赖底层网络的BGP配置。
• 适用场景：适合云环境或网络策略限制严格的场景，无需依赖底层网络支持BGP。

与普通网桥的区别：

• 传统网桥基于MAC层，不涉及IP层。
• IPIP隧道通过路由建立点对点连接，实现跨子网的虚拟桥接。

模式选择建议

• 小规模集群：默认BGP全互联模式简单高效。
• 大规模集群：启用Route Reflector减少连接数。
• 跨子网或云环境：优先使用IPIP模式避免网络配置依赖。

代码示例（启用IPIP隧道）：

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  cidr: 192.168.0.0/16
  ipipMode: Always  # 启用IPIP
  natOutgoing: true

数学公式（BGP连接数计算）：

全互联模式连接数 = \frac{N \times (N - 1)}{2}

其中N为节点数。

3.1、BGP 概述

BGP（Border Gateway Protocol）是一种用于自治系统（AS）间交换路由信息的外部网关协议（EGP）。其核心功能是实现跨AS的无环路路由信息交换，通过AS路径（AS-PATH）等属性构建拓扑图，确保路由策略的有效实施。

3.2、BGP 协议特性

BGP采用TCP协议（端口179）建立可靠邻居会话，工作在应用层。其路径传输机制类似距离矢量协议，但选路依据并非传统度量值（如带宽），而是基于路径属性（如AS-PATH、NEXT_HOP、LOCAL_PREF等），因此被归类为路径矢量路由协议。

BGP支持增量更新机制，仅传播变化的路由信息，减少带宽消耗。路由宣告时携带子网掩码，支持CIDR（无类域间路由），具备链路状态协议的某些特征。

3.3、BGP 无环路机制

BGP通过AS-PATH属性避免环路。当路由器收到包含本AS号的BGP路由时，会直接丢弃该路由。例如：AS 100发出的路由经过AS 200传递回AS 100时，AS 100检测到自身AS号存在于AS-PATH中，判定为环路。

3.4、BGP 路径属性分类

BGP路径属性分为四类：

• 公认必遵（Well-known mandatory）：所有BGP实现必须识别且必须包含在更新消息中，如ORIGIN、AS-PATH、NEXT_HOP。
• 公认任意（Well-known discretionary）：所有BGP实现必须识别但可选择是否包含，如LOCAL_PREF、ATOMIC_AGGREGATE。
• 可选过渡（Optional transitive）：BGP实现可不识别，但需保留并传递给邻居，如AGGREGATOR、COMMUNITY。
• 可选非过渡（Optional non-transitive）：BGP实现可不识别且不传递，如MED、ORIGINATOR_ID。

3.5、BGP 邻居建立过程

BGP邻居建立分为三个阶段：

1. Idle：初始状态，等待启动事件。
2. Connect：尝试建立TCP连接，成功则进入OpenSent状态，失败则进入Active状态重试。
3. Established：TCP连接建立后交换Open消息，协商参数后进入该状态，开始路由交换。

3.6、BGP 路由优选规则

BGP按以下顺序评估路由优先级：

1. 优选权重（Weight）最高的路由（厂商私有属性，本地有效）。
2. 优选LOCAL_PREF最高的路由。
3. 优选本地始发的路由（如network或aggregate命令生成）。
4. 优选AS-PATH最短的路由。
5. 依次比较ORIGIN、MED、邻居类型（EBGP优于IBGP）、IGP成本等属性。

是的，Calico 项目与 Flannel 的 host-gw 模式在底层实现上确实有相似之处。两者都是通过路由表 实现容器数据包的跨节点转发，其核心原理是将容器网络的子网路由信息添加到宿主机的路由表中。具体差异主要体现在路由信息的维护机制上：

1. Flannel host-gw

   通过 flanneld 守护进程管理路由：

   • 监听 Kubernetes API 获取节点与子网映射
   • 在本地添加路由规则（如 10.244.1.0/24 via 192.168.0.2）
   • 需依赖 flanneld 进程的轮询更新

2. Calico BGP

   利用 BGP（Border Gateway Protocol） 协议实现路由分发：

   • 每个节点作为 BGP Speaker，通过 BGP 协议广播本节点容器子网
   • 相邻节点自动学习路由并更新本地路由表
   • 无需中心化进程干预，实现分布式路由同步

---

总结

虽然二者均依赖宿主机路由表转发数据包，但 Calico 通过 BGP 协议实现了路由信息的自动化、分布式维护，避免了 Flannel host-gw 对中心化进程的依赖，更适合大规模集群场景。

Calico BGP 概述

Calico 是一个基于 BGP（边界网关协议）的网络解决方案，主要用于容器网络通信。在 Kubernetes 环境中，Calico 通过 BGP 协议实现 Pod 之间的跨节点通信，避免了传统隧道方案（如 VXLAN）带来的性能开销。

核心组件与流程

1. 路由分发

   每个节点上的 Felix 组件负责监听本地 Pod 的路由信息（例如 10.244.1.10），并通过 BGP 协议将这些路由通告给集群中的其他节点。

   \\text{Felix} \\xrightarrow{\\text{BGP}} \\text{其他节点}

2. 直接路由通信

   当 Pod 1（10.244.1.10）访问 Pod 2（10.244.2.10）时：

   • 流量通过 cali34 虚拟接口进入主机网络
   • 目标路由指向 Node2 的物理 IP（192.168.31.63）
   • 经由底层网络直接转发至目标节点

架构优势

• 零隧道开销：BGP 路由使流量直接通过底层网络传输，无需封装/解封装
• 策略灵活：通过 Calico 的 NetworkPolicy 实现细粒度访问控制
• 高可扩展性：利用 etcd 存储路由状态，支持大规模集群

图示解析：
[Pod 1] --cali34--> [Node1] --BGP--> [Node2] --cali89--> [Pod 2]

好的，我们来梳理一下 BGP (边界网关协议) 在 Calico 网络中的作用和工作原理，并与 flannel host-gw 进行对比。

BGP 在 Calico 网络中的工作原理

1. 基础网络结构:

   • 当创建一个 Pod 时，Calico 会启动一个 infra container（通常称为 pause container），并调用其二进制程序（位于 /opt/cni/bin）来配置该 Pod 的网络。
   • Pod 通过一对 veth 设备连接到宿主机网络。一端在 Pod 的网络命名空间内，另一端是宿主机上以 cali 开头的虚拟接口（如 cali123456）。
   • 数据包从 Pod 发出，通过 veth 对到达宿主机上的 cali 接口，从而进入宿主机内核的网络协议栈进行处理。

2. 路由驱动:

   • Calico 的核心机制是纯路由 。它不依赖网桥（如 flannel 的 flannel.1）或隧道封装（如 VXLAN）。

   • 每个宿主机都维护着一个路由表。当宿主机内核协议栈处理来自 cali 接口的数据包时，会根据目的 IP 查询这个路由表来决定数据包的下一跳。

   • 使用 ip route 命令可以查看路由条目。这些条目通常形如：

     目的 Pod 子网网段 via 下一跳 IP dev 宿主机的物理网卡 (如 eth0)

     例如：10.244.2.0/24 via 192.168.1.102 dev eth0

   • 这个下一跳 IP 就是目标 Pod 所在宿主机的 IP 地址 。数据包会直接从当前宿主机的物理网卡（如 eth0）发送出去，到达目标宿主机。

3. 路由信息分发 - BGP 的作用:

   • 关键问题：每台宿主机如何知道其他宿主机上的 Pod 子网应该通过哪个下一跳（即哪个宿主机 IP）到达？
   • Calico 在每个宿主机（或特定节点）上运行一个 BGP Client （通常是 bird 或 felix）。这个 BGP Client 扮演 BGP Speaker 的角色。
   • 这些 BGP Speaker 之间会建立 BGP Peer 连接（通常是全互联模式 full mesh，或通过路由反射器 route reflector）。
   • 每个 BGP Speaker 会向它的 Peer 宣告（advertise）本机所拥有的 Pod 子网信息（例如：10.244.1.0/24 可经由本机 IP 192.168.1.101 到达）。
   • 通过 BGP 协议，这些路由信息在所有建立了 Peer 关系的 BGP Speaker 之间自动交换和同步。
   • 最终，每个宿主机都学习到了集群中所有其他 Pod 子网的路由信息，并写入宿主机的内核路由表。这使得跨主机 Pod 通信成为可能。

4. 与 Flannel host-gw 的对比:

   • 相似点 ：两者都使用纯路由 模式（host-gateway）。数据包在跨主机通信时不经过隧道封装，直接从源宿主机的物理网卡发送到目标宿主机的物理网卡。效率较高。
   • 核心区别 - 路由分发机制 :
     • Flannel host-gw ：依赖一个中心化的组件（通常是 flanneld）来收集所有宿主机的子网信息，然后将完整的路由信息静态地下发到每个节点。节点本身不参与路由协议的交换。
     • Calico (BGP) ：使用去中心化 的 BGP 协议 进行路由信息的分发。每个节点（BGP Speaker）都参与其中，动态地学习、宣告和更新路由信息。这是一种动态路由协议。
   • 优势 :
     • 可扩展性/成熟性：BGP 是互联网骨干网使用的路由协议，经过大规模验证，非常适合大型集群。
     • 灵活性：支持更复杂的网络拓扑和路由策略（如通过路由反射器优化全互联、设置 AS Path、Community 等）。
     • 路由收敛：在节点或网络路径发生变化时，BGP 能够自动重新计算最优路径并更新路由表，提高网络的恢复能力。

为什么叫"边界网关协议"（Border Gateway Protocol）？

• BGP 设计之初是为了解决不同自治系统之间的路由问题。
• 自治系统是一个在统一管理域下、具有独立路由策略的网络集合（例如：一个大型企业网、一个 ISP 的网络）。
• 边界 指的是自治系统之间的连接点。位于自治系统边界的路由器称为边界网关路由器。
• BGP 运行在这些边界网关路由器上，负责在不同自治系统之间交换路由信息，并基于策略决定哪些路由可以接收、宣告以及选择最优路径。
• 在 Calico 的语境下：
  • 可以将每个 Kubernetes 节点（运行 BGP Speaker）视为一个微型的"自治系统"的代表（因为它管理着自己节点上的 Pod 子网）。
  • 节点之间建立的 BGP Peer 连接，模拟了自治系统边界路由器之间的连接。
  • 它们通过 BGP 协议交换"自治系统"（节点）内部（Pod 子网）的路由信息，实现跨"自治系统"（节点）的通信。

配置位置

• Calico CNI 二进制插件：/opt/cni/bin/
• CNI 网络配置（定义 IPAM、网络类型等）：/etc/cni/net.d/

总结：Calico 利用 BGP 协议在集群节点间动态分发路由信息，实现纯路由模式的 Pod 网络通信。相比 Flannel host-gw 的静态路由下发，BGP 提供了更好的可扩展性、灵活性和成熟度，尤其适合大型 Kubernetes 集群。其名称"边界网关协议"源于它在不同网络自治系统边界交换路由的核心设计思想，Calico 借用此概念在节点间交换 Pod 子网路由。

Calico 与 Flannel host-gw 网络模型对比分析

核心通信流程差异

Calico 和 Flannel host-gw 在跨节点通信时存在本质差异：

1. Calico 数据包流向

   • 源容器通过 Veth Pair 进入宿主机网络栈
   • 宿主机路由表指向目标节点 IP（三层路由）
   • 目标节点通过 cali 设备将数据包注入目标容器
   • 全程未修改数据包 MAC 地址

2. Flannel host-gw 特殊处理

   • 目标节点收到数据包后执行 ARP 代理：

   if 数据包目的IP == 本机容器网段:
       替换目标MAC为本机MAC地址  # 伪二层转发

   • 通过 flannel 接口将数据包送入容器网络栈
   • 需维护容器 IP 与宿主机 MAC 的映射关系

路由规则对比

特征	Calico	Flannel host-gw
路由类型	BGP 动态路由	静态主机路由
路由表示例	10.244.1.0/24 via 192.168.0.2	10.244.2.0/24 dev flannel.1
跨节点跳数	直接节点跳转	需经过 overlay 接口
MAC 处理	保持原始 MAC	目标 MAC 替换为宿主机 MAC

网络拓扑差异

Calico 构建的是纯三层路由网络： $$ \text{Pod}_1 \xrightarrow{\text{L3}} \text{Node}_1 \xrightarrow{\text{BGP}} \text{Node}_2 \xrightarrow{\text{L3}} \text{Pod}_2 $$

Flannel host-gw 本质是伪二层网络： $$ \text{Pod}_1 \xrightarrow{\text{ARP代理}} \text{Node}_1 \xrightarrow{\text{伪L2}} \text{Node}_2 \xrightarrow{\text{ARP代理}} \text{Pod}_2 $$

性能影响

• Calico 省去 MAC 重写操作，减少 CPU 开销约 15%
• Flannel host-gw 的 ARP 代理机制增加约 0.2ms 延迟
• 两者均无隧道封装开销，性能显著优于 VXLAN 模式

关键结论：Calico 通过纯 IP 路由实现跨节点通信，而 Flannel host-gw 依赖 ARP 代理模拟二层互通，这是两者最核心的架构差异。

3.1.6 Route Reflector 模式（RR）（路由反射）

设置方法请参考官方链接 https://docs.projectcalico.org/master/networking/bgp

Calico 维护的网络在默认是 （Node-to-Node Mesh）全互联模式，Calico集群中的节点之间都会相互建立连接，用于路由交换。但是随着集群规模的扩大，mesh模式将形成一个巨大服务网格，连接数成倍增加。这时就需要使用 Route Reflector（路由器反射）模式解决这个问题。确定一个或多个Calico节点充当路由反射器，让其他节点从这个RR节点获取路由信息。

在BGP中可以通过calicoctl node status看到启动是 node-to-node mesh 网格的形式，这种形式是一个全互联的模式，默认的BGP在k8s的每个节点担任了一个BGP的一个喇叭，一直吆喝着扩散到其他节点，随着集群节点的数量的增加，那么上百台节点就要构建上百台链接，就是全互联的方式，都要来回建立连接来保证网络的互通性，那么增加一个节点就要成倍的增加这种链接保证网络的互通性，这样的话就会使用大量的网络消耗，所以这时就需要使用Route reflector，也就是找几个大的节点，让他们去这个大的节点建立连接，也叫RR，也就是公司的员工没有微信群的时候，找每个人沟通都很麻烦，那么建个群，里面的人都能收到，所以要找节点或着多个节点充当路由反射器，建议至少是2到3个，一个做备用，一个在维护的时候不影响其他的使用。

3.2、IPIP 模式概述

IPIP 是linux内核的驱动程序，可以对数据包进行隧道，上图可以看到两个不同的网络 vlan1 和 vlan2。基于现有的以太网将原始包中的原始IP进行一次封装，通过tunl0解包，这个tunl0类似于ipip模块，和Flannel vxlan的veth很类似。

3.2.1 Pod1 访问 Pod2 流程如下：

1、数据包从 Pod1 出到达Veth Pair另一端（宿主机上，以cali前缀开头）。

2、进入IP隧道设备（tunl0），由Linux内核IPIP驱动封装，把源容器ip换成源宿主机ip，目的容器ip换成目的主机ip，这样就封装成 Node1 到 Node2 的数据包。

此时包的类型：

原始IP包：

源IP：10.244.1.10

目的IP：10.244.2.10

TCP：

源IP: 192.168.31.62

目的iP：192.168.32.63

3、数据包经过路由器三层转发到 Node2。

4、Node2 收到数据包后，网络协议栈会使用IPIP驱动进行解包，从中拿到原始IP包。

5、然后根据路由规则，将数据包转发给cali设备，从而到达 Pod2。

3.3 Calico 优势 与 劣势

优势

没有封包和解包过程，完全基于两端宿主机的路由表进行转发

可以配合使用 Network Policy 做 pod 和 pod 之前的访问控制

劣势

要求宿主机处于同一个2层网络下，也就是连在一台交换机上

路由的数目与容器数目相同，非常容易超过路由器、三层交换、甚至node的处理能力，从而限制了整个网络的扩张。(可以使用大规模方式解决)

每个node上会设置大量（海量)的iptables规则、路由，运维、排障难度大。

原理决定了它不可能支持VPC，容器只能从calico设置的网段中获取ip。

3.4 两种网络的对比

IPIP网络：

流量：tunl0 设备封装数据，形成隧道，承载流量。

适用网络类型：适用于互相访问的pod不在同一个网段中，跨网段访问的场景。外层封装的ip能够解决跨网段的路由问题。

效率：流量需要tunl0设备封装，效率略低

BGP网络：

流量：使用路由信息导向流量

适用网络类型：适用于互相访问的pod在同一个网段，适用于大型网络。

效率：原生hostGW，效率高

总结：

项目	IPIP	BGP
流量	tunl0封装数据，形成隧道，承载流量	路由信息导向流量
适用场景	Pod跨网段互访	Pod同网段互访，适合大型网络
效率	需要tunl0设备封装，效率略低	原生hostGW, 效率高
类型	overlay	underlay