Cilium 在 Rancher 托管 RKE2 集群上的安装指南基于官方 Helm Chart 的带外Out-of-Band部署【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文基于 Cilium 官方文档 k8s-install-rancher-existing-nodes.rst讲解如何在Rancher 管理控制台托管的 RKE2 下游集群上不使用 Rancher 内置的rke2-ciliumHelm Chart而是通过 RKE2 内置 Helm Operator 以Additional Manifests方式带外安装官方 Cilium Helm Chart。阅读本文后你将掌握在 Rancher UI 中创建不带 CNI 的 Custom Cluster、注入 Cilium 的ClusterRepo与HelmChart清单、配置k8sServiceHost/k8sServicePort/kubeProxyReplacement等核心参数、禁用内置 kube-proxy 的完整流程以及如何在 Rancher UI 中验证和升级 Cilium。适用范围本指南仅面向Rancher 托管的非 standaloneRKE2 集群。若你使用 Rancher 管理控制台/UI 之外的独立 RKE 集群请参考 k8s-install-rke.rstRancher 对 Cilium 有官方支持对大多数用户而言Rancher 内置的rke2-cilium方案即推荐路径。本指南针对希望脱离该 Chart 独立发布周期、直接掌控官方 Cilium Helm Chart 的高级用户。背景为什么要在 Rancher 集群上带外安装 CiliumRancher 为 Cilium 提供官方支持并在其托管的 RKE2 下游集群中默认使用定制的rke2-ciliumHelm Chart。该 Chart 拥有独立的发布周期其版本更新节奏与上游 Cilium 不完全同步。对于追求最新特性、希望直接使用官方 Cilium Helm Chart 的高级用户power-user可以在 Rancher 托管的 RKE2 下游集群之上叠加一套带外out-of-bandCilium 安装。这种做法的核心价值在于由用户直接控制 Cilium 版本与全部 Helm values不依赖 RKE2 打包的 CNI Chart 的发布节奏仍然保留 Rancher 对集群生命周期节点增删、扩缩容的完整管理能力安装完成后Cilium 的 Helm Release 会纳入 Rancher 的应用管理可在 UI 中直接升级。注意本指南展示的是 Rancher 托管的Custom Clusters安装方法同样适用于通过 VMware vSphere 等 Provider 创建的集群。前置条件开始之前请确认以下条件已满足前置条件说明可用的 Rancher 2.x 实例需要功能完整的 Rancher 2.x 管理控制台至少一台空置的 Linux VM作为下游 Custom Cluster 的初始Control Plane节点DNS 记录或 L4 负载均衡指向下游 Custom Cluster Control Plane 节点的 Kubernetes API供工作节点发现 API Server第一步在 Rancher UI 中创建不带 CNI 的新集群进入集群创建页在 Rancher UI 中导航到Cluster Management集群管理页面点击右上角的Create按钮创建新集群参考截图 rancher_add_cluster.png。选择 Custom 集群类型在集群创建页面中选择创建Custom自定义集群参考截图 rancher_existing_nodes.png。Custom 集群允许你将裸机或任意云环境中的现有节点手动加入这正是现有节点安装方式的入口。配置 CNI 为 none当Create Custom页面打开后为集群提供一个名称在同一个Basics基础设置区域中展开Container Network容器网络下拉列表选择none参考截图 rancher_select_cni.png继续检查其余配置选项按你的实际环境配置相关项。选择none意味着 Rancher 不会为集群预装任何 CNI 插件后续由我们通过 Helm Operator 注入的 Cilium 来承担网络职责。第二步通过 Additional Manifests 注入 Cilium 安装清单RKE2 自带内置的Helm Operator它会在集群引导bootstrap阶段处理Additional Manifests中定义的HelmChart资源。我们利用这一机制安装 Cilium。在集群创建页的Additional Manifests附加清单区域粘贴以下两个 YAML。定义 Cilium Helm Chart 仓库首先定义一个ClusterRepo资源将 Cilium 官方 Helm 仓库注册到集群的 Rancher Catalog 中apiVersion: catalog.cattle.io/v1 kind: ClusterRepo metadata: name: cilium spec: url: https://helm.cilium.io定义 Cilium HelmChart 安装清单接着定义HelmChart资源指定从上述仓库安装ciliumChartapiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: cilium namespace: kube-system spec: targetNamespace: kube-system createNamespace: false version: v1.18.0 chart: cilium repo: https://helm.cilium.io bootstrap: true valuesContent: |- # paste your Cilium values here: k8sServiceHost: 127.0.0.1 k8sServicePort: 6443 kubeProxyReplacement: true各字段说明字段取值作用metadata.namespacekube-systemHelmChart 资源本身所在命名空间spec.targetNamespacekube-systemCilium 实际安装到的目标命名空间spec.createNamespacefalsekube-system已存在无需创建spec.versionv1.18.0指定 Cilium Chart 版本请替换为你需要的版本spec.chartciliumChart 名称spec.repohttps://helm.cilium.ioCilium 官方 Helm 仓库spec.bootstraptrue关键标志让 RKE2 Helm Operator 在集群引导早期阶段就安装 Cilium确保 CNI 在节点就绪前就位spec.valuesContent见下传递给 Cilium 的 Helm values参考截图rancher_additional_manifests.png理解k8sServiceHost与k8sServicePort的含义valuesContent中的三个参数是整个 RKE2 场景下能否正常工作的关键k8sServiceHost: 127.0.0.1告知 Cilium Agent 通过回环地址访问 Kubernetes API。在 Control Plane 节点上kube-apiserver进程直接监听本地 6443 端口在工作节点上rke2进程会在本地 127.0.0.1:6443 上监听并将请求代理到 Control Plane 上的 API Server。k8sServicePort: 6443Kubernetes API Server 的服务端口RKE2 默认端口。kubeProxyReplacement: true启用 Cilium 的 eBPF kube-proxy 替代能力详见下文。为什么必须设置k8sServiceHost127.0.0.1在 RKE2 托管的集群中节点上没有独立的kube-proxy为 Kubernetes Servicekubernetes.default即 API Server ClusterIP提供负载均衡。因此 Cilium Agent 无法通过 ClusterIP 访问 API Server必须显式告知其 API 端点地址。验证 API 监听Control Plane 节点 vs 工作节点文档给出了两个可复现的验证命令确认 API 端点的监听位置。在Control Plane 节点上kube-apiserver进程直接监听 6443$ sudo ss -tulpn | grep 6443 tcp LISTEN 0 4096 *:6443 *:* users:((kube-apiserver,pid124481,fd3))在Worker 节点上监听 6443 的是rke2进程它将请求代理到 Control Plane 上的 Kubernetes API Server$ sudo ss -tulpn | grep 6443 tcp LISTEN 0 4096 127.0.0.1:6443 0.0.0.0:* users:((rke2,pid113574,fd8))从源码与官方 Helm 参数文档helm-values.rst可知k8sServiceHost与k8sServicePort是 Cilium Agent 在无 kube-proxy 环境下连接 API Server 的标准配置项。Helm 还提供k8sServiceHostRef通过 ConfigMap 动态配置 API 端点与k8sServiceHost互斥以及k8sServiceHostauto时从kube-public/cluster-infoConfigMap 自动发现的扩展能力。而在 RKE2 托管集群场景中固定使用127.0.0.1:6443即可覆盖所有节点类型。第三步编辑集群 YAML 并禁用内置 kube-proxy可选进入 Edit as YAML粘贴完 Additional Manifests 后点击页面底部的Edit as YAML复选框集群配置会在窗口内以编辑器形式打开参考截图 rancher_config_yaml.png。在Cluster自定义资源provisioning.cattle.io/v1中检查rkeConfig部分确认其中包含你在 Additional Manifests 中添加的清单内容。可选禁用内置 kube-proxy如果你希望禁用 RKE2 默认的 kube-proxy并且你的 Cilium 配置启用了 Kube-Proxy Replacement即上文kubeProxyReplacement: true则在spec.rkeConfig.machineGlobalConfig部分设置spec: rkeConfig: machineGlobalConfig: disable-kube-proxy: true关于 Kube-Proxy Replacement 的补充说明Cilium 的 kube-proxy 替代能力依赖 socket-LBsocket 层负载均衡特性。在无 kube-proxy 的集群中必须通过k8sServiceHost/k8sServicePort显式告知 Cilium Agent API Server 地址因为在 kubeadm 等场景下 API Server Service 本身没有 kube-proxy 来提供服务详见 kubeproxy-free.rst。RKE2 场景下的127.0.0.1:6443即是对这一要求的适配。创建集群确认配置无误后点击CreateRancher 开始创建集群。集群会保持在Updating状态直到你加入节点参考截图 rancher_cluster_state_provisioning.png。第四步注册节点并等待集群就绪获取 Registration 命令点击集群在Registration注册选项卡中可以看到生成的Registration command需要在下游集群的各个节点上执行参考截图 rancher_registration_command.png。注意节点角色选择Rancher 默认会部署全部三种角色etcd、Control Plane、Worker。对于多节点集群这通常不是你想要的结果——请按拓扑规划为每个节点明确勾选正确的角色。观察节点与集群状态加入至少一个节点后几秒钟内即可在Machines选项卡中看到新节点。此时 RKE2 内置的 Helm Operator 会创建一个 Kubernetes Job在集群引导过程中安装 Cilium CNI。几分钟后节点变为Ready状态可用kubectl验证kubectl get nodes -A NAME STATUS ROLES AGE VERSION ip-10-1-1-167 Ready control-plane,etcd,master,worker 41m v1.32.6rke2r1 ip-10-1-1-231 Ready control-plane,etcd,master,worker 41m v1.32.6rke2r1 ip-10-1-1-50 Ready control-plane,etcd,master,worker 45m v1.32.6rke2r1返回 Rancher UI集群应变为健康的Active状态参考截图 rancher_cluster_created.png。至此安装完成。此后你可以像使用 Rancher 默认 CNI 安装方式一样管理该集群扩容/缩容、添加/移除节点等均不受影响。第五步验证 Cilium 安装与后续升级在 Rancher UI 中检查 Cilium 应用安装完成后Cilium 的 Helm 仓库与 Release 会由 Rancher 跟踪管理你可以通过 Rancher UI 管理 Cilium 生命周期。验证方法导航到your-cluster→Apps→Installed Apps已安装应用。从顶部下拉菜单选择All Namespaces或Project: System - kube-system即可看到 Cilium 应用参考截图 rancher_cluster_cilium_app.png。Cilium Helm 仓库会显示在 Rancher 的仓库列表中因为我们已在 Additional Manifests 中通过ClusterRepo注册参考截图 rancher_cilium_repo.png。通过 Rancher UI 升级 Cilium当有新的 Cilium 版本发布时该应用条目上会出现升级提示参考截图 rancher_cluster_cilium_app_upgrade.png。点击后可以选择目标版本并直接在 Rancher UI 中完成升级参考截图 rancher_cluster_cilium_app_upgrade_versions.png。这正是带外安装带来的运维收益升级路径完全由官方 Helm Chart 驱动同时保留了 Rancher UI 的图形化操作体验。常见问题与注意事项为什么不直接使用 Rancher 内置的 Cilium 支持对大多数用户Rancher 官方内置支持是推荐路径。只有当你需要紧跟上游 Cilium 版本、使用定制 Helm values 时才采用本文方案。bootstrap: true的含义它要求 RKE2 在集群引导的最早期阶段安装 Cilium确保节点上的 Pod 网络在业务工作负载调度前就已可用。若省略该字段CNI 可能在节点就绪后才安装导致调度到节点上的 Pod 无法获得网络。版本选择spec.version需替换为实际可用的 Cilium Chart 版本。本文示例基于文档撰写时的v1.18.0请以官方 Helm 仓库的可用版本为准。升级 Cilium 版本建议在升级前查阅 upgrade.rst 中的升级注意事项该文档同时引用了 kube-proxy 替代相关说明。节点角色规划Rancher 默认三合一角色etcd Control Plane Worker适合单节点测试环境生产多节点集群务必按职责拆分。总结本指南完整覆盖了在 Rancher 托管 RKE2 集群上带外安装 Cilium 的五个核心环节创建 CNI 为none的 Custom 集群通过 Additional Manifests 注入ClusterRepo与HelmChart清单配置k8sServiceHost127.0.0.1、k8sServicePort6443、kubeProxyReplacementtrue通过 Edit as YAML 检查rkeConfig并按需设置disable-kube-proxy: true使用 Registration 命令加入节点等待集群进入 Active 状态在 Rancher UI 的 Installed Apps 中验证并通过 UI 升级 Cilium。这套方案在保留 Rancher 集群管理能力的同时将 CNI 的控制权完整交还给 Cilium 用户实现了Rancher 管集群、Cilium 管网络的清晰分工。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cilium 在 Rancher 托管 RKE2 集群上的安装指南：基于官方 Helm Chart 的带外（Out-of-Band）部署
Cilium 在 Rancher 托管 RKE2 集群上的安装指南基于官方 Helm Chart 的带外Out-of-Band部署【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文基于 Cilium 官方文档 k8s-install-rancher-existing-nodes.rst讲解如何在Rancher 管理控制台托管的 RKE2 下游集群上不使用 Rancher 内置的rke2-ciliumHelm Chart而是通过 RKE2 内置 Helm Operator 以Additional Manifests方式带外安装官方 Cilium Helm Chart。阅读本文后你将掌握在 Rancher UI 中创建不带 CNI 的 Custom Cluster、注入 Cilium 的ClusterRepo与HelmChart清单、配置k8sServiceHost/k8sServicePort/kubeProxyReplacement等核心参数、禁用内置 kube-proxy 的完整流程以及如何在 Rancher UI 中验证和升级 Cilium。适用范围本指南仅面向Rancher 托管的非 standaloneRKE2 集群。若你使用 Rancher 管理控制台/UI 之外的独立 RKE 集群请参考 k8s-install-rke.rstRancher 对 Cilium 有官方支持对大多数用户而言Rancher 内置的rke2-cilium方案即推荐路径。本指南针对希望脱离该 Chart 独立发布周期、直接掌控官方 Cilium Helm Chart 的高级用户。背景为什么要在 Rancher 集群上带外安装 CiliumRancher 为 Cilium 提供官方支持并在其托管的 RKE2 下游集群中默认使用定制的rke2-ciliumHelm Chart。该 Chart 拥有独立的发布周期其版本更新节奏与上游 Cilium 不完全同步。对于追求最新特性、希望直接使用官方 Cilium Helm Chart 的高级用户power-user可以在 Rancher 托管的 RKE2 下游集群之上叠加一套带外out-of-bandCilium 安装。这种做法的核心价值在于由用户直接控制 Cilium 版本与全部 Helm values不依赖 RKE2 打包的 CNI Chart 的发布节奏仍然保留 Rancher 对集群生命周期节点增删、扩缩容的完整管理能力安装完成后Cilium 的 Helm Release 会纳入 Rancher 的应用管理可在 UI 中直接升级。注意本指南展示的是 Rancher 托管的Custom Clusters安装方法同样适用于通过 VMware vSphere 等 Provider 创建的集群。前置条件开始之前请确认以下条件已满足前置条件说明可用的 Rancher 2.x 实例需要功能完整的 Rancher 2.x 管理控制台至少一台空置的 Linux VM作为下游 Custom Cluster 的初始Control Plane节点DNS 记录或 L4 负载均衡指向下游 Custom Cluster Control Plane 节点的 Kubernetes API供工作节点发现 API Server第一步在 Rancher UI 中创建不带 CNI 的新集群进入集群创建页在 Rancher UI 中导航到Cluster Management集群管理页面点击右上角的Create按钮创建新集群参考截图 rancher_add_cluster.png。选择 Custom 集群类型在集群创建页面中选择创建Custom自定义集群参考截图 rancher_existing_nodes.png。Custom 集群允许你将裸机或任意云环境中的现有节点手动加入这正是现有节点安装方式的入口。配置 CNI 为 none当Create Custom页面打开后为集群提供一个名称在同一个Basics基础设置区域中展开Container Network容器网络下拉列表选择none参考截图 rancher_select_cni.png继续检查其余配置选项按你的实际环境配置相关项。选择none意味着 Rancher 不会为集群预装任何 CNI 插件后续由我们通过 Helm Operator 注入的 Cilium 来承担网络职责。第二步通过 Additional Manifests 注入 Cilium 安装清单RKE2 自带内置的Helm Operator它会在集群引导bootstrap阶段处理Additional Manifests中定义的HelmChart资源。我们利用这一机制安装 Cilium。在集群创建页的Additional Manifests附加清单区域粘贴以下两个 YAML。定义 Cilium Helm Chart 仓库首先定义一个ClusterRepo资源将 Cilium 官方 Helm 仓库注册到集群的 Rancher Catalog 中apiVersion: catalog.cattle.io/v1 kind: ClusterRepo metadata: name: cilium spec: url: https://helm.cilium.io定义 Cilium HelmChart 安装清单接着定义HelmChart资源指定从上述仓库安装ciliumChartapiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: cilium namespace: kube-system spec: targetNamespace: kube-system createNamespace: false version: v1.18.0 chart: cilium repo: https://helm.cilium.io bootstrap: true valuesContent: |- # paste your Cilium values here: k8sServiceHost: 127.0.0.1 k8sServicePort: 6443 kubeProxyReplacement: true各字段说明字段取值作用metadata.namespacekube-systemHelmChart 资源本身所在命名空间spec.targetNamespacekube-systemCilium 实际安装到的目标命名空间spec.createNamespacefalsekube-system已存在无需创建spec.versionv1.18.0指定 Cilium Chart 版本请替换为你需要的版本spec.chartciliumChart 名称spec.repohttps://helm.cilium.ioCilium 官方 Helm 仓库spec.bootstraptrue关键标志让 RKE2 Helm Operator 在集群引导早期阶段就安装 Cilium确保 CNI 在节点就绪前就位spec.valuesContent见下传递给 Cilium 的 Helm values参考截图rancher_additional_manifests.png理解k8sServiceHost与k8sServicePort的含义valuesContent中的三个参数是整个 RKE2 场景下能否正常工作的关键k8sServiceHost: 127.0.0.1告知 Cilium Agent 通过回环地址访问 Kubernetes API。在 Control Plane 节点上kube-apiserver进程直接监听本地 6443 端口在工作节点上rke2进程会在本地 127.0.0.1:6443 上监听并将请求代理到 Control Plane 上的 API Server。k8sServicePort: 6443Kubernetes API Server 的服务端口RKE2 默认端口。kubeProxyReplacement: true启用 Cilium 的 eBPF kube-proxy 替代能力详见下文。为什么必须设置k8sServiceHost127.0.0.1在 RKE2 托管的集群中节点上没有独立的kube-proxy为 Kubernetes Servicekubernetes.default即 API Server ClusterIP提供负载均衡。因此 Cilium Agent 无法通过 ClusterIP 访问 API Server必须显式告知其 API 端点地址。验证 API 监听Control Plane 节点 vs 工作节点文档给出了两个可复现的验证命令确认 API 端点的监听位置。在Control Plane 节点上kube-apiserver进程直接监听 6443$ sudo ss -tulpn | grep 6443 tcp LISTEN 0 4096 *:6443 *:* users:((kube-apiserver,pid124481,fd3))在Worker 节点上监听 6443 的是rke2进程它将请求代理到 Control Plane 上的 Kubernetes API Server$ sudo ss -tulpn | grep 6443 tcp LISTEN 0 4096 127.0.0.1:6443 0.0.0.0:* users:((rke2,pid113574,fd8))从源码与官方 Helm 参数文档helm-values.rst可知k8sServiceHost与k8sServicePort是 Cilium Agent 在无 kube-proxy 环境下连接 API Server 的标准配置项。Helm 还提供k8sServiceHostRef通过 ConfigMap 动态配置 API 端点与k8sServiceHost互斥以及k8sServiceHostauto时从kube-public/cluster-infoConfigMap 自动发现的扩展能力。而在 RKE2 托管集群场景中固定使用127.0.0.1:6443即可覆盖所有节点类型。第三步编辑集群 YAML 并禁用内置 kube-proxy可选进入 Edit as YAML粘贴完 Additional Manifests 后点击页面底部的Edit as YAML复选框集群配置会在窗口内以编辑器形式打开参考截图 rancher_config_yaml.png。在Cluster自定义资源provisioning.cattle.io/v1中检查rkeConfig部分确认其中包含你在 Additional Manifests 中添加的清单内容。可选禁用内置 kube-proxy如果你希望禁用 RKE2 默认的 kube-proxy并且你的 Cilium 配置启用了 Kube-Proxy Replacement即上文kubeProxyReplacement: true则在spec.rkeConfig.machineGlobalConfig部分设置spec: rkeConfig: machineGlobalConfig: disable-kube-proxy: true关于 Kube-Proxy Replacement 的补充说明Cilium 的 kube-proxy 替代能力依赖 socket-LBsocket 层负载均衡特性。在无 kube-proxy 的集群中必须通过k8sServiceHost/k8sServicePort显式告知 Cilium Agent API Server 地址因为在 kubeadm 等场景下 API Server Service 本身没有 kube-proxy 来提供服务详见 kubeproxy-free.rst。RKE2 场景下的127.0.0.1:6443即是对这一要求的适配。创建集群确认配置无误后点击CreateRancher 开始创建集群。集群会保持在Updating状态直到你加入节点参考截图 rancher_cluster_state_provisioning.png。第四步注册节点并等待集群就绪获取 Registration 命令点击集群在Registration注册选项卡中可以看到生成的Registration command需要在下游集群的各个节点上执行参考截图 rancher_registration_command.png。注意节点角色选择Rancher 默认会部署全部三种角色etcd、Control Plane、Worker。对于多节点集群这通常不是你想要的结果——请按拓扑规划为每个节点明确勾选正确的角色。观察节点与集群状态加入至少一个节点后几秒钟内即可在Machines选项卡中看到新节点。此时 RKE2 内置的 Helm Operator 会创建一个 Kubernetes Job在集群引导过程中安装 Cilium CNI。几分钟后节点变为Ready状态可用kubectl验证kubectl get nodes -A NAME STATUS ROLES AGE VERSION ip-10-1-1-167 Ready control-plane,etcd,master,worker 41m v1.32.6rke2r1 ip-10-1-1-231 Ready control-plane,etcd,master,worker 41m v1.32.6rke2r1 ip-10-1-1-50 Ready control-plane,etcd,master,worker 45m v1.32.6rke2r1返回 Rancher UI集群应变为健康的Active状态参考截图 rancher_cluster_created.png。至此安装完成。此后你可以像使用 Rancher 默认 CNI 安装方式一样管理该集群扩容/缩容、添加/移除节点等均不受影响。第五步验证 Cilium 安装与后续升级在 Rancher UI 中检查 Cilium 应用安装完成后Cilium 的 Helm 仓库与 Release 会由 Rancher 跟踪管理你可以通过 Rancher UI 管理 Cilium 生命周期。验证方法导航到your-cluster→Apps→Installed Apps已安装应用。从顶部下拉菜单选择All Namespaces或Project: System - kube-system即可看到 Cilium 应用参考截图 rancher_cluster_cilium_app.png。Cilium Helm 仓库会显示在 Rancher 的仓库列表中因为我们已在 Additional Manifests 中通过ClusterRepo注册参考截图 rancher_cilium_repo.png。通过 Rancher UI 升级 Cilium当有新的 Cilium 版本发布时该应用条目上会出现升级提示参考截图 rancher_cluster_cilium_app_upgrade.png。点击后可以选择目标版本并直接在 Rancher UI 中完成升级参考截图 rancher_cluster_cilium_app_upgrade_versions.png。这正是带外安装带来的运维收益升级路径完全由官方 Helm Chart 驱动同时保留了 Rancher UI 的图形化操作体验。常见问题与注意事项为什么不直接使用 Rancher 内置的 Cilium 支持对大多数用户Rancher 官方内置支持是推荐路径。只有当你需要紧跟上游 Cilium 版本、使用定制 Helm values 时才采用本文方案。bootstrap: true的含义它要求 RKE2 在集群引导的最早期阶段安装 Cilium确保节点上的 Pod 网络在业务工作负载调度前就已可用。若省略该字段CNI 可能在节点就绪后才安装导致调度到节点上的 Pod 无法获得网络。版本选择spec.version需替换为实际可用的 Cilium Chart 版本。本文示例基于文档撰写时的v1.18.0请以官方 Helm 仓库的可用版本为准。升级 Cilium 版本建议在升级前查阅 upgrade.rst 中的升级注意事项该文档同时引用了 kube-proxy 替代相关说明。节点角色规划Rancher 默认三合一角色etcd Control Plane Worker适合单节点测试环境生产多节点集群务必按职责拆分。总结本指南完整覆盖了在 Rancher 托管 RKE2 集群上带外安装 Cilium 的五个核心环节创建 CNI 为none的 Custom 集群通过 Additional Manifests 注入ClusterRepo与HelmChart清单配置k8sServiceHost127.0.0.1、k8sServicePort6443、kubeProxyReplacementtrue通过 Edit as YAML 检查rkeConfig并按需设置disable-kube-proxy: true使用 Registration 命令加入节点等待集群进入 Active 状态在 Rancher UI 的 Installed Apps 中验证并通过 UI 升级 Cilium。这套方案在保留 Rancher 集群管理能力的同时将 CNI 的控制权完整交还给 Cilium 用户实现了Rancher 管集群、Cilium 管网络的清晰分工。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考