Calico 面试题

答案：

Calico 采用分布式架构，核心组件包括 Felix、BIRD、confd、Typha 和 Datastore。

• Felix：运行在每个节点上的守护进程，负责配置网络接口、路由规则和 ACL（iptables/eBPF）。处理实际的网络策略执行和路由发布。
• BIRD：BGP 协议客户端，负责在节点间分发路由信息。Felix 将路由写入内核路由表后，BIRD 将它们通过 BGP 协议通告给其他节点。
• confd：监控 Calico 配置数据的变更，动态生成 BIRD 和 Felix 的配置文件。当网络策略或路由发生变化时触发重新加载。
• Typha：可选组件，当集群规模较大（超过 50 节点）时引入，作为 Felix 与 Datastore 之间的缓存代理，减少 Datastore 的并发连接压力。
• Datastore：存储 Calico 配置和状态信息，支持 etcd（独立部署）和 Kubernetes API Server（KDD 模式）两种后端。

适用场景：理解 Calico 组件架构是排查网络问题、规划大规模部署和组件优化配置的基础。

答案：

Calico 支持三种数据平面模式：标准 Linux（iptables）、eBPF 和 Windows。

标准 Linux（iptables/netfilter）

• 基于 Linux 内核的 iptables 规则和路由表实现数据包转发
• 利用内核 IP 转发功能，通过在节点上设置 iptables/ipset 规则实现网络策略
• overlay 封装使用 IPIP（IP in IP）或 VXLAN 隧道
• 优势：兼容性最好，不需要特殊内核版本或硬件支持

eBPF（Extended Berkeley Packet Filter）

• 使用 eBPF 程序替代 iptables 规则，在内核空间直接处理数据包
• 支持 Direct Server Return（DSR）模式，减少额外跳转
• 优势：更高吞吐量、更低延迟（降低 30-50%）、减少 iptables 规则复杂度
• 依赖：Linux 内核 5.3+，需开启 BPF 文件系统

Windows

• 适用于 Windows Worker 节点，不依赖 Linux 网络功能
• 使用 Windows HNS（Host Networking Service）和 Windows Filters

适用场景：性能敏感场景选择 eBPF 模式；低版本内核或需兼容旧系统时选择 iptables 模式；Windows 容器混合集群选择 Windows 模式。

答案：

Calico 提供纯 BGP 路由模式和 Overlay 隧道模式两种网络方案。

BGP 路由模式

• 每个节点作为 BGP 路由器，通过 BGP 协议将 Pod CIDR 通告给集群内其他节点
• 节点可以直接路由到其他节点上的 Pod IP，无需封装
• 支持两种拓扑：Full-mesh（节点两两互联，适合小集群）和 Route Reflector（集中式路由反射，适合大规模集群）
• 优势：无封装开销，数据包直接走原始网络路径，性能接近宿主机网络

Overlay 隧道模式（IPIP/VXLAN）

• 数据包通过 IPIP 或 VXLAN 隧道封装传输
• 对底层网络路由没有要求，不需要网络设备支持 BGP
• IPIP 封装头部 20 字节，VXLAN 封装头部 50 字节，存在 MTU 损耗
• 优势：兼容任何网络基础设施，跨网段通信无限制

适用场景：同物理网络段且路由可控的环境使用 BGP 模式；跨网络段、云环境或底层网络不可控时使用 Overlay 模式。

答案：

Calico 网络策略是对 Kubernetes NetworkPolicy 的超集，提供更丰富的策略语义和更细粒度的控制能力。

Kubernetes NetworkPolicy

• 仅支持 Pod 级别的网络策略
• 策略规则限于 IP 地址、端口和标签选择器
• 仅支持 Allow 规则（默认 Deny）
• 不支持优先级排序，多条策略取并集
• 不支持外部端点（External Entities）

Calico 网络策略增强

• GlobalNetworkPolicy：集群范围内生效，不限于单个 Namespace
• GlobalNetworkSet：定义外部 IP 集合（CIDR 或 IP 列表），可在策略中引用
• 规则动作：支持 Allow、Deny、Log、Pass 四种动作
• 优先级排序：每条策略可设置 order 字段，低数值优先匹配
• 协议感知：支持 ICMP 类型、ICMPv6、SCTP 协议
• HTTP 方法过滤：配合 Istio/Envoy 实现七层规则
• DoS 防护：Rate limiting 等能力

# Calico GlobalNetworkPolicy 示例
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-dns
spec:
  order: 100
  selector: all()
  egress:
    - action: Allow
      protocol: UDP
      destination:
        ports:
          - 53
        selector: k8s-app == "kube-dns"

适用场景：Kubernetes NetworkPolicy 满足基本租户隔离要求；Calico 策略用于安全合规要求严格的场景，如金融级多租户隔离、零信任网络架构。

答案：

Typha 是 Calico 在大规模集群中的关键组件，作为 Felix 与 Datastore（Kubernetes API Server）之间的数据访问代理和缓存层。

核心作用

• 连接聚合：将多个 Felix 实例对 Datastore 的 Watch 连接聚合到少量连接，减少 API Server 的并发 Watch 连接数
• 数据缓存：缓存 Calico 配置数据（网络策略、IPAM 分配等），Felix 从 Typha 获取配置，减少对 API Server 的直接访问
• 负载均衡：分发 Felix 的 Watch 请求到多个 Typha 副本，避免单点瓶颈
• 事件分发：Datastore 数据变更时，Typha 一次性通知所有 Felix 实例，减少重复处理

部署条件

• 集群节点数超过 50 的规模建议部署
• 节点数超 100 必须部署
• 小规模集群（< 50 节点）可以不部署，Felix 直接连接 API Server

