CNI网络插件之Calico详解

原创已于 2025-05-26 11:25:08 修改 · 1k 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #php #开发语言

于 2025-05-22 14:38:19 首次发布

Kubernetes系列专栏收录该内容

243 篇文章

订阅专栏

Calico 是一款专为 Kubernetes 设计的高性能网络和网络安全解决方案，它通过纯三层网络模型提供 Pod 间通信，并支持细粒度的网络策略控制。以下从架构、工作原理、关键组件、配置优化到安全特性进行全面解析。

一、核心架构与工作原理

1. 核心定位

CNI 插件：为 Kubernetes Pod 提供网络连接能力。
网络策略引擎：基于标签定义细粒度的网络访问控制（类似防火墙）。
跨平台支持：支持公有云、私有云、裸金属等环境。

2. 纯三层网络模型

Calico 采用 IP 路由而非 Overlay 网络（如 VXLAN），直接通过三层网络转发流量：

每个 Pod 分配唯一 IP：可直接路由，无需 NAT 或封装。
基于 BGP 协议：通过边界网关协议（BGP）在节点间交换路由信息。
无隧道开销：性能接近原生网络，尤其适合高性能场景。

3. 数据平面实现

Pod A (192.168.1.2) → 主机网络栈 → 基于路由表转发 → 主机网络接口 → 物理网络 → 目标主机 → Pod B (192.168.2.3)

IP 路由：Calico 在主机上配置路由规则，将流量导向目标 Pod 所在节点。
BGP 路由反射器：在大规模集群中，通过 Route Reflector 减少全互联 BGP 会话数量。

4. 核心优势

高性能：基于纯三层路由（无 overlay 网络开销）。
扩展性：支持大规模集群（数千节点）。
安全增强：丰富的网络策略语法，支持全局和命名空间级策略。
混合云友好：支持跨集群网络和多租户隔离。

二、架构组件

1. 控制平面组件

（1）Felix

角色：运行在每个节点上的代理，负责配置路由和 ACL（访问控制列表）。
功能：
- 根据 Calico 网络策略生成 iptables 规则或 BPF 程序。
- 配置 VXLAN 或 IPIP 隧道（overlay 模式）。
- 维护节点上的路由表。
- 监控 Pod 生命周期事件。

（2）Etcd

角色：分布式键值存储，存储 Calico 的网络状态（如 IP 分配、策略规则）。
部署方式：
- 独立集群（推荐生产环境）。
- 利用 Kubernetes API Server（简化部署，性能稍低）。

（3）Typha

角色：Calico 的控制平面扩展组件，作为 Felix 和 API Server 之间的中间层。
作用：
- 减轻 API Server 压力（尤其在大规模集群中）。
- 实现 Felix 连接的负载均衡。

2. 数据平面组件

（1）BGP 路由

原理：利用边界网关协议（BGP）在节点间交换路由信息。
优势：纯三层网络，无需 overlay 隧道，性能接近原生网络。
限制：需要底层网络支持路由传播（如物理网络或支持 BGP 的 SDN）。

（2）IPIP/VXLAN 隧道

原理：当底层网络不支持 BGP 时，通过隧道技术封装数据包。
- IPIP：基于 IP 层封装，性能较高。
- VXLAN：基于 UDP 封装，支持更大规模网络和多租户。

三、Calico 网络模型

1. 路由模式（BGP 模式）

（1）工作原理

Pod IP 直接分配在节点网络中，通过节点间的 BGP 路由表实现互通。
每个节点作为 BGP 路由器，向其他节点宣告其 Pod 的路由。

（2）网络拓扑

Node1 (192.168.1.10)
├─ Pod1 (10.244.1.10)
└─ Pod2 (10.244.1.11)

Node2 (192.168.1.11)
├─ Pod3 (10.244.2.10)
└─ Pod4 (10.244.2.11)

BGP 路由表：
Node1 → 10.244.2.0/24 via 192.168.1.11
Node2 → 10.244.1.0/24 via 192.168.1.10

（3）优势与适用场景

优势：高性能、无额外封装开销。
适用场景：
- 物理网络或支持 BGP 的 SDN 环境。
- 对网络延迟敏感的应用（如数据库）。

2. 隧道模式（IPIP/VXLAN）

（1）工作原理

Pod IP 属于私有网段，通过隧道技术跨节点通信。
数据包在发送节点被封装（添加外层 IP 头），接收节点解封装。

（2）网络拓扑

Node1 → 数据包封装 → Node2
(192.168.1.10)      (192.168.1.11)
  └─ Pod1           └─ Pod3
(10.244.1.10)     (10.244.2.10)

原始数据包：
源 IP: 10.244.1.10 → 目标 IP: 10.244.2.10

封装后数据包：
源 IP: 192.168.1.10 → 目标 IP: 192.168.1.11
  载荷: 源 IP: 10.244.1.10 → 目标 IP: 10.244.2.10

（3）优势与适用场景

优势：无需底层网络支持路由，部署灵活。
适用场景：
- 公有云环境（如 AWS、Azure）。
- 网络基础设施不支持 BGP 的私有云。

四、网络策略详解

1. Calico 策略模型

（1）Kubernetes NetworkPolicy

