Kubernetes 集群的网络层负责为每个 Pod 分配独立 IP 并实现跨节点通信，而 CNI（容器网络接口）插件的选择直接影响集群的连通性、性能与安全策略能力。Calico 是当前使用最广泛的 CNI 插件之一，它以纯三层路由为基础，不依赖二层网桥，支持网络策略与 BGP 动态路由。不过很多团队在配置 Calico 时经常忽略 IP 池范围、封装模式以及网卡自动检测等关键参数，导致 Pod 无法获取 IP 或跨节点访问超时。下面将结合一个标准的 v1.25 以上 Kubernetes 集群，演示 Calico 从安装到策略验证的完整流程。

Calico 的核心组件与数据面选择

Calico 并不是一个单一进程，而是由多个组件协同完成网络配置与策略下发。其中 calico-node 以 DaemonSet 形式运行在每个节点上，内部包含 Felix 和 BIRD 两个关键模块。Felix 负责监听 Kubernetes API 中的网络策略和端点变化，并将规则写入节点的路由表与 iptables；BIRD 则是一个 BGP 守护进程，用于在节点之间交换路由信息，使得每个节点都知道去往其他节点 Pod 网段的路由。早期版本还依赖 etcd 存储数据，现在默认使用 Kubernetes API 作为数据存储，部署更简单。

在数据面层面，Calico 支持三种主要转发模式：IPIP、VXLAN 和直接 BGP 路由。IPIP 将原始 IP 报文再封装一层 IP 头，适合节点不在同一二层网络、底层不支持 BGP 转发的场景；VXLAN 则把二层帧封装在 UDP 中，兼容性更好，但对内核版本有一定要求。直接 BGP 路由性能最高，但要求底层网络能够传递节点间的原始报文，一般用于物理交换机支持 BGP 或节点同网段的私有云环境。大多数新手推荐从 IPIP 或 VXLAN 开始，待网络稳定后再评估是否需要切换到直接路由。

此外，Calico 还提供 calico-kube-controllers 组件，以 Deployment 形式运行，处理 IP 池回收、命名空间隔离等控制逻辑。如果启用了网络策略，该控制器还负责同步全局网络策略与命名空间网络策略。因此，在安装 Calico 时不仅要关注 node 组件状态，也要确认 controllers 是否正常运行，避免策略无法生效。

安装 Calico 的详细步骤与参数调整

官方推荐使用 Tigera Operator 或直接应用 manifest 文件安装 Calico。对于大多数自建集群，直接使用 manifest 更加直观。首先下载对应 Kubernetes 版本的 Calico 清单，例如 curl https://raw.githubusercontent.com/projectcalico/calico/v3.25.1/manifests/calico.yaml -O。不同版本的清单略有差异，建议选择与集群版本兼容的稳定版本，例如 Calico v3.25 支持 Kubernetes 1.24 至 1.27。下载后不要直接应用，而是根据实际网段修改其中的环境变量。

在 calico.yaml 中，最需要调整的参数是 CALICO_IPV4POOL_CIDR，它定义了 Pod 使用的 IP 地址池。默认值通常为 192.168.0.0/16，如果该网段与现有物理网络或容器网络冲突，必须修改。另一个关键变量是 IP_AUTODETECTION_METHOD，用于指定节点选择哪个网卡作为 BGP 源地址。如果节点有多个网卡且自动检测选错了网卡，会导致节点间 BGP 对等建立失败。常见设置包括 interface=eth0、can-reach=10.0.0.1 或 first-found。例如内部网卡名为 ens192，可以设置为 interface=ens192。

下面是修改后的关键片段示例：

- name: CALICO_IPV4POOL_CIDR
  value: "10.244.0.0/16"
- name: IP_AUTODETECTION_METHOD
  value: "interface=ens192"
- name: CALICO_IPV4POOL_IPIP
  value: "Always"