# Calico Typha 配置示例
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  # Typha 服务地址
  typhaServiceName: calico-typha
  # 如果没有部署 Typha，设为空
  # typhaServiceName: ""

适用场景：大规模 K8s 集群部署 Calico 时必须规划 Typha，它是保证 Calico 控制平面在大规模下依然稳定的关键组件。

答案：

Calico 提供多种 IPAM（IP Address Management）模式，支持灵活管理 Pod IP 地址。

Calico IPAM 模式

• Host-local（默认）：每个节点分配一个 IP 池，Pod 从本节点的 CIDR 块中分配 IP。节点加入集群时自动分配 IP Block，节点删除时回收。
• Kubernetes IPAM：使用 Kubernetes 自身的 Node CIDR 分配机制，与 kube-controller-manager 的 --allocate-node-cidrs 配合。
• Cluster：全局 IP 池，Pod 的 IP 从集群级 IPAM 分配，不绑定到特定节点。Cluster 模式支持跨节点弹性调度。

IP 池（IPPool）配置

• 通过 Calico IPPool CRD 定义，支持多个 IP 池并存
• 每个 IP 池可指定 CIDR、节点选择器、NAT 出口模式
• 支持 IPv4、IPv6 和双栈

# Calico IPPool 示例
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: production-pool
spec:
  cidr: 10.48.0.0/16
  blockSize: 26  # 每个节点分配 64 个地址（/26）
  nodeSelector: all()
  natOutgoing: true
  disabled: false

IP 分配流程

1. 节点启动后，Felix/calico-node 从 IPPool 中为节点分配一个 IP Block
2. Pod 创建时，kubelet 通过 CNI 插件请求 IP
3. Calico CNI 从节点本地 Block 中分配一个可用 IP
4. 节点 IP Block 耗尽时自动申请新 Block
5. Pod 删除后 IP 回收回 Block，Block 空闲后回收回 IPPool

适用场景：Host-local 适合大多数生产集群；Cluster 模式适合 IP 地址紧张或需要集中管理 IP 分配的场景。

答案：

Felix 是 Calico 在每个节点上的核心代理，负责将 Calico 的策略和网络配置转换为实际的数据平面规则。

网络策略处理流程

1. 通过 Datastore Watch 机制监听 NetworkPolicy、GlobalNetworkPolicy、Profile 等策略资源变化
2. 解析策略规则，将标签选择器解析为具体的端点 IP 集合
3. 生成 iptables 规则链（或 eBPF 程序），编排安全组规则
4. 利用 ipsets 管理策略中引用的 IP 集合，减少 iptables 规则数量
5. 将策略规则应用到对应的网络接口（cali* 虚拟接口）

路由处理流程

1. 监听节点和 WorkloadEndpoint 的创建/删除事件
2. 为每个本地 Pod 创建路由 entry，指向容器侧的 veth 对端
3. 为远端 Pod 创建路由 entry，指向对端节点的 IP
4. 更新内核路由表，触发 BIRD 重新分发 BGP 路由

数据处理路径示例

Pod A 访问 Pod B：
  Pod A → caliA（veth）→ 内核路由表 → 查找到 Pod B 路由
    → 同节点：直接走 caliB → Pod B
    → 跨节点：BGP 路由 → Node B（IPIP/VXLAN/直接路由）→ caliB → Pod B

# Felix 关键配置参数
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  # 日志级别
  logSeverityScreen: Info
  # 外部连接的心跳间隔
  healthHost: "0.0.0.0"
  healthPort: 9099
  # 路由表模式
  routeTableRanges:
    - cidr: 10.48.0.0/16
      table: 1

适用场景：Felix 的配置调优直接影响网络策略生效速度和节点路由收敛时间，大规模集群需要根据节点密度调整同步间隔。

答案：

Calico eBPF 模式通过在 Linux 内核中注入 BPF 程序替代传统的 iptables/netfilter 路径，带来显著的性能提升。

性能提升

• 吞吐量提升 30-50%：eBPF 程序直接在内核态处理数据包，减少了用户态和内核态的上下文切换
• 延迟降低 40-60%：数据路径更短，减少了 iptables 规则链遍历的开销
• CPU 开销降低：大量并发连接时，eBPF 的哈希表查找远快于 iptables 规则匹配

关键改进点

• DSR（Direct Server Return）：NodePort 访问时，回程流量不经过本地节点直接回到客户端，消除了额外的网络跳转
• 跳过 netfilter 路径：启用 eBPF 后，数据包通过 BPF 程序直接转发，不再经过 iptables 和 conntrack
• 本地流量优化：同节点 Pod 间通信通过 BPF 程序直接处理，不经过 iptables

# 启用 Calico eBPF 模式
kubectl patch felixconfiguration default --type='merge' \
  -p '{"spec":{"bpfEnabled":true}}'
# 同时启用 DSR（可选）
kubectl patch felixconfiguration default --type='merge' \
  -p '{"spec":{"bpfExternalServiceMode":"DSR"}}'

# eBPF 模式 Felix 配置
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  bpfEnabled: true
  bpfExternalServiceMode: "DSR"  # 或 "Tunnel"（跨子网需要隧道模式）
  bpfKubeProxyIptablesCleanupEnabled: false
  bpfLogLevel: "Off"

适用场景：高吞吐量网关节点、NodePort 频繁使用的服务、对 P99 延迟敏感的应用、大规模集群。

答案：

Calico 通过集成 WireGuard 实现跨节点 Pod 间流量的传输中加密，保证自动化、高性能的节点间通信安全。

工作原理

1. Calico 在每个节点上自动创建 WireGuard 接口
2. 节点之间的 Pod 流量通过 WireGuard 隧道加密传输
3. WireGuard 密钥对由 Felix 自动管理，定期轮换
4. 非 Calico 管控的流量（如节点本身通信）不受影响
5. 加密对 Pod 和应用透明，无需修改应用代码

