Cilium 在 RKE1 / RKE2 集群上的安装与验证指南（Rancher Kubernetes Engine）

Cilium 在 RKE1 / RKE2 集群上的安装与验证指南（Rancher Kubernetes Engine）

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium

本指南以 Cilium 官方文档 Documentation/installation/k8s-install-rke.rst 为核心，完整讲解如何在standalone（独立、非 Rancher 管理面托管）的 RKE1 与 RKE2 集群上安装 Cilium。你将掌握：RKE1 集群如何关闭默认网络插件（canal/flannel）、RKE2 两种接入方式的取舍（内置 rke2-cilium 与官方 Helm 二选一）、通过 Helm v3 或 Cilium CLI 完成部署，以及使用cilium status、cilium connectivity test或kubectl验证集群网络连通性的完整流程。

RKE（Rancher Kubernetes Engine）是 SUSE 出品的 CNCF 认证 Kubernetes 发行版，内置安全与合规能力。它通过去除大部分宿主机依赖，显著降低了 Kubernetes 的安装复杂度，并为部署、升级与回滚提供了稳定路径。当你的 RKE 集群由 Rancher Management Console/UI 托管时，应改走 Rancher 托管集群安装指南；本文只覆盖 standalone 场景。

一、安装前置：确认集群形态

在动手之前，先明确你的 RKE 集群属于哪种形态，对应的安装路径完全不同：

此分类在 Documentation/installation/requirements-rke.rst 中同样得到印证：只有 standalone 的 RKE1/RKE2 集群才走本文介绍的安装流程。

二、安装 RKE1 集群：将网络插件切换为 none

RKE1 的安装步骤以 RKE1 官方安装指南 为准。关键一步是：生成config.yaml后，必须把默认网络插件修改为none，否则 RKE1 自带的 canal（Canal = Calico + Flannel）网络插件会先于 Cilium 抢占集群网络，导致 Cilium 无法接管 CNI。

将config.yaml中的默认配置：

network: options: flannel_backend_type: "vxlan" plugin: "canal"

修改为：

network: plugin: none

修改后，rke up创建的集群将不部署任何 CNI 插件，Node 会处于NotReady状态，这正是 Cilium 将要填补的空位。这里的核心原理是：Kubernetes 每个节点同一时间只能运行一套 CNI 实现，Cilium 作为 eBPF 驱动的 CNI 必须独占node_config.h中的网络配置（见 bpf/node_config.h），因此先禁用 RKE 内置插件是安装 Cilium 的硬性前置条件。

三、安装 RKE2 集群：两种 CNI 接入方式

RKE2 的安装步骤以 RKE2 官方快速入门 为准。RKE2 提供了两种让 Cilium 接管网络的方案：

方式一：使用 RKE2 内置的 Cilium（推荐）

RKE2 发行版自身集成了 Cilium 作为可选 CNI，安装时直接选择 RKE2-integrated Cilium 即可，无需额外安装。此方式对大多数用户最为推荐，因为它与 RKE2 生命周期天然协同，升级路径统一。

方式二：cni: none+ 官方 Cilium Helm chart（进阶）

在 RKE2 服务端配置中显式声明cni: none（详见 RKE2 服务端配置参考），然后通过 Helm 安装 Cilium。

为什么 Cilium 高级用户倾向选择方式二？关键在于 Rancher 维护的rke2-ciliumHelm chart（基于 rancher/rke2-charts 仓库）有独立的发布周期，其 Cilium 版本与上游可能存在时间差。而方式二直接使用官方 Cilium Helm chart，由你自行掌控版本，从 Cilium 视角获得最大的灵活性，例如：更早用上新特性、按需定制 chart values、独立于 RKE2 节奏做升级。代价是需要自己管理 Cilium 的升级与回滚。

四、部署 Cilium：Helm v3 与 Cilium CLI 两种路径

集群就绪且 CNI 位置留空后，即可部署 Cilium。官方提供两种等价方式，任选其一。

方式 A：Helm v3

使用 Helm 直接安装：

helm install cilium cilium/cilium --namespace kube-system

实际安装时建议显式指定版本并携带自定义 values，例如：

helm repo add cilium https://helm.cilium.io/ helm install cilium cilium/cilium \ --namespace kube-system \ --version 1.16.0 \ --set ipam.mode=kubernetes

说明：kube-system是 Cilium 官方默认的部署命名空间，你也可通过--namespace $CILIUM_NAMESPACE自定义。

方式 B：Cilium CLI

Cilium CLI 不仅能安装 Cilium，还能检查安装状态、启用/禁用各类特性（如 ClusterMesh、Hubble）。先按系统架构安装最新版 CLI：

Linux（x86_64 / aarch64 自动识别）：

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCH=amd64 if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum} sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

macOS：

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCH=amd64 if [ "$(uname -m)" = "arm64" ]; then CLI_ARCH=arm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum} shasum -a 256 -c cilium-darwin-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-darwin-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum}

上述下载与校验脚本的完整出处见 Documentation/installation/cli-download.rst。安装完 CLI 后执行：

cilium install --version 1.16.0

cilium install底层会调用cilium-cli/install包（见 cilium-cli/install），将官方 Helm chart 渲染并应用到集群。从源码结构看，该命令会读取 kubeconfig、校验集群 CNI 占用情况，再以 Helm 方式完成部署，因此它的行为与方式 A 完全等价。

五、验证安装：观察组件与状态

5.1 用 kubectl 观察组件滚动

安装后 Cilium 由两个核心组件组成：DaemonSetcilium（每节点一个，负责数据面）与 Deploymentcilium-operator（负责控制面逻辑，如 IP 分配）。用 watch 观察它们就绪：

