集群 CNI 更换指南:安装支持网络策略的 Calico 3.28.2
在 Kubernetes 集群运维过程中,容器网络接口(CNI)的稳定性和安全性至关重要。近期有用户反馈,集群原有的 CNI 未通过安全审核已被移除,急需安装一款既能实现 Pod 间通信,又能支持网络策略(Network Policy)实施的新 CNI。本文将围绕这一需求,从 CNI 选型、核心知识点、安装步骤及验证方法等方面,详细讲解如何安装 Calico 3.28.2(满足需求的最优选择),帮助大家高效完成集群网络重建。
一、CNI 选型分析:为何选择 Calico 3.28.2 而非 Flannel 0.26.1?
在用户提供的两个选项中,Flannel 和 Calico 都是主流的 Kubernetes CNI,但二者在 "支持网络策略" 这一核心需求上存在关键差异,这也是选型的核心依据:
1. Flannel 0.26.1 的局限性
Flannel 是一款轻量级 CNI,主要通过 vxlan、host-gw 等模式实现 Pod 间网络互通,优势在于部署简单、资源占用低。但Flannel 默认不支持 Network Policy------ 即使通过额外插件扩展,也需复杂配置且功能不完善,无法满足 "实施网络策略" 的硬性要求,因此直接排除。
2. Calico 3.28.2 的优势
Calico 是一款功能全面的 CNI,不仅支持 Pod 间通信(通过 BGP、vxlan 等模式),还原生集成 Network Policy 功能,可实现精细化的网络访问控制(如限制 Pod 间通信、屏蔽外部访问等),完全满足需求。此外,Calico 3.28.2 作为稳定版本,兼容性强(支持 Kubernetes 1.24+)、性能优异,是生产环境的首选。
后续步骤将围绕 Calico 3.28.2 展开,重点讲解从清单文件安装的全流程及核心知识点。
二、核心知识点:理解 Calico 与 Network Policy 的关键概念
在安装前,需先掌握以下基础知识点,避免后续操作踩坑:
1. Calico 的核心组件
Calico 通过 "运算符(Operator)+ 自定义资源(CR)" 的模式部署,核心组件包括:
- Tigera Operator:负责管理 Calico 的生命周期(安装、升级、配置),是整个 Calico 集群的控制中心;
- Calico Node:运行在每个 Kubernetes 节点上的守护进程(calico-node 容器),负责节点间网络路由、Pod 网络配置;
- Felix:Calico Node 内置的核心组件,负责配置节点的网络规则(如 iptables)、实施 Network Policy;
- BIRD:可选组件,用于通过 BGP 协议实现节点间路由交换(若使用 vxlan 模式则无需依赖)。
2. Network Policy 的核心作用
Network Policy 是 Kubernetes 的原生资源,用于定义 Pod 的网络访问规则,核心能力包括:
- 入站规则(Ingress):限制哪些来源(如 Pod 标签、IP 段)可以访问目标 Pod;
- 出站规则(Egress):限制目标 Pod 可以访问哪些目的地;
- 选择器(Selector):通过 Pod 标签或命名空间标签,指定规则作用的 Pod 范围。
Calico 通过 Felix 组件监听 Network Policy 资源的变化,并将规则转化为节点的 iptables 规则,从而实现网络访问控制。
3. 清单文件(Manifest)安装的优势
用户要求 "从清单文件安装,不使用 Helm",清单文件(YAML 格式)的优势在于:
- 无依赖:无需安装 Helm 客户端,直接通过kubectl apply命令部署;
- 可定制:可直接编辑 YAML 文件,调整 Calico 的配置(如网络模式、IP 池);
- 易审计:清单文件可纳入版本控制(如 Git),便于追溯配置变更。
三、安装前准备:确认集群环境与依赖
在安装 Calico 前,需确保 Kubernetes 集群满足以下前提条件,避免部署失败:
1. 集群环境要求
- Kubernetes 版本:Calico 3.28.2 支持 Kubernetes 1.24 ~ 1.30(需确认集群版本在此范围内,可通过kubectl version查看);
- 节点操作系统:支持 Linux(如 CentOS 7+/Ubuntu 20.04+),且禁用了 Swap(Kubernetes 要求,可通过swapoff -a临时禁用,或修改/etc/fstab永久禁用);
- 网络支持:节点间网络互通(需开放 Calico 所需端口,如 BGP 的 179 端口、vxlan 的 4789 端口)。
2. 移除旧 CNI 残留(关键步骤)
若集群此前安装过其他 CNI(如 Flannel、Weave),需先清理残留资源,避免冲突:
# 1. 删除旧CNI的Pod和命名空间(以Flannel为例)
kubectl delete ns kube-flannel
kubectl delete pod -n kube-system -l app=flannel
# 2. 清理节点上的旧CNI配置(所有节点执行)
rm -rf /etc/cni/net.d/* # 删除CNI配置文件
systemctl restart kubelet # 重启kubelet,使配置生效
3. 工具准备
确保节点已安装kubectl客户端,且能正常连接 Kubernetes 集群(通过kubectl get nodes验证,需所有节点处于Ready状态)。
四、分步安装:从清单文件部署 Calico 3.28.2
Calico 3.28.2 的安装分为两步:先部署 Tigera Operator,再通过自定义资源(CustomResource)配置 Calico,全程使用清单文件。
1. 第一步:部署 Tigera Operator
Tigera Operator 是 Calico 的管理核心,需先通过官方清单文件安装:
# 下载并部署Tigera Operator清单(3.28.2版本)
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/tigera-operator.yaml
验证 Operator 部署结果
等待 1~2 分钟,查看tigera-operator命名空间下的 Pod 状态,需处于Running状态:
kubectl get pods -n tigera-operator
# 预期输出(NAME列可能不同,STATUS需为Running):
# NAME READY STATUS RESTARTS AGE
# tigera-operator-7f98d7c6b4-xyz 1/1 Running 0 1m
2. 第二步:部署 Calico 自定义资源(CR)
Tigera Operator 部署完成后,需创建Installation类型的自定义资源,定义 Calico 的安装配置(如网络模式、IP 池)。官方提供了默认清单文件,直接部署即可:
# 下载并部署Calico安装配置清单
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/custom-resources.yaml
关键配置说明(可按需修改)
若需调整 Calico 的网络配置(如 Pod 网段、网络模式),可先下载custom-resources.yaml文件编辑后再部署:
# 下载文件到本地
curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/custom-resources.yaml
打开文件后,重点关注以下配置:
- Pod 网段(cidr) :默认192.168.0.0/16,需确保与 Kubernetes 集群的--cluster-cidr(kube-apiserver 参数)一致(可通过kubectl -n kube-system get pod kube-apiserver-xxx -o yaml | grep cluster-cidr查看);
- 网络模式(vxlanEnabled):默认true(使用 vxlan 模式,无需节点间 BGP 配置),若需高性能可改为false并启用 BGP(需额外配置 BGP peer)。
修改完成后,再执行kubectl apply -f custom-resources.yaml部署。
3. 验证 Calico 部署结果
Calico 部署需 3~5 分钟(视集群节点数量而定),通过以下命令验证部署是否成功:
# 1. 查看calico-system命名空间下的Pod(所有Pod需Running)
kubectl get pods -n calico-system
# 预期输出(关键Pod:calico-node、calico-kube-controllers):
# NAME READY STATUS RESTARTS AGE
# calico-kube-controllers-5f7d6c7d89-xyz 1/1 Running 0 2m
# calico-node-abcde 1/1 Running 0 2m
# calico-node-fghij 1/1 Running 0 2m
# 2. 查看节点网络状态(所有节点需标注Calico信息)
kubectl get nodes -o wide
# 预期输出(INTERNAL-IP列后会显示Calico的Pod CIDR):
# NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
# node-1 Ready master 10h v1.27.0 192.168.1.1 <none> CentOS Linux 7 (Core) 3.10.0-1160.el7.x86_64 containerd://1.6.24
# node-2 Ready worker 10h v1.27.0 192.168.1.2 <none> CentOS Linux 7 (Core) 3.10.0-1160.el7.x86_64 containerd://1.6.24
若所有calico-node Pod 处于Running状态,且节点标注了 Calico 信息,说明 Calico 已成功部署。
五、功能验证:确保 Pod 通信与 Network Policy 生效
Calico 安装完成后,需验证两个核心功能:Pod 间通信、Network Policy 实施,确保满足需求。
1. 验证 Pod 间通信
创建两个测试 Pod(处于同一命名空间),测试它们之间能否互通:
# 1. 创建测试命名空间
kubectl create ns test-network
# 2. 创建两个测试Pod(nginx和busybox)
kubectl run nginx-pod -n test-network --image=nginx:alpine
kubectl run busybox-pod -n test-network --image=busybox:1.35 --command -- sh -c "sleep 3600"
# 3. 等待Pod就绪(STATUS为Running)
kubectl get pods -n test-network
# 4. 从busybox-pod ping nginx-pod(验证通信)
# 先获取nginx-pod的IP(假设为192.168.1.100)
NGINX_IP=$(kubectl get pod nginx-pod -n test-network -o jsonpath='{.status.podIP}')
# 从busybox-pod执行ping命令
kubectl exec -n test-network busybox-pod -- ping -c 3 $NGINX_IP
预期结果
若输出 "3 packets transmitted, 3 received",说明 Pod 间通信正常,Calico 的网络互通功能生效。
2. 验证 Network Policy 实施
创建一个 Network Policy,限制仅允许busybox-pod访问nginx-pod,验证网络策略是否生效:
第一步:创建 Network Policy 清单
创建nginx-policy.yaml文件,内容如下:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-busybox-to-nginx
namespace: test-network
spec:
podSelector:
matchLabels: # 规则作用于nginx-pod(需匹配Pod标签)
run: nginx-pod
policyTypes:
- Ingress # 仅配置入站规则
ingress:
- from:
- podSelector:
matchLabels: # 仅允许带有run: busybox-pod标签的Pod访问
run: busybox-pod
ports:
- protocol: TCP
port: 80 # 仅允许访问80端口(nginx默认端口)
第二步:部署 Network Policy
kubectl apply -f nginx-policy.yaml
第三步:验证策略生效
- 允许访问的场景:从busybox-pod访问nginx-pod的 80 端口,应成功:
kubectl exec -n test-network busybox-pod -- wget -q -O - $NGINX_IP:80
# 预期输出:nginx的默认欢迎页面HTML内容
- 拒绝访问的场景:创建一个新的test-pod,尝试访问nginx-pod,应失败:
# 创建新Pod
kubectl run test-pod -n test-network --image=busybox:1.35 --command -- sh -c "sleep 3600"
# 从test-pod访问nginx-pod
kubectl exec -n test-network test-pod -- wget -q -O - $NGINX_IP:80 --timeout=5
预期结果
test-pod访问时会提示 "wget: download timed out",说明 Network Policy 已生效,仅允许busybox-pod访问nginx-pod,满足 "实施网络策略" 的需求。
六、常见问题排查与解决方案
在安装或验证过程中,若遇到问题,可参考以下排查方向:
1. calico-node Pod 启动失败(状态为 CrashLoopBackOff)
可能原因
- 节点 Swap 未禁用(Calico 要求禁用 Swap);
- 节点网络端口被占用(如 vxlan 的 4789 端口);
- Pod 网段与集群--cluster-cidr不一致。
解决方案
# 1. 禁用Swap(所有节点执行)
swapoff -a
sed -i '/swap/s/^/#/' /etc/fstab # 永久禁用
# 2. 检查端口占用(以4789为例)
netstat -tulpn | grep 4789
# 若占用,停止占用进程或修改Calico的vxlan端口(需编辑custom-resources.yaml)
# 3. 确认Pod网段一致
APISERVER_CIDR=$(kubectl -n kube-system get pod kube-apiserver-$(hostname) -o yaml | grep cluster-cidr | awk -F': ' '{print $2}')
CALICO_CIDR=$(kubectl get installation.operator.tigera.io default -n calico-system -o jsonpath='{.spec.calicoNetwork.ipPools[0].cidr}')
if [ "$APISERVER_CIDR" != "$CALICO_CIDR" ]; then
# 修改Calico的Pod网段
kubectl patch installation.operator.tigera.io default -n calico-system --type merge -p '{"spec":{"calicoNetwork":{"ipPools":[{"cidr":"'$APISERVER_CIDR'","encapsulation":"VXLAN"}]}}}'
fi
# 4. 重启calico-node Pod
kubectl delete pods -n calico-system -l k8s-app=calico-node
2. Network Policy 不生效
可能原因
- Network Policy 的 Pod 标签匹配错误;
- Calico 的 Felix 组件未正常运行;
- 节点 iptables 规则未更新。
解决方案
# 1. 验证Pod标签匹配
kubectl get pods -n test-network --show-labels
# 确保nginx-pod的标签包含run: nginx-pod,busybox-pod包含run: busybox-pod
# 2. 检查Felix组件状态(在calico-node Pod内)
kubectl exec -n calico-system calico-node-abcde -- felixctl status
# 预期输出中"Healthy"为true
# 3. 重启Felix组件(重启calico-node Pod)
kubectl delete pods -n calico-system -l k8s-app=calico-node
七、总结
本文围绕 "安装支持网络策略的 CNI" 这一需求,从选型、知识点、安装、验证四个维度,详细讲解了 Calico 3.28.2 的部署全流程。通过本文的操作,可实现:
- Pod 间正常通信:Calico 通过 vxlan/BGP 模式构建集群网络;
- Network Policy 实施:原生支持精细化网络访问控制;
- 无依赖部署:仅通过清单文件,无需 Helm。
若后续需升级 Calico 或调整网络策略,可参考官方文档([Calico 3.28 Docs](#Calico 3.28 Docs)