加密粒度

• WireGuard 加密作用于节点间路由层面
• 同一节点上的 Pod 间通信不经过加密（不跨网络）
• 支持排除特定 CIDR 或标签选择器不加密

# 启用 WireGuard 加密
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  wireguardEnabled: true
  # 可选：使用内核态 WireGuard（更快）或用户态 wireguard-go
  wireguardInterfaceName: "wireguard.cali"
  # 加密排除规则
  wireguardListeningPort: 51820

性能影响 WireGuard 相比 IPsec 性能更好，但加密仍然带来部分性能损耗，主要消耗 CPU 资源用于加密运算。

适用场景：跨公有云多区域集群、混合云环境下节点间通信加密、等保合规对传输加密有要求的部署。

答案：

Calico 通过 kube-proxy 替换功能或与 kube-proxy 协同工作来管理 Kubernetes Service 的 NodePort 和 LoadBalancer 流量。

kube-proxy 替换模式（eBPF）

• Calico eBPF 模式下可以直接替换 kube-proxy，不再需要 kube-proxy 组件
• eBPF 程序直接响应 NodePort/LoadBalancer 请求，将流量转发到后端 Pod
• 通过 DSR 模式优化回程路径

iptables 模式下的协同

• kube-proxy 管理 Service 相关的 iptables 规则
• Calico 管理 Pod 网络相关的路由和策略规则
• 两者独立工作，Calico 不干预 kube-proxy 的 Service 转发逻辑

Calico 默认行为

• NodePort 流量到达节点后，由 kube-proxy（或 eBPF 替代）做 DNAT 转发到后端 Pod
• 后端 Pod 可能在本节点或其他节点
• Calico 确保 kube-proxy DNAT 后的流量能正确路由到目标 Pod

# 在 eBPF 模式下替换 kube-proxy
kubectl patch felixconfiguration default --type='merge' \
  -p '{"spec":{"bpfKubeProxyIPTablesCleanupEnabled":false}}'
# 确保集群中没有 kube-proxy 运行
kubectl -n kube-system delete daemonset kube-proxy

适用场景：eBPF + DSR 模式适用于要求 NodePort 和 LoadBalancer 性能最大化的生产集群。

答案：

Full-mesh 模式中每个节点与其他所有节点建立 BGP 连接，Route Reflector 模式通过集中式路由反射节点管理路由分发。

Full-mesh 模式

• 每个节点与其他所有节点建立 BGP Peer 关系
• 连接数 = N × (N-1) / 2，50 节点产生 1,225 个连接
• 节点增减时全部节点的 BGP 会话需要重建
• 适用于小规模集群（< 50 节点）

Route Reflector 模式

• 部署一组专用 RR 节点，所有计算节点只与 RR 建立 BGP Peer
• 连接数 = N × R（R 为 RR 节点数），大幅减少连接
• 节点增减只需更新 RR 的 Peer 配置
• RR 可用多副本实现高可用

# 配置 Route Reflector（在 RR 节点上）
calicoctl apply -f - <<EOF
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: rr-config
spec:
  nodeSelector: has(route-reflector)
  peerSelector: all()
  asNumber: 64512
EOF

适用场景：小型集群用 Full-mesh 简单直接；100+ 节点必须用 Route Reflector；生产环境建议无论规模大小都使用 RR 模式，为集群扩展预留。

答案：

IPIP 和 VXLAN 是 Calico 支持的两种 Overlay 隧道封装技术，用于在底层网络不支持直接路由时实现跨节点 Pod 通信。

IPIP（IP in IP）

• 在原始 IP 包外封装一个新的 IP 头（20 字节）
• 协议号 4（IPIP），通过在 IP 头中设置 ipip 标记
• 只能封装 IPv4 单播流量
• MTU 损耗 20 字节，隧道开销较小
• Linux 内核原生支持，配置简单

VXLAN

• 在原始二层帧外封装 UDP 头（8 字节）+ VXLAN 头（8 字节）+ 外部 IP 头（20 字节）= 50 字节
• 使用 UDP 端口 4789，支持多租户（24-bit VNI 标识，支持 1600 万+ 租户）
• 支持二层和三层流量，广播/组播模拟
• MTU 损耗 50 字节
• 对底层网络设备兼容性更好（仅需支持 UDP 转发）

# Calico IPPool 配置封装模式
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  cidr: 10.48.0.0/16
  # IPIP 封装
  ipipMode: Always  # Always / CrossSubnet / Never
  # VXLAN 封装
  vxlanMode: Never  # Always / CrossSubnet / Never
  natOutgoing: true
  nodeSelector: all()

CrossSubnet 模式：根据源和目标节点是否在同一子网决定是否封装。同子网直接路由，跨子网自动封装，兼顾性能和兼容性。

适用场景：同网络环境选 IPIP（开销小）；跨网络段、多云或 VPC 环境下选 VXLAN（兼容性更好）；推荐使用 CrossSubnet 模式获得最佳性能。

答案：

Calico 支持多种部署方式，适配不同的环境和运维需求。

官方 Operator

• 通过 tigera-operator 资源自动管理 Calico 组件
• CRD 驱动，声明式配置，支持生命周期管理（升级/回滚）
• 自动处理 TLS 证书、RBAC 配置
• 支持 Tigera Cloud 监控集成

# Operator 方式安装
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/custom-resources.yaml

Manifest 方式

• 直接应用 YAML 清单文件部署 DaemonSet
• 手动控制每个组件版本和配置
• 适合需要精确控制安装细节的场景

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/calico.yaml

Helm Chart

• 通过 Helm Chart 管理部署参数
• Values 文件灵活配置 IPPool、MTU、网络模式等
• 适合 GitOps 和 IaC 场景

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm install calico projectcalico/tigera-operator --version v3.28