$ kubectl -n kube-system get pods --watch NAME READY STATUS RESTARTS AGE cilium-operator-cb4578bc5-q52qk 0/1 Pending 0 8s cilium-s8w5m 0/1 PodInitializing 0 7s coredns-86c58d9df4-4g7dd 0/1 ContainerCreating 0 8m57s coredns-86c58d9df4-4l6b2 0/1 ContainerCreating 0 8m57s

全部组件拉起通常需要几分钟，最终状态应为：

cilium-operator-cb4578bc5-q52qk 1/1 Running 0 4m13s cilium-s8w5m 1/1 Running 0 4m12s coredns-86c58d9df4-4g7dd 1/1 Running 0 13m coredns-86c58d9df4-4l6b2 1/1 Running 0 13m

注意：Cilium 接管 CNI 后，之前因无网络插件而处于ContainerCreating的coredns也会随之恢复 Running，这正是网络已打通的标志（参见 Documentation/installation/kubectl-status.rst）。

5.2 用 Cilium CLI 查看整体状态

$ cilium status --wait /¯¯\ /¯¯\__/¯¯\ Cilium: OK \__/¯¯\__/ Operator: OK /¯¯\__/¯¯\ Hubble: disabled \__/¯¯\__/ ClusterMesh: disabled \__/ DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2 Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2 Containers: cilium-operator Running: 2 cilium Running: 2 Image versions cilium quay.io/cilium/cilium:v1.9.5: 2 cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2

输出说明（示例版本号 v1.9.5 会随你安装的版本而变化）：Cilium: OK表示数据面健康，Operator: OK表示控制面健康，Hubble与ClusterMesh默认disabled，可按需通过 CLI 启用。命令来自 Documentation/installation/cli-status.rst，其实现逻辑可在 cilium-cli/status 中找到。

六、连通性验证：两条测试路线

路线一：cilium connectivity test（推荐）

运行内置的端到端连通性测试套件：

$ cilium connectivity test ℹ️ Monitor aggregation detected, will skip some flow validation steps ✨ [k8s-cluster] Creating namespace for connectivity check... (...) --------------------------------------------------------------------------------------------------------------------- 📋 Test Report --------------------------------------------------------------------------------------------------------------------- ✅ 69/69 tests successful (0 warnings)

该命令来自 Documentation/installation/cli-connectivity-test.rst，底层实现在 cilium-cli/connectivity（仓库中该目录包含 171 个 Go 文件与 109 个 YAML 场景）。它会自动创建临时命名空间、部署多组测试 Pod，覆盖 Pod 到 Pod、Pod 到 Service、多节点、FQDN、网络策略等路径，最后输出测试报告。

故障提示：如果测试 Pod 因 "too many open files" 无法启动，可在宿主机上调大inotify资源限制后重试。

路线二：kubectl 手动部署 connectivity-check

不想依赖 CLI 时，可手动部署官方连通性检查清单。先创建独立命名空间：

kubectl create ns cilium-test

再应用清单：

kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml

该清单（examples/kubernetes/connectivity-check/connectivity-check.yaml）会部署一系列 Deployment，它们通过有无 Service 负载均衡、多种网络策略组合等不同路径互相连通。Pod 名称即连通性变体标识，READY、STATUS直接反映测试成败：

$ kubectl get pods -n cilium-test NAME READY STATUS RESTARTS AGE echo-a-76c5d9bd76-q8d99 1/1 Running 0 66s echo-b-795c4b4f76-9wrrx 1/1 Running 0 66s echo-b-host-6b7fc94b7c-xtsff 1/1 Running 0 66s host-to-b-multi-node-clusterip-85476cd779-bpg4b 1/1 Running 0 66s host-to-b-multi-node-headless-dc6c44cb5-8jdz8 1/1 Running 0 65s pod-to-a-79546bc469-rl2qq 1/1 Running 0 66s pod-to-a-allowed-cnp-58b7f7fb8f-lkq7p 1/1 Running 0 66s pod-to-a-denied-cnp-6967cb6f7f-7h9fn 1/1 Running 0 66s pod-to-b-intra-node-nodeport-9b487cf89-6ptrt 1/1 Running 0 65s pod-to-b-multi-node-clusterip-7db5dfdcf7-jkjpw 1/1 Running 0 66s pod-to-b-multi-node-headless-7d44b85d69-mtscc 1/1 Running 0 66s pod-to-b-multi-node-nodeport-7ffc76db7c-rrw82 1/1 Running 0 65s pod-to-external-1111-d56f47579-d79dz 1/1 Running 0 66s pod-to-external-fqdn-allow-google-cnp-78986f4bcf-btjn7 1/1 Running 0 66s

单节点集群注意：host-to-b-multi-node-*与pod-to-b-multi-node-*这类检查多节点功能的 Pod 在单节点集群上会保持Pending，属预期行为——它们至少需要 2 个节点才能被调度。

测试完毕后清理命名空间：

kubectl delete ns cilium-test

至此，你已经拥有了一个完全可用的、由 Cilium 提供网络能力的 Kubernetes 集群。

七、后续进阶方向

安装验证完成后，官方文档 Documentation/installation/next-steps.rst 建议按需继续深入以下能力：

• Hubble：可观测性层，包含 Hubble 安装（cilium hubble enable）、Hubble CLI 与 Hubble UI，用于服务依赖图、流日志与指标观测；
• HTTP 感知策略（L7）：通过gs_http指南体验基于 HTTP 方法的七层网络策略；
• ClusterMesh：跨集群互联，让多个集群共享服务发现与网络安全策略。

以上参考章节的完整入口可在 Documentation/installation/k8s-toc.rst 中检索。

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium