当前位置：首页 > news >正文

K8s集群CNI升级：Calico3.28.2安装全攻略

news 2025/10/5 8:39:11

集群 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-flannelkubectl 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:alpinekubectl 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/v1kind: NetworkPolicymetadata:name: allow-busybox-to-nginxnamespace: test-networkspec:podSelector:matchLabels: # 规则作用于nginx-pod（需匹配Pod标签）run: nginx-podpolicyTypes:- Ingress # 仅配置入站规则ingress:- from:- podSelector:matchLabels: # 仅允许带有run: busybox-pod标签的Pod访问run: busybox-podports:- protocol: TCPport: 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，应失败：

# 创建新Podkubectl run test-pod -n test-network --image=busybox:1.35 --command -- sh -c "sleep 3600"# 从test-pod访问nginx-podkubectl 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 -ased -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 Podkubectl 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