标准 API：Kubernetes 原生网络策略资源。
局限性：语法简单，仅支持命名空间、标签选择器和端口过滤。

（2）Calico NetworkPolicy

扩展 API：Calico 自定义资源，提供更丰富的规则表达。
增强功能：
- 支持 IP 集（IPSet）和命名端口。
- 支持基于 HTTP/HTTPS 协议的七层过滤。
- 支持流量方向（ingress/egress）和优先级。

（3）GlobalNetworkPolicy

集群范围策略：跨命名空间的全局策略，用于系统级安全控制。
典型场景：
- 禁止外部访问核心服务（如 API Server）。
- 限制跨节点流量（如仅允许特定节点访问数据库）。

2. 策略示例

（1）基本 NetworkPolicy（Kubernetes 原生）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-database
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: mysql
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: wordpress
      ports:
        - protocol: TCP
          port: 3306

（2）高级 Calico NetworkPolicy

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-https
  namespace: frontend
spec:
  selector: app == 'web'
  types:
    - Egress
  egress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 443
        selector: has(public-service) || net == "0.0.0.0/0"

四、部署与配置

1. 部署方式

（1）Helm 安装

# 添加 Calico 仓库
helm repo add projectcalico https://docs.tigera.io/calico/charts

# 安装 Calico
helm install calico projectcalico/tigera-operator --version v3.25.0 \
  --namespace tigera-operator \
  --create-namespace

（2）Manifest 安装

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

2. 关键配置参数

（1）IP 地址管理（IPAM）

# 配置 IP 池（Calico 自定义资源）
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-pool
spec:
  cidr: 192.168.0.0/16
  ipipMode: Always  # 隧道模式：Always、CrossSubnet、Never
  vxlanMode: Never   # VXLAN 模式
  natOutgoing: true  # 启用 SNAT（默认 true）

（2）网络模式选择

# 配置 BGP 模式（直接路由）
kubectl patch installation.operator.tigera.io default \
  -p '{"spec":{"calicoNetwork":{"bgp":{"enabled":true}}}}' \
  --type=merge

# 配置 IPIP 隧道模式
kubectl patch installation.operator.tigera.io default \
  -p '{"spec":{"calicoNetwork":{"bgp":{"enabled":true},"ipPools":[{"cidr":"192.168.0.0/16","encapsulation":"IPIP"}]}}}' \
  --type=merge

五、性能优化

1. 禁用封装（推荐）

# 纯三层网络，无需VXLAN封装
calicoNetwork:
  encapsulation: None

2. 使用 BPF 加速

# 替换iptables为BPF实现
felix:
  bpf:
    enabled: true

3. 配置 BGP 路由反射器

# 适用于大型集群（>50节点）
bgp:
  routeReflectorClusterID: '224.0.0.1'
  serviceAccounts:
    routeReflector: calico-route-reflector

4、部署 Typha 减轻 API Server 压力

helm install calico projectcalico/tigera-operator \
  --set typha.enabled=true \
  --set typha.replicas=3

六、安全特性

1. 基于身份的访问控制

标签选择器：基于 Pod 标签而非 IP 地址定义策略。
命名空间隔离：默认拒绝跨命名空间访问，需显式允许。

2. 零信任网络

# 默认拒绝所有入站流量
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  selector: all()
  types:
  - Ingress
  ingress: []  # 空规则表示拒绝所有

3. 与 Kubernetes 集成

NetworkPolicy 控制器：自动同步 Kubernetes NetworkPolicy 到 Calico。
NetworkPolicy 验证：使用calicoctl验证策略有效性。

七、监控与故障排查

1. 关键指标

felix_active_endpoints：活跃端点数量。
bird_route_count：路由表大小。
policy_rule_processing_duration：策略处理延迟。

2. 故障排查工具

# 检查Calico节点状态
calicoctl node status

# 查看路由表
ip route show

# 验证策略应用
calicoctl get networkpolicy -o yaml

八、Calico 与其他 CNI 对比

特性	Calico	Flannel	Cilium
网络模型	纯三层路由	Overlay（VXLAN/IPsec）	eBPF 加速的三层 / 四层
性能	高（无封装开销）	中等（有封装开销）	极高（eBPF 优化）
网络策略	丰富（支持全局策略）	有限（依赖 kube-proxy）	高级（支持 L7 策略）
扩展性	好（BGP 路由反射器）	一般	好（eBPF 动态加载）
复杂度	中等（需理解 BGP）	低（简单配置）	高（需理解 eBPF）

九、生产环境最佳实践

1）网络规划：

为 Calico 分配专用 CIDR（如 192.168.0.0/16）。
避免与现有网络重叠。

2）高可用性：

部署多节点 etcd 集群。
配置多个 BGP Route Reflector。

3）监控与告警：

监控节点资源使用（CPU、内存）。
设置策略拒绝率告警阈值。

4）升级策略：

先在测试环境验证新版本。
使用 Helm 进行滚动升级。

总结

Calico 凭借其高性能的纯三层网络模型和强大的网络策略功能，成为生产环境中 Kubernetes 集群的首选网络方案。通过合理配置 BGP、优化路由策略和启用 BPF 加速，可在大规模集群中实现卓越的网络性能和安全性。建议根据集群规模和业务需求选择合适的部署模式，并通过持续监控确保网络稳定运行。