kubeadm 内置集成

• kubeadm 在初始化时直接指定 Calico 作为 CNI
• 通过 kubeadm init --pod-network-cidr 配置 Pod 子网

适用场景：生产环境推荐 Operator 方式，自动处理组件生命周期的复杂性；高度定制场景选择 Manifest 方式直接编辑配置。

答案：

Calico 通过 IPPool 的 natOutgoing 配置控制 Pod 访问集群外部网络时的 NAT 行为。

NAT Outgoing 原理

• Pod IP 通常是私有地址（如 10.48.0.0/16），外部网络无法直接路由
• 启用 natOutgoing: true 后，Pod 发往集群外部的流量通过节点 IP 进行 SNAT
• 源地址从 Pod IP 转换为节点 IP，外部响应回到节点后解 NAT 转发回 Pod
• Calico 使用 iptables MASQUERADE 规则或 eBPF 程序实现

配置方式

• 每个 IPPool 独立配置 natOutgoing
• 支持按 Node Selector 控制哪些节点的 Pod 启用 NAT
• 可以结合 floatIPs 实现 DNAT 从外部访问 Pod

# 启用 NAT Outgoing
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  cidr: 10.48.0.0/16
  natOutgoing: true  # Pod 出集群时做 SNAT
  nodeSelector: all()

识别 NAT 出站流量

# 查看节点 iptables NAT 规则
iptables -t nat -L POSTROUTING -n --line-numbers
# 检查 Calico 的 NAT 链
iptables -t nat -S | grep calico

适用场景：大多数云环境和混合云场景需要启用 NAT Outgoing，使 Pod 能访问互联网或外部 API；私有网络直连场景可关闭以保持端到端 IP 透明。

答案：

Calico 网络策略的 Log 规则动作允许对符合策略条件的流量进行日志记录，满足安全合规的审计需求。

Log 规则配置

• 在 NetworkPolicy 或 GlobalNetworkPolicy 中使用 action: Log
• Log 规则按 order 优先级执行，匹配到 Log 规则后流量继续匹配后续规则
• 不会阻断或放行流量，仅产生日志记录
• 日志由 Felix 输出，标记为 ACTION=LOG

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: audit-ssh-traffic
spec:
  order: 10
  selector: all()
  ingress:
    - action: Log
      protocol: TCP
      destination:
        ports:
          - 22
    # 日志后继续匹配其他规则
    - action: Deny
      protocol: TCP
      destination:
        ports:
          - 22

日志采集方式

• Felix 输出的日志格式：syslog 级别消息包含 calico-packet
• 可通过 Fluentd/Vector/Loki 采集节点日志中的 Calico 审计记录
• 通过 iptables LOG 目标输出到内核日志，Felix 采集后转发

应用场景

• 合规审计：记录所有数据库端口的访问尝试
• 安全分析：发现 SSH、数据库等非授权访问尝试
• 调试阶段：确认网络策略是否按预期生效

适用场景：金融行业审计要求、安全事件溯源分析、网络策略调试和验证。

答案：

Calico 通过 Dikastes（应用程序层策略组件）与 Istio 服务网格集成，在原有的四层网络策略基础上增加七层感知能力。

集成架构

• Istio 侧车（Envoy Proxy）处理七层流量，Calico 处理四层网络策略
• Dikastes 作为 Calico 的侧车容器，与 Envoy 协同工作
• Dikastes 从 Calico Datastore 获取七层策略定义，将其转换为 Envoy 的 RBAC 过滤器配置
• Envoy 执行 Dikastes 下发的七层策略规则

支持的七层策略

• HTTP 方法过滤（GET/POST/PUT/DELETE）
• 路径匹配（精确/前缀/正则）
• HTTP 头匹配
• gRPC 方法过滤
• JWT Token 验证集成

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: http-policy
  namespace: default
spec:
  selector: app == "web-server"
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: app == "web-client"
      http:
        methods: ["GET"]
        paths:
          - "/api/v1/*"

与 Service Mesh 的关系

• Calico 七层策略不取代 Istio 的 AuthorizationPolicy
• Calico 提供统一的策略定义接口（CRD），与 Calico 四层策略保持一致的声明式体验
• 适合已经使用 Calico 网络策略的团队，不需要学习 Istio 的独立策略语法

适用场景：微服务架构中的七层访问控制（如只允许 GET 读取 API）、API 网关的安全策略、多租户应用中的租户隔离。

答案：

Calico 节点故障的影响范围取决于故障类型和集群的网络拓扑。

控制平面故障

• Typha 或 Datastore 故障：现有网络连接继续工作，但策略变更无法下发
• BIRD 故障：BGP 路由更新无法发布，远端节点直到路由老化（默认 180 秒）才清除路由
• Felix 故障：节点上现有 Pod 的网络持续工作，但新 Pod 无法接入网络

数据平面故障

• 节点宕机：该节点上的 Pod 完全不可达，K8s 重新调度后新的 Pod 在其他节点正常启动
• 网络链路中断：BGP 会话断开，路由收敛完成后流量绕过故障链路

恢复机制

• Felix：DaemonSet 自动重启，Kubernetes 调度器保证 Pod 重建
• BGP 路由收敛：BIRD 在 BGP Hold Time（默认 90 秒）内未收到 Keepalive 断开会话
• Route Reflector 提供 BGP 连接冗余

# BGP 配置调优
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  logSeverityScreen: Info
  nodeToNodeMeshEnabled: true
  # BGP 参数调优
  listenPort: 179
  # 路由收敛加速
  # 可根据网络稳定性调整

适用场景：生产环境应部署多副本 Typha，配置 BGP Route Reflector 高可用，降低控制平面故障对集群网络的影响。

