在 OpenShift 4.x 上安装 Cilium默认配置、环境要求与安装路径全解析【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本指南以 Cilium 官方安装文档中的 OpenShift 专章requirements-openshift.rst为核心骨架面向需要在 Red Hat OpenShift 上部署 Cilium 的集群管理员与平台工程师。文章覆盖 OpenShift 场景下的默认数据路径/IPAM/数据存储选型、版本与内核等环境前置要求、基于 OpenShift 官方安装器的推荐部署路径、OKD 环境的 OLM 镜像安装方式以及 OpenShift 特有的 DNS 策略适配与 SELinux 注意事项帮助读者在 OpenShift 集群中落地一套可运行、可验证的 Cilium 网络方案。一、文档定位OpenShift 安装要求一览在 Cilium 的安装文档体系中requirements-openshift.rst 是 OpenShift 专属的“前置要求”清单页。它与 requirements-intro.rst通用 Kubernetes 要求、requirements-eks.rstEKS、requirements-aks.rstAKS、requirements-gke.rstGKE等页面并列共同构成按云厂商/发行版划分的安装指引矩阵。该页面在仓库中有两处被直接引用k8s-install-default.rst 的 OpenShift tab 中通过.. include:: ../installation/requirements-openshift.rst内嵌本页内容k8s-install-helm.rst 的 Helm 安装方法中同样内嵌了本页作为 OpenShift 场景的“Requirements”小节。由此可见本文档是 OpenShift 安装流程的标准入口之一任何通过 Helm 或默认安装路径在 OpenShift 上部署 Cilium 的操作都会先经过这份要求清单。二、OpenShift 场景的默认配置组合根据原文档在 OpenShift 上安装 Cilium 时采用的默认配置组合如下Datapath数据路径IPAMIP 地址管理Datastore数据存储Encapsulation封装Cluster PoolKubernetes CRD三个维度分别说明如下Datapath EncapsulationCilium 采用基于封装的覆盖网络数据路径即 VXLAN 隧道模式。工作负载的 Pod 流量通过 VXLAN 隧道在节点间传输对底层网络拓扑依赖最小适合 OpenShift 这种对底层网络不做过深耦合的通用场景。相关实现可参考仓库中的 bpf/lib/encap.h 与 pkg/datapath/linux 等数据路径代码。IPAM Cluster PoolIP 地址由 Cilium Operator 从集群级的 Pod CIDR 池中统一分配而不是依赖 OpenShift 自身的 HostSubnet / SDN 分配机制。这意味着安装后 Cilium 完全接管 Pod 网络的地址分配。Cluster Pool 的相关实现位于 pkg/ipam特别是allocator与clusterpool相关代码以及 operator 目录。Datastore Kubernetes CRDCilium 的标识Identity、节点、端点等信息直接存储在 Kubernetes CRD 中无需额外部署 etcd 集群简化了在 OpenShift 上的运维负担。CRD 定义见 api/v1 下的类型定义实际 CRD 清单可参考 examples/crds。对比其他云平台可以看出该组合的定位EKS 默认使用 Direct Routing AWS ENI见 requirements-eks.rstGKE 默认使用 Direct Routing PodCIDR见 requirements-gke.rst而 OpenShift 与 AKS见 requirements-aks.rst一样选择了 Encapsulation Cluster Pool —— 因为 OpenShift 集群通常构建在异构或不受 Cilium 直接控制的底层网络上封装模式能够屏蔽底层差异。三、环境要求版本与内核前置条件原文档明确列出的硬性要求为Requirements:OpenShift 4.x在此基础上结合仓库中通用的 requirements-intro.rst 与 requirements-generic.rstOpenShift 集群在安装 Cilium 前还需要满足以下通用前置条件这些要求同样适用于 OpenShift 节点Kubernetes 1.16OpenShift 4.x 对应的 Kubernetes 版本均满足该下限但建议使用较新的 4.x 小版本以获得完整的功能支持。Linux 内核 5.10或等效版本Cilium 依赖 eBPF 特性较老的内核会缺少BPF_PROG_TYPE_CGROUP_SOCK_ADDR、BPF_PROG_TYPE_LSM等能力。OpenShift 4.x 基于 RHEL/CoreOS 内核需确认节点内核版本满足要求具体内核特性门槛可参考仓库中 bpf/bpf_probes.c 与 bpf/probes 相关探针代码。Kubernetes 必须运行在 CNI 模式Cilium 以 CNI 插件身份接管 Pod 网络。OpenShift 4.x 默认使用 OVN-Kubernetes 或 OpenShift SDN 作为 CNI安装 Cilium 时需要以网络栈替换或在新集群中直接选用的方式切换详见下文“安装路径”一节。所有工作节点上挂载 eBPF 文件系统Cilium 依赖/sys/fs/bpf挂载点若节点未挂载Cilium Agent 会自动尝试挂载相关逻辑见 pkg/datapath/linux 与 pkg/mountinfo但提前在节点上配置挂载更稳妥。推荐在kube-controller-manager中启用 PodCIDR 分配--allocate-node-cidrs虽然 OpenShift 默认配置通常已启用该选项但作为前置检查项需要确认因为它影响 Cluster Pool IPAM 与节点 PodCIDR 的一致性。提示以上通用要求来自仓库中的 requirements-intro.rst系统级内核要求的详细说明可进一步参考 Cilium 管理指南中的系统要求章节对应admin_system_reqs锚点即 requirements-generic.rst 中引用的系统要求说明。四、推荐安装路径通过 OpenShift 官方安装器创建的集群原文档在“执行步骤”之后将具体的安装操作指向了 OpenShift 安装专章k8s-install-openshift-okd.rst并在 k8s-install-default.rst 中说明Cilium 是Red Hat 认证的 OpenShift CNI 插件并且当集群使用 OpenShift 官方安装器openshift-install创建时安装效果最佳。这意味着推荐的落地路径是使用openshift-install创建一个全新的 OpenShift 4.x 集群在集群创建阶段或创建完成后将 Cilium 配置为唯一的 CNI 插件替换默认的 OVN-Kubernetes / OpenShift SDN参照 OpenShift 专章的安装说明完成部署。关于第 3 步的具体操作仓库当前的状态是OpenShift OKD 目前没有社区维护的直接安装流程但可以通过 Red Hat 生态目录Red Hat Ecosystem Catalog中厂商维护的 OLM 镜像进行安装详见下文第五节。OLMOperator Lifecycle Manager是 OpenShift 内置的 Operator 管理框架通过 CatalogSource 将 Cilium Operator 交付到集群再以 Subscription 的方式自动部署这是 OpenShift 平台上安装认证 Operator 的标准方式。五、OKD 场景基于厂商 OLM 镜像的安装方式k8s-install-openshift-okd.rst 明确指出目前不存在社区维护的 OpenShift 上的 Cilium 安装方式。不过可以通过厂商维护的 OLM 镜像在 OpenShift 上安装 Cilium。这些镜像及其安装说明可以在 Red Hat 生态目录中找到。具体操作路径引用自该文档访问 Red Hat 生态目录中 Isovalent Enterprise for Cilium 的软件页面获取产品信息与安装指引在目录中检索 “Isovalent” 相关的Certified OLM 容器镜像按镜像说明在 OpenShift 集群中配置 OLM CatalogSource 与 Subscription完成 Cilium Operator 的部署Operator 部署完成后由其创建 Cilium Agent DaemonSet 与 Cilium Operator Deployment接管集群网络。注意本文档描述的 OLM 安装方式以厂商镜像为准具体版本、命名空间与参数请以 Red Hat 生态目录中镜像页面提供的说明为准。该文档还附带了 eCHO episode 31OpenShift Test Environment with Cilium的视频资料用于学习 OpenShift Cilium 的测试环境搭建仓库内不包含该视频内容仅作为延伸学习指引。六、OpenShift 特有的适配要点虽然原文档只给出“OpenShift 4.x”这一条要求但从仓库其他文档与示例中可以提炼出在 OpenShift 上运行 Cilium 时必须处理的平台差异这些是实际落地时的高频坑点6.1 DNS 策略命名空间与端口差异OpenShift 使用openshift-dns命名空间运行 CoreDNS而非标准 Kubernetes 的kube-system/kube-dns且 DNS 监听端口为5353非 53。因此为集群外域名FQDN放行 DNS 查询的 CiliumNetworkPolicy 需要相应调整见 Documentation/security/dns.rst 的说明。仓库中提供了开箱即用的 OpenShift 版 DNS 策略示例 dns-matchname-openshift.yamlapiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: fqdn spec: endpointSelector: matchLabels: org: empire class: mediabot egress: - toFQDNs: - matchName: api.github.com - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: openshift-dns toPorts: - ports: - port: 5353 protocol: ANY rules: dns: - matchPattern: *与标准示例 dns-matchname.yaml 相比OpenShift 版的关键差异正是命名空间标签改为openshift-dns、去掉k8s:k8s-appkube-dns标签匹配、DNS 端口改为 5353。6.2 SELinux 与 Envoy 代理的兼容性Red Hat OpenShift Container Platform 默认启用 SELinux。仓库中 Envoy 代理相关文档Documentation/security/network/proxy/envoy.rst指出由于 Cilium Agent 与 Envoy DaemonSet 之间通过 UNIX 域套接字通信当主机启用 SELinux 时两者需要具备兼容的 SELinux 类型——默认均为高权限类型spc_t。在 OpenShift 上部署涉及 L7 代理Envoy的 Cilium 功能时需确认该兼容性约束。6.3 节点污点Taint机制与未托管 PodOpenShift 4.x 集群节点由 MachineConfig 管理节点可能提前就绪并运行默认 CNI。为避免应用 Pod 在 Cilium 接管前被默认网络托管推荐利用 Cilium 的节点污点机制详见 Documentation/installation/taints.rst机制流程管理员在未初始化的节点上放置node.cilium.io/agent-not-readytrue污点 → Cilium Agent 启动并完成节点初始化后自动移除污点 → 此后 Pod 才被调度/运行其网络由 Cilium 管理 → 若 Cilium 暂时从节点退出Operator 会以NoSchedule效果重新施加污点污点键可通过agent-not-ready-taint-key选项调整例如使用ignore-taint.cluster-autoscaler.kubernetes.io/前缀以配合 Cluster Autoscaler效果选择建议NoExecute会在 Pod 被调度到节点前即阻止其执行是官方文档推荐的“最小破坏”模式而NoSchedule仅阻止调度节点重启后已调度的 Pod 可能与 Cilium 并发启动产生未托管 Pod。当然NoExecute也可能带来 Pod 被意外驱逐的副作用具体取舍需结合集群运维策略决定。七、安装后的验证与下一步完成 OpenShift 上的 Cilium 部署后可通过以下方式验证集群网络是否就绪使用 CLI 或kubectl运行连通性测试Cilium CLI 的cilium connectivity test用法见 Documentation/installation/cli-connectivity-test.rst会创建一组测试 Pod验证集群内 L3/L4/L7 策略与服务负载均衡等能力检查 Cilium 状态cilium status查看 Agent 健康、Kubernetes 集成与 IPAM 模式详见 Documentation/installation/cli-status.rst或使用kubectl -n kube-system get pods -l k8s-appcilium确认 DaemonSet 在全部节点就绪若在 OpenShift 上启用了 Hubble 可观测性可通过 Documentation/observability 下的指标与流日志文档核对流量可视化是否正常其中工作负载标签体系已明确支持 OpenShift 的DeploymentConfig工作负载类型见 Documentation/observability/metrics.rst。八、小结本文围绕 requirements-openshift.rst 展开梳理了在 OpenShift 4.x 上部署 Cilium 的完整脉络默认配置组合EncapsulationVXLAN 封装 Cluster Pool IPAM Kubernetes CRD 数据存储与 AKS 等云平台一致适合底层网络不可控的场景硬性要求OpenShift 4.x并叠加通用的 Kubernetes 1.16、内核 5.10、CNI 模式、eBPF 文件系统挂载等前置条件安装路径Cilium 是 Red Hat 认证的 OpenShift CNI 插件推荐配合 OpenShift 官方安装器使用OKD 场景下通过 Red Hat 生态目录中的厂商维护 OLM 镜像安装平台适配需处理openshift-dns命名空间 5353 端口、SELinux 与 Envoy 的spc_t类型兼容、节点污点机制等 OpenShift 特有细节。掌握这些要点后读者即可在 OpenShift 集群中按官方推荐路径完成 Cilium 的安装、验证与日常维护。如需深入理解安装背后涉及的 IPAM、数据路径与 CRD 实现可继续阅读本仓库 pkg/ipam、pkg/datapath 与 api/v1 下的源码。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
在 OpenShift 4.x 上安装 Cilium：默认配置、环境要求与安装路径全解析
在 OpenShift 4.x 上安装 Cilium默认配置、环境要求与安装路径全解析【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本指南以 Cilium 官方安装文档中的 OpenShift 专章requirements-openshift.rst为核心骨架面向需要在 Red Hat OpenShift 上部署 Cilium 的集群管理员与平台工程师。文章覆盖 OpenShift 场景下的默认数据路径/IPAM/数据存储选型、版本与内核等环境前置要求、基于 OpenShift 官方安装器的推荐部署路径、OKD 环境的 OLM 镜像安装方式以及 OpenShift 特有的 DNS 策略适配与 SELinux 注意事项帮助读者在 OpenShift 集群中落地一套可运行、可验证的 Cilium 网络方案。一、文档定位OpenShift 安装要求一览在 Cilium 的安装文档体系中requirements-openshift.rst 是 OpenShift 专属的“前置要求”清单页。它与 requirements-intro.rst通用 Kubernetes 要求、requirements-eks.rstEKS、requirements-aks.rstAKS、requirements-gke.rstGKE等页面并列共同构成按云厂商/发行版划分的安装指引矩阵。该页面在仓库中有两处被直接引用k8s-install-default.rst 的 OpenShift tab 中通过.. include:: ../installation/requirements-openshift.rst内嵌本页内容k8s-install-helm.rst 的 Helm 安装方法中同样内嵌了本页作为 OpenShift 场景的“Requirements”小节。由此可见本文档是 OpenShift 安装流程的标准入口之一任何通过 Helm 或默认安装路径在 OpenShift 上部署 Cilium 的操作都会先经过这份要求清单。二、OpenShift 场景的默认配置组合根据原文档在 OpenShift 上安装 Cilium 时采用的默认配置组合如下Datapath数据路径IPAMIP 地址管理Datastore数据存储Encapsulation封装Cluster PoolKubernetes CRD三个维度分别说明如下Datapath EncapsulationCilium 采用基于封装的覆盖网络数据路径即 VXLAN 隧道模式。工作负载的 Pod 流量通过 VXLAN 隧道在节点间传输对底层网络拓扑依赖最小适合 OpenShift 这种对底层网络不做过深耦合的通用场景。相关实现可参考仓库中的 bpf/lib/encap.h 与 pkg/datapath/linux 等数据路径代码。IPAM Cluster PoolIP 地址由 Cilium Operator 从集群级的 Pod CIDR 池中统一分配而不是依赖 OpenShift 自身的 HostSubnet / SDN 分配机制。这意味着安装后 Cilium 完全接管 Pod 网络的地址分配。Cluster Pool 的相关实现位于 pkg/ipam特别是allocator与clusterpool相关代码以及 operator 目录。Datastore Kubernetes CRDCilium 的标识Identity、节点、端点等信息直接存储在 Kubernetes CRD 中无需额外部署 etcd 集群简化了在 OpenShift 上的运维负担。CRD 定义见 api/v1 下的类型定义实际 CRD 清单可参考 examples/crds。对比其他云平台可以看出该组合的定位EKS 默认使用 Direct Routing AWS ENI见 requirements-eks.rstGKE 默认使用 Direct Routing PodCIDR见 requirements-gke.rst而 OpenShift 与 AKS见 requirements-aks.rst一样选择了 Encapsulation Cluster Pool —— 因为 OpenShift 集群通常构建在异构或不受 Cilium 直接控制的底层网络上封装模式能够屏蔽底层差异。三、环境要求版本与内核前置条件原文档明确列出的硬性要求为Requirements:OpenShift 4.x在此基础上结合仓库中通用的 requirements-intro.rst 与 requirements-generic.rstOpenShift 集群在安装 Cilium 前还需要满足以下通用前置条件这些要求同样适用于 OpenShift 节点Kubernetes 1.16OpenShift 4.x 对应的 Kubernetes 版本均满足该下限但建议使用较新的 4.x 小版本以获得完整的功能支持。Linux 内核 5.10或等效版本Cilium 依赖 eBPF 特性较老的内核会缺少BPF_PROG_TYPE_CGROUP_SOCK_ADDR、BPF_PROG_TYPE_LSM等能力。OpenShift 4.x 基于 RHEL/CoreOS 内核需确认节点内核版本满足要求具体内核特性门槛可参考仓库中 bpf/bpf_probes.c 与 bpf/probes 相关探针代码。Kubernetes 必须运行在 CNI 模式Cilium 以 CNI 插件身份接管 Pod 网络。OpenShift 4.x 默认使用 OVN-Kubernetes 或 OpenShift SDN 作为 CNI安装 Cilium 时需要以网络栈替换或在新集群中直接选用的方式切换详见下文“安装路径”一节。所有工作节点上挂载 eBPF 文件系统Cilium 依赖/sys/fs/bpf挂载点若节点未挂载Cilium Agent 会自动尝试挂载相关逻辑见 pkg/datapath/linux 与 pkg/mountinfo但提前在节点上配置挂载更稳妥。推荐在kube-controller-manager中启用 PodCIDR 分配--allocate-node-cidrs虽然 OpenShift 默认配置通常已启用该选项但作为前置检查项需要确认因为它影响 Cluster Pool IPAM 与节点 PodCIDR 的一致性。提示以上通用要求来自仓库中的 requirements-intro.rst系统级内核要求的详细说明可进一步参考 Cilium 管理指南中的系统要求章节对应admin_system_reqs锚点即 requirements-generic.rst 中引用的系统要求说明。四、推荐安装路径通过 OpenShift 官方安装器创建的集群原文档在“执行步骤”之后将具体的安装操作指向了 OpenShift 安装专章k8s-install-openshift-okd.rst并在 k8s-install-default.rst 中说明Cilium 是Red Hat 认证的 OpenShift CNI 插件并且当集群使用 OpenShift 官方安装器openshift-install创建时安装效果最佳。这意味着推荐的落地路径是使用openshift-install创建一个全新的 OpenShift 4.x 集群在集群创建阶段或创建完成后将 Cilium 配置为唯一的 CNI 插件替换默认的 OVN-Kubernetes / OpenShift SDN参照 OpenShift 专章的安装说明完成部署。关于第 3 步的具体操作仓库当前的状态是OpenShift OKD 目前没有社区维护的直接安装流程但可以通过 Red Hat 生态目录Red Hat Ecosystem Catalog中厂商维护的 OLM 镜像进行安装详见下文第五节。OLMOperator Lifecycle Manager是 OpenShift 内置的 Operator 管理框架通过 CatalogSource 将 Cilium Operator 交付到集群再以 Subscription 的方式自动部署这是 OpenShift 平台上安装认证 Operator 的标准方式。五、OKD 场景基于厂商 OLM 镜像的安装方式k8s-install-openshift-okd.rst 明确指出目前不存在社区维护的 OpenShift 上的 Cilium 安装方式。不过可以通过厂商维护的 OLM 镜像在 OpenShift 上安装 Cilium。这些镜像及其安装说明可以在 Red Hat 生态目录中找到。具体操作路径引用自该文档访问 Red Hat 生态目录中 Isovalent Enterprise for Cilium 的软件页面获取产品信息与安装指引在目录中检索 “Isovalent” 相关的Certified OLM 容器镜像按镜像说明在 OpenShift 集群中配置 OLM CatalogSource 与 Subscription完成 Cilium Operator 的部署Operator 部署完成后由其创建 Cilium Agent DaemonSet 与 Cilium Operator Deployment接管集群网络。注意本文档描述的 OLM 安装方式以厂商镜像为准具体版本、命名空间与参数请以 Red Hat 生态目录中镜像页面提供的说明为准。该文档还附带了 eCHO episode 31OpenShift Test Environment with Cilium的视频资料用于学习 OpenShift Cilium 的测试环境搭建仓库内不包含该视频内容仅作为延伸学习指引。六、OpenShift 特有的适配要点虽然原文档只给出“OpenShift 4.x”这一条要求但从仓库其他文档与示例中可以提炼出在 OpenShift 上运行 Cilium 时必须处理的平台差异这些是实际落地时的高频坑点6.1 DNS 策略命名空间与端口差异OpenShift 使用openshift-dns命名空间运行 CoreDNS而非标准 Kubernetes 的kube-system/kube-dns且 DNS 监听端口为5353非 53。因此为集群外域名FQDN放行 DNS 查询的 CiliumNetworkPolicy 需要相应调整见 Documentation/security/dns.rst 的说明。仓库中提供了开箱即用的 OpenShift 版 DNS 策略示例 dns-matchname-openshift.yamlapiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: fqdn spec: endpointSelector: matchLabels: org: empire class: mediabot egress: - toFQDNs: - matchName: api.github.com - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: openshift-dns toPorts: - ports: - port: 5353 protocol: ANY rules: dns: - matchPattern: *与标准示例 dns-matchname.yaml 相比OpenShift 版的关键差异正是命名空间标签改为openshift-dns、去掉k8s:k8s-appkube-dns标签匹配、DNS 端口改为 5353。6.2 SELinux 与 Envoy 代理的兼容性Red Hat OpenShift Container Platform 默认启用 SELinux。仓库中 Envoy 代理相关文档Documentation/security/network/proxy/envoy.rst指出由于 Cilium Agent 与 Envoy DaemonSet 之间通过 UNIX 域套接字通信当主机启用 SELinux 时两者需要具备兼容的 SELinux 类型——默认均为高权限类型spc_t。在 OpenShift 上部署涉及 L7 代理Envoy的 Cilium 功能时需确认该兼容性约束。6.3 节点污点Taint机制与未托管 PodOpenShift 4.x 集群节点由 MachineConfig 管理节点可能提前就绪并运行默认 CNI。为避免应用 Pod 在 Cilium 接管前被默认网络托管推荐利用 Cilium 的节点污点机制详见 Documentation/installation/taints.rst机制流程管理员在未初始化的节点上放置node.cilium.io/agent-not-readytrue污点 → Cilium Agent 启动并完成节点初始化后自动移除污点 → 此后 Pod 才被调度/运行其网络由 Cilium 管理 → 若 Cilium 暂时从节点退出Operator 会以NoSchedule效果重新施加污点污点键可通过agent-not-ready-taint-key选项调整例如使用ignore-taint.cluster-autoscaler.kubernetes.io/前缀以配合 Cluster Autoscaler效果选择建议NoExecute会在 Pod 被调度到节点前即阻止其执行是官方文档推荐的“最小破坏”模式而NoSchedule仅阻止调度节点重启后已调度的 Pod 可能与 Cilium 并发启动产生未托管 Pod。当然NoExecute也可能带来 Pod 被意外驱逐的副作用具体取舍需结合集群运维策略决定。七、安装后的验证与下一步完成 OpenShift 上的 Cilium 部署后可通过以下方式验证集群网络是否就绪使用 CLI 或kubectl运行连通性测试Cilium CLI 的cilium connectivity test用法见 Documentation/installation/cli-connectivity-test.rst会创建一组测试 Pod验证集群内 L3/L4/L7 策略与服务负载均衡等能力检查 Cilium 状态cilium status查看 Agent 健康、Kubernetes 集成与 IPAM 模式详见 Documentation/installation/cli-status.rst或使用kubectl -n kube-system get pods -l k8s-appcilium确认 DaemonSet 在全部节点就绪若在 OpenShift 上启用了 Hubble 可观测性可通过 Documentation/observability 下的指标与流日志文档核对流量可视化是否正常其中工作负载标签体系已明确支持 OpenShift 的DeploymentConfig工作负载类型见 Documentation/observability/metrics.rst。八、小结本文围绕 requirements-openshift.rst 展开梳理了在 OpenShift 4.x 上部署 Cilium 的完整脉络默认配置组合EncapsulationVXLAN 封装 Cluster Pool IPAM Kubernetes CRD 数据存储与 AKS 等云平台一致适合底层网络不可控的场景硬性要求OpenShift 4.x并叠加通用的 Kubernetes 1.16、内核 5.10、CNI 模式、eBPF 文件系统挂载等前置条件安装路径Cilium 是 Red Hat 认证的 OpenShift CNI 插件推荐配合 OpenShift 官方安装器使用OKD 场景下通过 Red Hat 生态目录中的厂商维护 OLM 镜像安装平台适配需处理openshift-dns命名空间 5353 端口、SELinux 与 Envoy 的spc_t类型兼容、节点污点机制等 OpenShift 特有细节。掌握这些要点后读者即可在 OpenShift 集群中按官方推荐路径完成 Cilium 的安装、验证与日常维护。如需深入理解安装背后涉及的 IPAM、数据路径与 CRD 实现可继续阅读本仓库 pkg/ipam、pkg/datapath 与 api/v1 下的源码。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