执行 kubectl apply -f calico.yaml 后，Calico 会以 DaemonSet 形式部署到每个节点。可以通过 kubectl get pods -n kube-system | grep calico 查看 Pod 是否正常运行。如果某个节点的 calico-node 一直处于 CrashLoopBackOff，通常是内核模块缺失或 CNI 配置目录权限问题。使用 kubectl logs -n kube-system calico-node-xxxxx -c calico-node 可以定位具体错误。安装完成后，还需要给节点打上标签或直接修改 IP 池，确保 Pod 能分配到预期网段。用 calicoctl get ippool -o wide 可以查看当前 IP 池状态，如果配置错误，可以编辑 ippool 资源调整 CIDR 和封装模式。

网络策略配置与连通性验证

Calico 的一大优势是原生支持 Kubernetes NetworkPolicy，而且扩展了更丰富的策略模型。验证网络策略之前，先确保基础连通性正常。可以在一个命名空间创建两个 Pod：一个作为客户端，一个作为服务端。使用 kubectl run client --image=busybox -- sleep 3600 和 kubectl run server --image=nginx。然后通过 kubectl exec client -- wget -qO- http://server-ip 测试访问。如果跨节点 Pod 无法互通，首先检查节点路由表是否包含目标 Pod 网段，命令为 ip route；其次检查 BGP 对等体状态，使用 calicoctl node status 输出每个节点的 BGP 连接情况。

网络策略方面，默认情况下 Kubernetes 允许所有 Pod 之间互通。一旦创建 NetworkPolicy，只有被规则允许的流量才能通过。下面是一个简单的策略示例，只允许来自同一命名空间且标签为 app=client 的 Pod 访问服务器 Pod 的 80 端口：

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

应用策略后，再次从客户端访问应该仍然成功，但从其他无标签 Pod 访问则应被拒绝。Calico 会将策略转化为 iptables 规则或 eBPF 程序（取决于数据面模式），网络策略的执行性能通常优于其他 CNI。使用 calicoctl get networkpolicy -o wide 可以查看策略是否已同步到所有节点。若策略未生效，检查 calico-kube-controllers 日志，通常与 RBAC 权限或策略格式错误有关。

生产环境优化与常见问题排查

在生产环境中部署 Calico 时，性能与稳定性同样重要。一个常见的优化是调整 MTU 大小。由于 IPIP 或 VXLAN 封装会额外增加头部长度，如果底层网络 MTU 为 1500，Pod 内部 MTU 应设置为 1400 或更小，避免分片导致性能下降。可以在 Calico 配置中通过 FELIX_IPV4SUPPORT 与 CALICO_IPV4POOL_IPIP 等参数间接控制，更直接的方式是在 CNI 配置中指定 mtu 字段。此外，对于大规模集群，建议为 BGP 配置 route reflector，减少全互联 BGP 对节点资源的消耗。

故障排查是运维 Calico 的必修课。以下场景需要特别关注：Pod 状态为 ContainerCreating 并报错 failed to allocate for range 0: no IP addresses available，说明 IP 池已耗尽，需要扩大 CIDR 或清理已删除 Pod 的残留 IP。节点之间无法 ping 通 Pod IP 时，先检查 bird 是否正常建立对等关系，执行 birdcl show protocols 查看 BGP 会话状态。对于使用 VXLAN 模式的集群，还需确认内核支持 VXLAN 模块，可通过 lsmod | grep vxlan 检查。另一个高频问题是网卡自动检测错误，导致节点间路由下一跳不可达；此时应固定 IP_AUTODETECTION_METHOD 为指定网卡或 can-reach 探测地址。

最后，Calico 的官方文档提供了完备的排错手册，但掌握 calicoctl 常用命令能快速定位问题。例如 calicoctl get nodes -o wide 显示所有节点及其 BGP 地址，calicoctl get ippool -o yaml 查看 IP 池详细配置，calicoctl get workloadendpoints 列出每个 Pod 对应的端点。通过持续监控这些资源状态，可以在网络异常发生前发现潜在风险。合理规划 IP 地址池、确定封装模式并定期检查 BGP 会话，是保证 Calico 稳定运行的关键。