答案：

Calico 支持 Kubernetes 双栈集群，允许 Pod 同时获取 IPv4 和 IPv6 地址。

双栈配置

• 创建两个 IPPool，分别对应 IPv4 和 IPv6 CIDR
• Calico 自动为每个 Pod 分配 IPv4 和 IPv6 地址
• 支持双栈 BGP 路由发布（BGP 天然支持 IPv6）
• 支持双栈 Overlay（IPIP/IPv6、VXLAN/IPv6）

# 双栈 IPPool 配置
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: ipv4-pool
spec:
  cidr: 10.48.0.0/16
  ipipMode: CrossSubnet
  natOutgoing: true
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: ipv6-pool
spec:
  cidr: 2001:db8:1000::/48
  ipipMode: Never
  natOutgoing: true

适用场景：IPv6 迁移过渡期、需要 IPv6 合规的政务云部署、对地址空间有巨大需求的场景。

答案：

Calico 的 Admit Webhook 是 Kubernetes 准入控制器，用于在校验阶段强制执行 Calico 网络规范的一致性。

主要功能

• 验证网络策略 CRD 的语法正确性
• 防止误删除关键 Calico 资源（如默认 IPPool）
• 强制安全基线（如禁止创建允许所有流量通过的默认策略）
• 确保策略变更满足合规要求

工作流程

1. 用户提交 NetworkPolicy/GlobalNetworkPolicy 等 CRD 变更
2. Kubernetes API Server 调用 Calico ValidatingWebhookConfiguration
3. Webhook 服务校验资源的完整性和合规性
4. 不符合规则的变更被拒绝并返回错误信息

适用场景：多团队共享集群的安全管控、策略提交前的语法校验、防止误操作导致的网络中断。

答案：

大型集群中 Calico 通过 Typha、分层架构和资源限制机制保证控制平面的稳定性。

关键策略

• Typha 连接聚合：1000 节点集群中，Felix 数量从 1000 个 Watch 连接减少到 3-5 个 Typha 连接，API Server 负载降低 200 倍
• 数据分片：Typha 按节点和策略分片数据，Felix 只获取与自己节点相关的数据
• 增量同步：Felix 与 Typha/Typha 与 API Server 之间使用高效 Watch 机制，只传递变更增量
• 资源限制：Felix 配置 CPU/Memory Limits，防止内存泄漏影响节点
• Campbell 算法：控制 BGP 路由更新的抖动，避免路由震荡

# 大型集群 Felix 配置优化
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  # 控制同步间隔，避免抖动
  bpfLogLevel: "Off"
  # 减少日志量
  logSeverityScreen: Warning
  # 限制对 API Server 的并发请求
  maxConcurrentAPIRequests: 30

适用场景：200+ 节点集群必须部署多副本 Typha；500+ 节点集群推荐 Route Reflector 模式并启用增量同步优化。

答案：

Calico 和 Flannel 都是 Kubernetes 常见的 CNI 插件，但在架构、功能、性能和管理模式上有本质区别。

架构差异

• Flannel 聚焦于单纯网络连通性，通过 VXLAN/Host-gw 等后端实现跨节点通信
• Calico 提供网络连通性 + 网络策略全栈方案，包括 BGP 路由、安全策略、IPAM 等

策略能力

• Flannel 不支持 NetworkPolicy，需要配合其他工具（如 Polaris 或 third-party）
• Calico 原生支持完整的 Kubernetes NetworkPolicy 和扩展策略

性能对比

• Flannel 的 VXLAN 模式性能较低，Host-gw 模式性能好但网络受限
• Calico 的 BGP 模式性能接近裸机，eBPF 模式更强

适用场景：Flannel 适合小型集群、简单网络场景、追求快速部署；Calico 适合中大型生产集群、需要网络策略和安全管控的场景。

答案：

Calico 在 iptables 和 eBPF 模式下对 Service ExternalTrafficPolicy 的支持方式不同。

ExternalTrafficPolicy: Cluster（默认）

• NodePort 流量在到达节点后可能会被转发到其他节点的 Pod
• 源 IP 会经历 SNAT，丢失客户端真实 IP
• Calico 和 kube-proxy 按默认方式处理

ExternalTrafficPolicy: Local

• NodePort 流量只转发到本节点上的 Pod
• 保留客户端真实源 IP
• 需要 NodePort 所在节点上有对应的 Pod 副本，否则请求被丢弃

eBPF + DSR 模式的处理

• 启用 DSR 后，NodePort 流量的回程直接从目标 Pod 所在的节点返回客户端，不经过原始入口节点
• 即使使用 Local 模式也能获得更好的负载均衡

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: NodePort
  externalTrafficPolicy: Local  # 保留客户端 IP
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: my-app

适用场景：需要客户端真实 IP 的日志审计场景、源 IP 白名单控制场景。

答案：

Calico 组件启动失败的排查涉及 Pod 状态检查、日志分析和配置验证三个步骤。

calico-node Pod 启动失败

# 检查 Pod 状态
kubectl get pods -n calico-system -o wide
# 查看详细信息
kubectl describe pod calico-node-xxxx -n calico-system
# 查看日志
kubectl logs calico-node-xxxx -n calico-system -c calico-node
# 检查 Felix 启动日志
kubectl logs calico-node-xxxx -n calico-system -c calico-node | grep "FATAL\|ERROR\|panic"

常见启动失败原因

• MTU 配置错误：底层网络 MTU 小于 Calico 配置的 MTU，导致隧道端点无法连通
• 网卡接口名不匹配：Felix 依赖的 dataplaneInterface 配置与实际节点网卡名不符
• IPPool 冲突：Pod CIDR 与现有网络冲突
• 内核模块缺失：IPIP 或 BPF 模式需要的内核模块未加载
• Typha 不可达：Felix 启动时无法连接 Typha 或 API Server

