在K8S中，Calico 网络组件实现原理?

Calico 是一个高性能、高度可扩展的 Kubernetes 网络和网络策略解决方案。其核心目标是提供纯三层的网络模型（基于 IP 路由），避免传统 Overlay 网络（如 VXLAN、Flannel VXLAN 模式）的性能开销和复杂性，同时提供强大的网络策略能力。以下是 Calico 的核心实现原理：

  1. 核心设计理念：纯三层网络

    • 目标： 让 Pod 之间的通信就像物理服务器之间的通信一样，直接使用 IP 路由，无需额外的封装和解封装（Overlay）。
    • 基础： 依赖底层物理网络（数据中心网络）的可路由性。Calico 假设集群节点之间是二层或三层互通的（IP 可达）。

  2. 关键组件及其作用：

    • calico/node (DaemonSet)： 运行在每个 Kubernetes 工作节点上的核心代理，包含多个子组件：
      • Felix: Calico 的“大脑”和“执行者”。
        • 路由管理： 在宿主机 Linux 内核的路由表中为本地 Pod 配置路由（通常是 via 网关指向宿主机的 Calico 虚拟接口）。当其他节点的 Pod 访问本机 Pod 时，Felix 确保回复包能被正确路由回来（通常通过配置 proxy_arp 或设置特定路由）。
        • ACL/策略编程： 将 Calico 的 NetworkPolicy 或 Kubernetes 原生 NetworkPolicy 资源翻译成宿主机的 iptables 规则 (或 eBPF，如果启用)，实现入口/出口流量控制、隔离、负载均衡（kube-proxy 替换）等。
        • 状态报告： 向 Orchestrator（如 calico/typha）报告节点状态（如工作状态、路由信息）。
      • BIRD (BGP Client): 路由分发引擎。
        • 路由学习： 从 Felix 获取本节点上所有 Pod 的路由信息（每个 Pod 拥有一个 /32 或 /128 的独立 IP）。
        • 路由广播： 使用 BGP (Border Gateway Protocol) 协议，将这些 Pod 路由广播给集群内的其他节点（通过节点上的 BIRD）或外部路由器（如 Top-of-Rack 交换机）。
        • 路由接收： 接收其他节点或路由器广播过来的 Pod 路由，并安装到本机的 Linux 内核路由表中。
      • confd (可选)： 监控 Calico 配置数据存储（如 etcd 或 Kubernetes API）的变化，动态生成 BIRD 的配置文件，触发 BIRD 重载。
    • calico/typha (Deployment)： 大规模集群优化组件（可选但推荐用于 >50 节点）。
      • 作用： 作为 Felix 和 calico/kube-controllers 与后端数据存储（etcd/Kubernetes API）之间的代理和缓存层。
      • 原理： 单个或少量 Typha 实例直接连接数据存储，处理大量 watch 事件。所有节点上的 Felix 只连接到本地的 Typha 实例，大大减少数据存储的连接数和事件风暴，提升集群稳定性和扩展性。
    • calico/kube-controllers (Deployment)： 监控 Kubernetes API 资源。
      • 作用： 负责同步 Kubernetes 资源（如 Namespace, Service, Pod 等）的状态到 Calico 的数据模型（etcd 或 Kubernetes CRD）。
      • 主要功能：
        • 策略控制器： 确保 Kubernetes NetworkPolicy 被 Calico 正确实现。
        • 节点控制器： 监控节点状态，在节点加入或离开时通知 Calico。
        • 服务帐户控制器： 处理与服务帐户相关的网络策略。
        • IPAM (IP 地址管理)： 管理 Pod IP 地址的分配和回收（Calico 通常使用自己的 IPAM，也可以与 host-local 或 DHCP 等 CNI IPAM 插件集成）。
    • calico/cni (CNI Plugin)： 安装在每个节点的 /opt/cni/bin 目录下。
      • 作用： 实现 CNI 规范。当 kubelet 创建/删除 Pod 时被调用。
      • 工作流程：
        1. kubelet 调用 calico 插件创建 Pod 网络。
        2. calico 插件调用 calico-ipam 子插件为 Pod 分配 IP 地址。
        3. 创建一对 veth pair：一端放入 Pod 网络命名空间（命名为 eth0），另一端留在宿主机命名空间（命名为 caliXXXXX）。
        4. 配置 Pod 内 eth0 的 IP 地址、路由等信息。
        5. 通知本地的 Felix：告知它新 Pod 的信息（IP, 接口等），Felix 随之配置主机路由、ARP、iptables/eBPF 规则等。
        6. 本节点的 BIRD 会将这个新 Pod 的 /32 或 /128 路由通过 BGP 通告出去。
    • 数据存储：
      • 选项： etcd 或 Kubernetes API Server (使用 CRD)。现代部署通常推荐使用 Kubernetes CRD 模式，减少对独立 etcd 的依赖，简化运维。
      • 存储内容： 节点信息、IP 地址池 (IPPools)、网络策略 (NetworkPolicy, GlobalNetworkPolicy)、工作负载端点 (WorkloadEndpoint)、主机端点 (HostEndpoint) 等。

  3. Pod 通信流程 (跨节点)：

    1. Pod A (Node 1) 发送数据包给 Pod B (Node 2)。
    2. Pod A 的 eth0 是 veth 的一端，数据包通过 veth pair 到达 宿主机 Node 1 的 caliXXXXX 接口。
    3. Node 1 的内核根据目的 IP (Pod B 的 IP) 查询路由表。
    4. 路由表中有由 BIRD 学习并安装的路由条目：Pod_B_IP via Node_2_IP dev <物理网卡>。这条路由意味着“去往 Pod B 的 IP，下一跳是 Node 2 的 IP，从物理网卡发出”。
    5. 内核将数据包通过 Node 1 的物理网卡发出。
    6. 底层网络（交换机/路由器）根据 IP 路由将数据包转发到 Node 2。
    7. Node 2 的物理网卡收到数据包，内核查询其路由表。
    8. 路由表中有由 Felix 安装的路由条目：Pod_B_IP dev caliYYYYY (或类似)。这条路由意味着“去往 Pod B 的 IP，从 caliYYYYY 接口发出”。
    9. 数据包被发送到 caliYYYYY 接口（这是 Pod B 的 veth pair 在主机端的接口）。
    10. 数据包通过 veth pair 进入 Pod B 的网络命名空间，到达 eth0。

  4. IPIP 模式 (Overlay 选项)：

    • 场景： 当底层物理网络无法直接路由 Pod IP 时（例如，Pod IP 网段不在物理网络的路由表中，或者节点间存在严格的网络隔离）。
    • 原理： Calico 在源节点对原始 Pod 数据包进行 IP-in-IP 封装：
      • 外层 IP 头： 源地址 = Node1 IP, 目的地址 = Node2 IP。
      • 内层 IP 头： 源地址 = Pod A IP, 目的地址 = Pod B IP。
    • 封装后的包在底层网络中被视为普通的 Node-to-Node 流量进行路由。
    • 目标节点 Node2 收到包后，解封装，取出内层的 Pod-to-Pod 数据包，然后根据本地路由表转发给 Pod B。
    • 代价： 增加了封装/解封装开销（CPU），增大了数据包大小（MTU 问题），失去了纯三层的部分性能优势。

  5. 网络策略实现：

    • Calico 的核心优势之一是其强大的网络策略引擎（支持扩展的 Calico 策略和标准 Kubernetes 策略）。
    • 实现机制： Felix 将策略规则（基于标签选择器、CIDR、端口、协议等）编译成宿主机上的 iptables 规则链（或 eBPF 程序）。
    • 当数据包进入/离开主机或经过 veth 接口时，会经过这些 iptables/eBPF 链进行匹配检查。
    • 规则决定是 ALLOW, DENY 还是 LOG 数据包。
    • 这种在每个节点分布式执行策略的方式非常高效和可扩展。

  6. eBPF 模式 (替代 iptables)：

    • Calico 支持使用 eBPF (Extended Berkeley Packet Filter) 替代传统的 iptables 来实现服务负载均衡（替换 kube-proxy）、网络策略执行和数据路径转发。
    • 优势：
      • 性能更高： 尤其在高连接数或复杂策略场景下。
      • 延迟更低： 数据路径更短。
      • 更强的可观测性： 利用 eBPF 的追踪能力。
      • 更少的依赖： 可以移除 kube-proxy。
    • 原理： Felix 将策略和服务转发规则编译成 eBPF 程序，由内核中的 eBPF 虚拟机执行，直接作用于网络数据包的处理路径。

总结 Calico 的核心实现原理：

  1. CNI 插件 + veth pair: 为每个 Pod 创建虚拟网络接口并连接主机网络栈。
  2. Felix (Agent)： 在每台主机上配置路由、ARP、iptables/eBPF（策略、转发）。
  3. BIRD (BGP)： 在节点间自动分发每个 Pod 的 /32 或 /128 路由信息，实现纯三层互通。
  4. 数据存储 (etcd/CRD)： 存储集群网络状态（节点、IPAM、策略）。
  5. kube-controllers： 同步 K8s API 状态到 Calico。
  6. Typha： 大规模集群的扩展性和稳定性优化。
  7. (可选) IPIP： 在非路由网络中提供 Overlay 封装。
  8. (可选) eBPF： 高性能数据路径和策略执行引擎。

Calico 通过这种基于 BGP 的路由分发和分布式策略执行的架构，提供了高性能、可扩展、安全的 Kubernetes 网络解决方案，尤其适合对网络性能和策略有较高要求的生产环境。

posted @ 2025-08-16 19:58  天道酬勤zjh  阅读(31)  评论(0)    收藏  举报