# 检查 IPIP 内核模块
lsmod | grep ipip
# 检查 BPF 文件系统
mount | grep bpf
# 检测网络连通性
calicoctl node status

适用场景：新集群部署 Calico 时启动失败的标准化排查流程。

答案：

Calico 通过 eBPF 模式和 iptables 规则实现基础的网络流量优先级控制能力。

QoS 实现方式

• 带宽限制：通过 eBPF 的带宽管理特性（bandwidth 插件）限制 Pod 的入站和出站速率
• DSCP 标记：Calico 网络策略可以设置 IP 头中的 DSCP（Differentiated Services Code Point）值
• 优先队列：结合 Linux TC（Traffic Control）对不同类型的流量进行排队

# 在 Pod 注解中设置带宽限制
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/ingress-bandwidth: 100M
    kubernetes.io/egress-bandwidth: 200M

DSCP 标记配置

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: dscp-priority
spec:
  order: 10
  selector: app == "high-priority"
  egress:
    - action: Allow
      dscp: 46  # 对应 EF（Expedited Forwarding）

适用场景：VoIP 和视频流量优先传输、后端关键业务流量保障、基于 SLA 的多租户流量区分。

答案：

WorkloadEndpoint（工作负载端点）是 Calico 中表示容器或 Pod 网络接口的 CRD 资源，是网络策略和路由的基本作用对象。

WorkloadEndpoint 的内容

• 接口名称：Pod 的虚拟以太网接口名称（cali* 格式）
• IP 地址：Pod 分配的 IP 和 MAC 地址
• 标签：Pod 的 Kubernetes 标签，用于策略匹配
• 所属节点：Pod 所在的工作节点
• 所属 Namespace：Pod 所属的命名空间

工作方式

1. Pod 创建时，Calico CNI 向 API Server 或 etcd 创建对应的 WorkloadEndpoint
2. Felix 监听 WorkloadEndpoint 变化，配置本地网络接口和路由
3. 网络策略通过 Selector 选择对应的 WorkloadEndpoint 生效
4. Pod 删除时，对应的 WorkloadEndpoint 自动清理

# WorkloadEndpoint 示例（简化）
{
  "name": "node1.eth0-calico",
  "node": "node1",
  "endpoint": "eth0",
  "mac": "ee:84:62:10:9b:fa",
  "ip": "10.48.1.128/32",
  "interfaces": ["cali12345abcd"]
}

适用场景：WorkloadEndpoint 是 Calico 将 K8s Pod 映射到自身网络模型的关键抽象，理解它是理解 Calico 策略匹配和路由机制的基础。

答案：

Calico 支持跨 ASN（自治系统号）的 BGP 部署，适用于多区域或多管理域场景。

多 ASN 架构

• 每个地域或数据中心使用独立 ASN
• 通过 BGP 配置指定每个节点的 ASN
• 跨 ASN 路由通过 BGP 边界路由协议交互

# 指定节点 ASN
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  asNumber: 64512
  nodeToNodeMeshEnabled: false  # 关闭 Full-mesh
  # 默认 ASN 供未单独指定 ASN 的节点使用

# 为特定节点指定 ASN
apiVersion: projectcalico.org/v3
kind: Node
metadata:
  name: node-beijing
spec:
  bgp:
    asNumber: 65100  # 北京节点 ASN 65100
apiVersion: projectcalico.org/v3
kind: Node
metadata:
  name: node-shanghai
spec:
  bgp:
    asNumber: 65200  # 上海节点 ASN 65200

跨 ASN Peer 配置

# 配置跨 ASN BGP Peer
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: cross-asn-peer
spec:
  nodeSelector: region == "beijing"
  peerIP: 10.0.0.1
  asNumber: 65200  # 对端 ASN

适用场景：多数据中心网络打通、多云环境 BGP 网络互联、不同管理域的网络隔离策略。

答案：

Calico 的安全上下文通过 Pod 的 Security Context 和 Calico 的 GlobalNetworkPolicy 协同作用，控制 Pod 的网络访问权限。

Pod Security Context 相关

• privileged: true：Pod 可以绕过部分 Calico 网络策略（取决于具体配置）
• capabilities: NET_ADMIN：Pod 可以修改自身网络配置，可能绕开 Calico 策略
• hostNetwork: true：Pod 使用宿主机网络栈，Calico 策略不直接作用于此类 Pod

# 为 hostNetwork Pod 制定特殊策略
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: host-network-policy
spec:
  order: 10
  # 匹配 hostNetwork Pod
  preDNAT: true
  applyOnForward: true
  selector: all()
  ingress:
    - action: Deny
      destination:
        nets:
          - 10.48.0.0/16

Calico 安全策略增强

• 自动创建 Profile 自动包含命名空间默认的流量规则
• 支持 Pod 级别的端口白名单
• 基于 Namespace 隔离（默认拒绝跨 Namespace 通信）

适用场景：混合 hostNetwork 和正常 Pod 的集群安全加固、特权容器的网络访问管控。

答案：

Calico 各组件支持独立的日志级别配置，用于调试、监控和性能调优。

日志级别设置

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  logSeverityScreen: Info  # Debug/Info/Warning/Error

各级别用途

• Debug：输出最详细的调试信息，用于定位网络策略或路由问题。生产环境不建议开启，会产生大量日志
• Info：默认级别，输出组件的关键状态变更和事件信息，适合日常监控
• Warning：仅输出异常和告警信息，适合稳定运行的集群
• Error：仅输出错误信息，适合资源受限或日志量管控严格的场景

# 动态调整日志级别（无需重启）
calicoctl patch felixconfiguration default \
  -p '{"spec":{"logSeverityScreen":"Debug"}}'

适用场景：排查策略规则问题时临时开启 Debug，问题定位后恢复 Info；生产集群推荐 Warning 或 Error 减少日志 IO 压力。

答案：

Calico 支持在有多个网络接口的节点上选择特定的数据平面接口，适用于集群节点有多块网卡分别承载业务和管理流量的场景。

配置方式

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  # 指定 Calico 使用的网络接口
  dataplaneInterfacePrefix: eth1
  # 或多个接口匹配
  interfacePrefix: "cali,eth1,kube-ipvs"

多网卡场景的注意事项

• 需要指定 Felix 使用的接口前缀，确保 Pod 流量走正确网卡
• BGP Peer 的 IP 地址需与实际使用的网卡 IP 匹配
• IPIP/VXLAN 隧道的源 IP 是所选择网卡的 IP

适用场景：节点同时连接业务网络、管理网络和存储网络的多网卡服务器、GPU 节点中专用通信网卡场景。

答案：

Tigera Calico（企业版）在开源 Calico 基础上增加了商业化功能和管理能力。

企业版增强功能

• UI 管理界面：可视化仪表盘展示集群网络拓扑、策略关系、流量路径
• 合规报告：自动生成网络策略合规审计报告
• 入侵检测：集成 Suricata IDS/IPS，实时检测网络安全威胁
• DNS 策略：基于 DNS 域名的网络策略控制
• WEB UI：策略编辑器，策略可视化编排
• SLA 支持：商业支持和 SLA 保证
• 多集群管理：统一管理面板跨集群网络策略

适用场景：开源版适合技术力强、需求标准的团队；企业版适合对合规性、可视化、商业支持有要求的金融/大型企业。

答案：

calicoctl 是 Calico 的命令行管理工具，用于管理 Calico 资源、查看集群状态和故障排查。

常用命令

# 查看 Calico 节点状态
calicoctl node status

# 查看 IP Pool 配置
calicoctl get ippool -o wide

# 查看网络策略
calicoctl get networkpolicy --all-namespaces
calicoctl get globalnetworkpolicy

# 查看 BGP Peer 配置
calicoctl get bgppeer

# 查看 Felix 配置
calicoctl get felixconfiguration default -o yaml

# 查看节点 IPAM 分配
calicoctl ipam show --show-pools

# 查看 WorkloadEndpoint
calicoctl get workloadendpoint --all-namespaces

# 验证配置
calicoctl apply -f policy.yaml --validate

故障排查命令

# 查看 Felix 状态
calicoctl node diags

# 导出诊断信息
calicoctl node diags --output-dir=/tmp/calico-diags

# 查看 IP 路由表（节点视角）
calicoctl node routes

适用场景：日常 Calico 运维管理、网络问题排查、策略配置验证。

答案：

Calico 支持 Windows Worker 节点，为混合操作系统集群提供统一的网络策略和管理。

架构差异

• Windows 节点上运行 calico-node-windows 替代 Linux 的 Felix
• 使用 Windows HNS（Host Networking Service）和 HCS 进行网络配置
• BGP 路由功能通过 Windows BGP 路由表实现
• 网络策略通过 Windows Filtering Platform（WFP）驱动实现

限制

• eBPF 模式不支持
• IPIP/VXLAN Overlay 支持有限
• WireGuard 加密不支持
• 仅支持 Windows Server 2019+ 版本

适用场景：混合操作系统集群、遗留 .NET 应用迁移到 K8s 但必须保留 Windows 容器的场景。

答案：

Calico 支持在不重建集群的情况下动态调整 IPPool 配置，包括扩容 CIDR、修改封装模式和 NAT 设置。

操作流程

# 创建新的 IPPool（扩容）
cat <<EOF | calicoctl apply -f -
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: new-pool
spec:
  cidr: 10.49.0.0/16
  blockSize: 26
  natOutgoing: true
  nodeSelector: all()
EOF

# 标记旧池禁用（停止分配新 IP）
calicoctl patch ippool default-ipv4-ippool \
  -p '{"spec":{"disabled":true}}'

# 等待现有 Pod 迁移或重建
# 迁移完成后删除旧池
calicoctl delete ippool default-ipv4-ippool

注意事项

• 新创建 IPPool 不会影响已有 Pod 的 IP 地址
• 修改 IPPool 的封装模式需要重建受影响节点的 Pod
• 禁用 IPPool 后已有 Pod 继续工作，但新 Pod 不会再从该池分配 IP

适用场景：集群 CIDR 扩缩容、切换网络模式（IPIP to VXLAN）、Pod 密度调整（修改 blockSize）。

答案：

Felix 的配置参数直接影响 Calico 控制平面的资源消耗和策略生效速度。

关键性能参数

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  # 策略同步间隔（默认 1 秒）
  # 影响：数值越小策略生效越快，但 CPU 消耗越大
  reportingIntervalSecs: 5
  
  # 路由同步间隔
  routeRefreshIntervalSecs: 10
  
  # 节点间心跳间隔（检测节点存活）
  healthHost: "0.0.0.0"
  
  # Debug 日志禁用
  bpfLogLevel: "Off"
  
  # 日志级别
  logSeverityScreen: Warning
  
  # 最大 iptables 规则数
  # 大集群增加此值可减少规则分裂
  iptablesRefreshInterval: 60
  
  # 限制对 API Server 的请求并发
  maxConcurrentAPIRequests: 20

适用场景：大规模集群（200+ 节点）应增大同步间隔、降低日志级别；小规模集群可保持默认值以获得快速响应。

答案：

Calico 在 Pod 注解中提供多个配置项，用于控制 Pod 级别的网络行为。

支持的注解

apiVersion: v1
kind: Pod
metadata:
  annotations:
    # 指定 Pod 的 IP 地址（需要 IPAM 预留）
    cni.projectcalico.org/ipAddrs: '["10.48.1.100"]'
    
    # 指定 Pod 所在的 IPPool
    cni.projectcalico.org/ipv4pools: '["custom-pool"]'
    
    # 禁用 Calico 网络策略（绕过策略检查）
    cni.projectcalico.org/disableNetworkPolicy: "true"
    
    # 控制浮动 IP（DNAT）
    cni.projectcalico.org/floatingIPs: '["10.0.0.10"]'
    
    # 附加 IP 地址
    cni.projectcalico.org/ipAddrsNoIpam: '["192.168.1.1/24"]'

适用场景：遗留系统迁移需要固定 IP、特殊监控 Pod 需要绕过网络策略、多云场景下的 IP 规划控制。

答案：

当集群前有外部 LoadBalancer（如云厂商 ELB）时，Calico 通过 eBPF DSR 模式和 ExternalTrafficPolicy 配置优化流量路径。

外部 LB + Calico 配合

• 外部 LB 将流量转发到 Node 的 NodePort
• kube-proxy（或 eBPF）做 DNAT 到后端 Pod
• 启用 DSR 时，回程流量直接从 Pod 所在节点返回客户端，不经过 LB

LB 直接接入 Pod 网络

• 在 BGP 模式下，外部 LB 可作为 BGP Peer 接入 Calico 网络
• LB 可以直接路由到 Pod IP，无需经过 NodePort
• 配合 Calico 的 External NetworkSet 控制哪些外部 IP 可以访问 Pod

# 定义外部网络的 NetworkSet
apiVersion: projectcalico.org/v3
kind: GlobalNetworkSet
metadata:
  name: external-lb
  labels:
    role: load-balancer
spec:
  nets:
    - 203.0.113.0/24

适用场景：高流量外部入口服务、云原生应用对外暴露时优化延迟和吞吐量。

答案：

Calico 支持为 Pod 分配 Floating IP，允许外部网络通过该 IP 直接访问 Pod，无需经过 NodePort 或 Ingress。

配置方式

# 创建浮动 IP 池
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: floating-ip-pool
spec:
  cidr: 203.0.113.0/28
  natOutgoing: false
  disabled: false
  nodeSelector: all()

在 Pod 上启用浮动 IP

apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/floatingIPs: '["203.0.113.2"]'
spec:
  containers:
    - name: my-app
      image: my-app:latest
      ports:
        - containerPort: 80

实现原理

• Calico 在 Pod 所在节点上配置 DNAT 规则，将浮动 IP 的流量转发到 Pod IP
• 浮动 IP 不在任何网络接口上配置，纯 iptables/路由转发
• 多个 Pod 可以共享同一个浮动 IP，通过端口分发

适用场景：无需修改 DNS 即可将 Pod 暴露到外部、快速迁移外部访问入口。

答案：

Calico NetworkPolicy 的 order 字段控制策略的评估优先级，决定多条策略同时匹配时的生效顺序。

order 机制

• 数值越小优先级越高，order 低的策略先评估
• 多个策略按 order 升序执行
• 相同 order 的策略按名称字母序执行（不确定性行为）

策略评估流程

1. 收集所有匹配 Pod 的 Calico NetworkPolicy 和 GlobalNetworkPolicy
2. 按 order 升序排序
3. 依次评估每条策略的规则
4. 对于每条策略内的多条规则，按定义顺序评估
5. 遇到 Deny 动作直接拒绝，不继续评估
6. 遇到 Allow 动作放行，继续评估后续策略
7. 若所有策略评估完没有明确 Allow 则默认 Deny

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: platform-base
spec:
  order: 50  # 高优先级（首先评估）
  selector: all()
  ingress:
    - action: Deny
      protocol: TCP
      destination:
        ports:
          - 22

# 低优先级策略
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-ssh
  namespace: ops
spec:
  order: 100  # 低优先级
  selector: app == "bastion"
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 22

适用场景：分层安全策略设计，基础安全基线使用低 order 优先拦截，业务策略在后层精细控制。

答案：

Calico 和 Cilium 都利用 eBPF 技术提升网络性能，但在实现路径和设计哲学上存在差异。

设计差异

• Calico eBPF 模式是传统 iptables 模式的替代数据路径，核心网络模型仍然是基于路由的
• Cilium 是 eBPF-native 设计，从一开始就围绕 eBPF 构建，所有功能都基于 eBPF 实现

功能差异

性能对比

适用场景：Calico 适合已熟悉 Calico 策略语法的团队、需要统一网络策略管理的场景；Cilium 适合需要全栈 eBPF 能力和高级可观测性的场景。

答案：

裸金属集群相比云环境能够充分发挥 Calico BGP 模式的性能优势，但也面临不同的运维挑战。

网络模式选择

• 推荐 BGP 模式，无封装开销，发挥裸金属网络性能
• 如果底层网络不支持 BGP，使用 VXLAN CrossSubnet 模式
• 启用 eBPF 模式获得最佳性能

配置建议

# 裸金属 Calico 推荐配置
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  asNumber: 64512
  nodeToNodeMeshEnabled: false  # 关闭 Full-mesh
  # 配置 Route Reflector
  serviceClusterIPs:
    - cidr: 10.96.0.0/12
  serviceExternalIPs:
    - cidr: 0.0.0.0/0

运维要点

• 与底层网络团队协作配置物理交换机的 BGP 路由
• 使用 ECMP 负载均衡提升多路访问性能
• 规划独立的节点互联 IP 段和 Pod CIDR
• 配置 Bonding 或多路径提供网卡冗余

适用场景：高性能计算集群、私有数据中心、对网络延迟敏感的金融交易系统。