尧图网页设计 
在 Kind 上部署 Cilium依赖安装、集群创建与验证完整指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文聚焦于 Cilium 官方 Kind 安装方案Documentation/installation/kind.rst的第一步——依赖安装并沿着官方指南的完整链路展开从 Docker、kubectl、Helm、Kind 四个前置依赖的版本要求与安装验证到 kind 集群配置、集群创建、Cilium 镜像预加载与 Helm 部署再到安装验证与常见故障排查。读完本文你将能够在一台安装了 Docker 的 Linux 主机上从零搭建一个由 4 个节点1 个控制平面 3 个 worker组成的本地多节点 Kubernetes 集群并成功运行以 eBPF 为数据面的 Cilium 网络插件。为什么用 Kind 部署 CiliumKindKubernetes in Docker通过把 Kubernetes 节点以容器方式运行在 Docker 之上提供了一种无需虚拟机的本地多节点集群方案。Cilium 官方之所以推荐 Kind 作为演示与开发环境核心原因有二多节点真实拓扑Kind 支持在一个控制平面节点之外再拉起多个 worker 节点能够贴近真实集群拓扑验证 Cilium 的 DaemonSet、节点间 Pod 网络互通等行为而不是单节点的玩具集群。与仓库开发工作流深度绑定Cilium 仓库自带一整套基于 Kind 的开发/测试目标详见下文与仓库开发工作流的衔接make kind、make kind-install-cilium等命令使得在本地快速迭代 Cilium 源码成为可能。该官方指南Documentation/installation/kind.rst将整个流程划分为安装依赖Install Dependencies→ 配置 KindConfigure kind→ 创建集群Create a cluster→ 安装 CiliumInstall Cilium→ 验证安装Validate the Installation→ 下一步Next Steps。依赖安装作为第一步其内容记录在 Documentation/installation/kind-install-deps.rst 中共四个依赖项下面逐一展开。第一步安装四个前置依赖根据 Documentation/installation/kind-install-deps.rst 的说明在开始之前需要先安装四个工具且每个都有明确的版本下限要求依赖工具版本要求作用Dockerstable 版本承载 Kind 节点的容器运行时是整个集群的地基kubectl v1.14.0与集群 API Server 交互的命令行客户端helm v3.13.0以 Helm Chart 方式部署和管理 Ciliumkind v0.7.0在 Docker 中创建多节点 Kubernetes 集群1.1 安装 DockerstableKind 的节点本质上是 Docker 容器因此 Docker 是唯一硬性的运行时依赖。安装 stable 版本 Docker Engine 后建议通过以下命令验证守护进程与权限是否就绪$ docker version $ docker run --rm hello-world需要特别注意的是Kind 对 Docker 的cgroup 配置有额外要求详见下文启用 Socket LB 的 cgroup 前提如果计划在 Kind 上启用 Cilium 的 Socket LBkube-proxy 替代模式必须在 Docker 层面做好相应配置。1.2 安装 kubectl v1.14.0kubectl 用于访问 Kind 集群的 API Server验证集群状态、部署资源、查看 Pod 日志都依赖它。官方文档要求版本不低于 v1.14.0实际使用中建议选择与目标 Kubernetes 版本相近或更新的 kubectl以获得完整的 API 兼容性$ kubectl version --client Client Version: v1.30.0安装完成后kind create cluster会自动把新集群的访问上下文写入KUBECONFIG未设置该环境变量时写入${HOME}/.kube/configkubectl 会默认使用该上下文。1.3 安装 Helm v3.13.0Cilium 的官方推荐部署方式是基于 Helm Chart 的因此需要 Helm v3。Cilium 文档要求版本不低于 v3.13.0验证方式$ helm version version.BuildInfo{Version:v3.15.0, ...}关于 Helm 版本要求的历史背景Cilium 使用 Helm 的若干较新特性如更完整的子 chart 与依赖管理能力因此文档将 v3.13.0 设为下限。部署时将以cilium作为 release 名、kube-system作为命名空间安装官方 Chart详见下文安装 Cilium。1.4 安装 Kind v0.7.0Kind 是创建集群的工具要求版本不低于 v0.7.0。仓库的开发者文档 Documentation/contributing/development/dev_setup.rst 中给出的现代安装方式之一是$ go install sigs.k8s.io/kindv0.19.0 $ kind version kind v0.19.0 go1.21.x linux/amd64安装完成后即可进入下一步——编写 kind 配置文件。第二步配置 Kind禁用默认 CNIKind 集群的创建行为由 YAML 配置文件控制。这一步必须禁用 Kind 默认的 CNI否则无法将网络插件替换为 Cilium。仓库提供了开箱即用的模板文件 Documentation/installation/kind-config.yaml内容如下kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker - role: worker networking: disableDefaultCNI: true该模板会创建一个1 个控制平面节点 3 个 worker 节点的 4 节点集群其中disableDefaultCNI: true是关键配置它让 Kind 不部署自己的默认网络插件把数据面完全交给之后安装的 Cilium。关于该配置模板的两个补充要点Kubernetes 版本控制默认情况下 Kind 使用其发布时对应的最新 Kubernetes 版本。如需固定版本可以为每个节点指定image字段例如image: kindest/node:v1.29.2具体取值需参考 Kind 官方发布的节点镜像列表。Pod/Service 网段冲突风险Kind 的默认网段为 PodSubnet10.244.0.0/16、ServiceSubnet10.96.0.0/12。如果这些网段与你的本地网络地址段冲突必须在配置文件的networking段中显式指定不冲突的网段否则部署 Cilium 后会出现连通性问题。例如networking: disableDefaultCNI: true podSubnet: 10.10.0.0/16 serviceSubnet: 10.11.0.0/16以上说明来自 Documentation/installation/kind-configure.rst。第三步创建 Kind 集群将上述配置文件保存为kind-config.yaml后通过--config参数创建集群$ kind create cluster --configkind-config.yaml等待数十秒到数分钟后4 节点集群创建完成。此时kubectl会新增一个名为kind-kind的上下文可以通过如下命令确认集群可达$ kubectl cluster-info --context kind-kind预期行为提示在 Cilium 部署完成之前集群节点会一直停留在NotReady状态这是正常的——因为节点上的 CNI 数据面还没有就绪kubelet 无法上报 Ready。不要因此误判集群创建失败见 Documentation/installation/kind-create-cluster.rst。第四步安装 Cilium4.1 配置 Helm 仓库安装分为添加 Chart 源与预加载镜像两步。首先添加 Cilium 官方 Helm 仓库仓库文档见 Documentation/installation/k8s-install-download-release.rst$ helm repo add cilium https://helm.cilium.io/除传统 Helm 仓库外Cilium Chart 也通过 OCI RegistryQuay.io 与 Docker Hub发布可以直接使用oci://协议的 URL 安装无需额外配置仓库。4.2 预加载 Cilium 镜像由于 Kind 节点是 Docker 容器其内部的容器运行时无法直接访问宿主机 Docker 镜像缓存因此需要先把 Cilium 镜像导入到每个节点。仓库文档 Documentation/installation/kind-preload.rst 给出的两步操作为其中镜像标签应替换为你实际安装的 Cilium 版本当前仓库的 VERSION 文件标注的版本为v1.21.0-dev对应镜像标签v1.21.0-dev$ docker pull quay.io/cilium/cilium:v1.21.0-dev $ kind load docker-image quay.io/cilium/cilium:v1.21.0-dev4.3 通过 Helm 安装使用 Helm 在kube-system命名空间安装 releasecilium并显式指定两个与 Kind 场景匹配的关键参数$ helm install cilium cilium/cilium --namespace kube-system \ --set image.pullPolicyIfNotPresent \ --set ipam.modekubernetes参数说明image.pullPolicyIfNotPresent镜像已在第 4.2 步预加载进节点因此无需每次从远端拉取避免网络波动或镜像仓库不可达导致 Pod 启动失败。ipam.modekubernetes使用 Kubernetes 原生的 Pod CIDR 分配基于节点分配的 Pod 网段与 Kind 默认的节点网段分配方式天然匹配无需依赖外部 IPAM。4.4 启用 Socket LB 的 cgroup 前提Kind 场景下如果要启用 Cilium 的 Socket LB即 kube-proxy 替代模式需要满足三个 cgroup 相关前提详见 Documentation/installation/kind.rst 中的说明宿主机启用 cgroup v2通过内核参数systemd.unified_cgroup_hierarchy1启用。每个 Kind 节点运行在独立的 cgroup namespace 中且与宿主机不同容器运行时需配置为 private cgroup namespace 模式例如 dockerd 需设置--default-cgroupns-modeprivate。验证方法是分别查看各节点与宿主机上的 cgroup namespace 序号它们必须互不相同$ docker exec kind-control-plane ls -al /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 Jul 20 19:20 /proc/self/ns/cgroup - cgroup:[4026532461] $ docker exec kind-worker ls -al /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 Jul 20 19:20 /proc/self/ns/cgroup - cgroup:[4026532543] $ ls -al /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 Jul 19 09:38 /proc/self/ns/cgroup - cgroup:[4026531835]cgroup v1 的net_cls与net_prio控制器被禁用或整体禁用 cgroup v1例如内核参数cgroup_no_v1all或者宿主机内核版本不低于 5.14该版本包含相关的 cgroup 修复补丁。不满足上述前提时Socket LB 无法正常工作Cilium 可能把 eBPF 程序挂载到错误的 cgroup 层级。第五步验证安装Cilium 部署完成后可以按两种方式验证详见 Documentation/installation/k8s-install-validate.rst。5.1 使用 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.21.0-dev: 2 cilium-operator quay.io/cilium/operator-generic:v1.21.0-dev: 2--wait参数会阻塞等待所有组件就绪随后输出各组件状态Cilium / Operator / Hubble / ClusterMesh以及 DaemonSet、Deployment、容器与镜像版本信息是判断安装是否成功的最快捷方式。5.2 使用 kubectl 手动验证通过 watch Pod 状态观察组件拉起过程$ 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所有组件从 Pending 变为 Running 通常需要数分钟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与cilium-operator的 Pod 全部 Running且节点转为 Ready后即可进行进一步的连通性测试cilium connectivity test或基于 kubectl 的手工测试。与仓库开发工作流的衔接Makefile 中的 Kind 目标除了文档化的手动流程Cilium 仓库还内置了一整套 Kind 自动化目标开发者文档 Documentation/contributing/development/dev_setup.rst 对此有专门描述。这些目标由 contrib/scripts/kind.sh 与 Makefile.kind 驱动核心目标包括目标作用make kind基于传入的配置创建 Kind 集群make kind-down销毁并删除集群make kind-image构建全部 Cilium 镜像并加载进节点make kind-image-agent仅构建 Cilium Agent 镜像并加载make kind-image-operator仅构建 Cilium Operatorgeneric镜像并加载make kind-debug以关闭优化、开启调试Delve的方式构建镜像并加载make kind-install-cilium使用 Helm 将 Cilium 安装进集群make kind-install-cilium-fast快速安装模式跳过部分构建步骤make kind-image-fast快速构建二进制并加载与这些目标配套的 Helm values 文件存放在 contrib/testing/ 目录下kind-common.yaml普通与快速模式共用、kind-values.yaml普通安装模式、kind-fast.yaml快速安装模式、kind-custom.yaml用户自定义 values存在时自动应用。make kind还支持通过环境变量定制行为例如IMAGE用于指定 Kind 节点镜像。这套工具链意味着如果需要在本地基于 Cilium 源码验证最新改动依赖安装完成后直接运行make kind make kind-image make kind-install-cilium即可复现一条完整的编译 → 构建镜像 → 加载 → 部署流水线。常见故障排查无法连接 k8s API Server当 Cilium Agent 日志中出现如下错误时levelinfo msgEstablishing connection to apiserver hosthttps://10.96.0.1:443 subsysk8s levelerror msgUnable to contact k8s api-server errorGet https://10.96.0.1:443/api/v1/namespaces/kube-system: dial tcp 10.96.0.1:443: connect: no route to host ipAddrhttps://10.96.0.1:443 subsysk8s levelfatal msgUnable to initialize Kubernetes subsystem errorunable to create k8s client: unable to create k8s client: Get https://10.96.0.1:443/api/v1/namespaces/kube-system: dial tcp 10.96.0.1:443: connect: no route to host subsysdaemon原因通常是Kind 节点是共享宿主机内核的 Docker 容器若 Socket LB 未正确禁用Cilium 挂载的 eBPF 程序可能已过期不再把对 API Server10.96.0.1:443的流量路由到当前的kind-control-plane容器。解决方案是重建 Kind 集群并重新执行 Cilium 安装步骤使 eBPF 程序重新挂载到正确的路径上。Cilium Agent Pod 持续崩溃若 Agent Pod 反复崩溃日志中出现levelwarning msg bpftool cgroup attach /var/run/cilium/cgroupv2 connect6 pinned /sys/fs/bpf/tc/globals/cilium_cgroups_connect6 subsysdatapath-loader levelwarning msgError: failed to attach program subsysdatapath-loader levelwarning msg RETCODE255 subsysdatapath-loader这通常意味着当前环境中已经运行着另一个 Cilium 实例例如在 Cilium 开发 VM 中或者在 kind 节点容器的父级 cgroup 层级上存在其他重叠的 BPF cgroup 类型程序。处理方式为先拆除已有 Cilium或使用bpftool cgroup手动分离父级 cgroup 层级上重叠的 BPF cgroup 程序后重试。下一步验证后的延展方向集群验证通过后官方指南Documentation/installation/next-steps.rst建议的后续方向包括配置与使用 Hubble 可观测性Documentation/observability/hubble-setup.rst 等文档、通过 Cilium CLI 操作 Hubble、部署 Hubble UI、基于 HTTP 的 L7 策略实践以及在多集群场景下使用 Cluster Mesh。值得一提的是Kind 集群也常被用来在沙箱环境中模拟 Cluster Mesh 多集群拓扑为每个集群单独创建 kind 配置显式设置互不重叠的podSubnet与serviceSubnet然后分别kind create cluster --namecluster1 --configkind-cluster1.yaml创建多个集群再按 Cluster Mesh 指南完成部署与连接相关配置示例见 Documentation/installation/kind.rst 的 Cluster Mesh 小节。这样即可在单台机器上完整体验跨集群的 Service 联邦与网络策略编排。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 Kind 上部署 Cilium：依赖安装、集群创建与验证完整指南
在 Kind 上部署 Cilium依赖安装、集群创建与验证完整指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文聚焦于 Cilium 官方 Kind 安装方案Documentation/installation/kind.rst的第一步——依赖安装并沿着官方指南的完整链路展开从 Docker、kubectl、Helm、Kind 四个前置依赖的版本要求与安装验证到 kind 集群配置、集群创建、Cilium 镜像预加载与 Helm 部署再到安装验证与常见故障排查。读完本文你将能够在一台安装了 Docker 的 Linux 主机上从零搭建一个由 4 个节点1 个控制平面 3 个 worker组成的本地多节点 Kubernetes 集群并成功运行以 eBPF 为数据面的 Cilium 网络插件。为什么用 Kind 部署 CiliumKindKubernetes in Docker通过把 Kubernetes 节点以容器方式运行在 Docker 之上提供了一种无需虚拟机的本地多节点集群方案。Cilium 官方之所以推荐 Kind 作为演示与开发环境核心原因有二多节点真实拓扑Kind 支持在一个控制平面节点之外再拉起多个 worker 节点能够贴近真实集群拓扑验证 Cilium 的 DaemonSet、节点间 Pod 网络互通等行为而不是单节点的玩具集群。与仓库开发工作流深度绑定Cilium 仓库自带一整套基于 Kind 的开发/测试目标详见下文与仓库开发工作流的衔接make kind、make kind-install-cilium等命令使得在本地快速迭代 Cilium 源码成为可能。该官方指南Documentation/installation/kind.rst将整个流程划分为安装依赖Install Dependencies→ 配置 KindConfigure kind→ 创建集群Create a cluster→ 安装 CiliumInstall Cilium→ 验证安装Validate the Installation→ 下一步Next Steps。依赖安装作为第一步其内容记录在 Documentation/installation/kind-install-deps.rst 中共四个依赖项下面逐一展开。第一步安装四个前置依赖根据 Documentation/installation/kind-install-deps.rst 的说明在开始之前需要先安装四个工具且每个都有明确的版本下限要求依赖工具版本要求作用Dockerstable 版本承载 Kind 节点的容器运行时是整个集群的地基kubectl v1.14.0与集群 API Server 交互的命令行客户端helm v3.13.0以 Helm Chart 方式部署和管理 Ciliumkind v0.7.0在 Docker 中创建多节点 Kubernetes 集群1.1 安装 DockerstableKind 的节点本质上是 Docker 容器因此 Docker 是唯一硬性的运行时依赖。安装 stable 版本 Docker Engine 后建议通过以下命令验证守护进程与权限是否就绪$ docker version $ docker run --rm hello-world需要特别注意的是Kind 对 Docker 的cgroup 配置有额外要求详见下文启用 Socket LB 的 cgroup 前提如果计划在 Kind 上启用 Cilium 的 Socket LBkube-proxy 替代模式必须在 Docker 层面做好相应配置。1.2 安装 kubectl v1.14.0kubectl 用于访问 Kind 集群的 API Server验证集群状态、部署资源、查看 Pod 日志都依赖它。官方文档要求版本不低于 v1.14.0实际使用中建议选择与目标 Kubernetes 版本相近或更新的 kubectl以获得完整的 API 兼容性$ kubectl version --client Client Version: v1.30.0安装完成后kind create cluster会自动把新集群的访问上下文写入KUBECONFIG未设置该环境变量时写入${HOME}/.kube/configkubectl 会默认使用该上下文。1.3 安装 Helm v3.13.0Cilium 的官方推荐部署方式是基于 Helm Chart 的因此需要 Helm v3。Cilium 文档要求版本不低于 v3.13.0验证方式$ helm version version.BuildInfo{Version:v3.15.0, ...}关于 Helm 版本要求的历史背景Cilium 使用 Helm 的若干较新特性如更完整的子 chart 与依赖管理能力因此文档将 v3.13.0 设为下限。部署时将以cilium作为 release 名、kube-system作为命名空间安装官方 Chart详见下文安装 Cilium。1.4 安装 Kind v0.7.0Kind 是创建集群的工具要求版本不低于 v0.7.0。仓库的开发者文档 Documentation/contributing/development/dev_setup.rst 中给出的现代安装方式之一是$ go install sigs.k8s.io/kindv0.19.0 $ kind version kind v0.19.0 go1.21.x linux/amd64安装完成后即可进入下一步——编写 kind 配置文件。第二步配置 Kind禁用默认 CNIKind 集群的创建行为由 YAML 配置文件控制。这一步必须禁用 Kind 默认的 CNI否则无法将网络插件替换为 Cilium。仓库提供了开箱即用的模板文件 Documentation/installation/kind-config.yaml内容如下kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker - role: worker networking: disableDefaultCNI: true该模板会创建一个1 个控制平面节点 3 个 worker 节点的 4 节点集群其中disableDefaultCNI: true是关键配置它让 Kind 不部署自己的默认网络插件把数据面完全交给之后安装的 Cilium。关于该配置模板的两个补充要点Kubernetes 版本控制默认情况下 Kind 使用其发布时对应的最新 Kubernetes 版本。如需固定版本可以为每个节点指定image字段例如image: kindest/node:v1.29.2具体取值需参考 Kind 官方发布的节点镜像列表。Pod/Service 网段冲突风险Kind 的默认网段为 PodSubnet10.244.0.0/16、ServiceSubnet10.96.0.0/12。如果这些网段与你的本地网络地址段冲突必须在配置文件的networking段中显式指定不冲突的网段否则部署 Cilium 后会出现连通性问题。例如networking: disableDefaultCNI: true podSubnet: 10.10.0.0/16 serviceSubnet: 10.11.0.0/16以上说明来自 Documentation/installation/kind-configure.rst。第三步创建 Kind 集群将上述配置文件保存为kind-config.yaml后通过--config参数创建集群$ kind create cluster --configkind-config.yaml等待数十秒到数分钟后4 节点集群创建完成。此时kubectl会新增一个名为kind-kind的上下文可以通过如下命令确认集群可达$ kubectl cluster-info --context kind-kind预期行为提示在 Cilium 部署完成之前集群节点会一直停留在NotReady状态这是正常的——因为节点上的 CNI 数据面还没有就绪kubelet 无法上报 Ready。不要因此误判集群创建失败见 Documentation/installation/kind-create-cluster.rst。第四步安装 Cilium4.1 配置 Helm 仓库安装分为添加 Chart 源与预加载镜像两步。首先添加 Cilium 官方 Helm 仓库仓库文档见 Documentation/installation/k8s-install-download-release.rst$ helm repo add cilium https://helm.cilium.io/除传统 Helm 仓库外Cilium Chart 也通过 OCI RegistryQuay.io 与 Docker Hub发布可以直接使用oci://协议的 URL 安装无需额外配置仓库。4.2 预加载 Cilium 镜像由于 Kind 节点是 Docker 容器其内部的容器运行时无法直接访问宿主机 Docker 镜像缓存因此需要先把 Cilium 镜像导入到每个节点。仓库文档 Documentation/installation/kind-preload.rst 给出的两步操作为其中镜像标签应替换为你实际安装的 Cilium 版本当前仓库的 VERSION 文件标注的版本为v1.21.0-dev对应镜像标签v1.21.0-dev$ docker pull quay.io/cilium/cilium:v1.21.0-dev $ kind load docker-image quay.io/cilium/cilium:v1.21.0-dev4.3 通过 Helm 安装使用 Helm 在kube-system命名空间安装 releasecilium并显式指定两个与 Kind 场景匹配的关键参数$ helm install cilium cilium/cilium --namespace kube-system \ --set image.pullPolicyIfNotPresent \ --set ipam.modekubernetes参数说明image.pullPolicyIfNotPresent镜像已在第 4.2 步预加载进节点因此无需每次从远端拉取避免网络波动或镜像仓库不可达导致 Pod 启动失败。ipam.modekubernetes使用 Kubernetes 原生的 Pod CIDR 分配基于节点分配的 Pod 网段与 Kind 默认的节点网段分配方式天然匹配无需依赖外部 IPAM。4.4 启用 Socket LB 的 cgroup 前提Kind 场景下如果要启用 Cilium 的 Socket LB即 kube-proxy 替代模式需要满足三个 cgroup 相关前提详见 Documentation/installation/kind.rst 中的说明宿主机启用 cgroup v2通过内核参数systemd.unified_cgroup_hierarchy1启用。每个 Kind 节点运行在独立的 cgroup namespace 中且与宿主机不同容器运行时需配置为 private cgroup namespace 模式例如 dockerd 需设置--default-cgroupns-modeprivate。验证方法是分别查看各节点与宿主机上的 cgroup namespace 序号它们必须互不相同$ docker exec kind-control-plane ls -al /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 Jul 20 19:20 /proc/self/ns/cgroup - cgroup:[4026532461] $ docker exec kind-worker ls -al /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 Jul 20 19:20 /proc/self/ns/cgroup - cgroup:[4026532543] $ ls -al /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 Jul 19 09:38 /proc/self/ns/cgroup - cgroup:[4026531835]cgroup v1 的net_cls与net_prio控制器被禁用或整体禁用 cgroup v1例如内核参数cgroup_no_v1all或者宿主机内核版本不低于 5.14该版本包含相关的 cgroup 修复补丁。不满足上述前提时Socket LB 无法正常工作Cilium 可能把 eBPF 程序挂载到错误的 cgroup 层级。第五步验证安装Cilium 部署完成后可以按两种方式验证详见 Documentation/installation/k8s-install-validate.rst。5.1 使用 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.21.0-dev: 2 cilium-operator quay.io/cilium/operator-generic:v1.21.0-dev: 2--wait参数会阻塞等待所有组件就绪随后输出各组件状态Cilium / Operator / Hubble / ClusterMesh以及 DaemonSet、Deployment、容器与镜像版本信息是判断安装是否成功的最快捷方式。5.2 使用 kubectl 手动验证通过 watch Pod 状态观察组件拉起过程$ 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所有组件从 Pending 变为 Running 通常需要数分钟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与cilium-operator的 Pod 全部 Running且节点转为 Ready后即可进行进一步的连通性测试cilium connectivity test或基于 kubectl 的手工测试。与仓库开发工作流的衔接Makefile 中的 Kind 目标除了文档化的手动流程Cilium 仓库还内置了一整套 Kind 自动化目标开发者文档 Documentation/contributing/development/dev_setup.rst 对此有专门描述。这些目标由 contrib/scripts/kind.sh 与 Makefile.kind 驱动核心目标包括目标作用make kind基于传入的配置创建 Kind 集群make kind-down销毁并删除集群make kind-image构建全部 Cilium 镜像并加载进节点make kind-image-agent仅构建 Cilium Agent 镜像并加载make kind-image-operator仅构建 Cilium Operatorgeneric镜像并加载make kind-debug以关闭优化、开启调试Delve的方式构建镜像并加载make kind-install-cilium使用 Helm 将 Cilium 安装进集群make kind-install-cilium-fast快速安装模式跳过部分构建步骤make kind-image-fast快速构建二进制并加载与这些目标配套的 Helm values 文件存放在 contrib/testing/ 目录下kind-common.yaml普通与快速模式共用、kind-values.yaml普通安装模式、kind-fast.yaml快速安装模式、kind-custom.yaml用户自定义 values存在时自动应用。make kind还支持通过环境变量定制行为例如IMAGE用于指定 Kind 节点镜像。这套工具链意味着如果需要在本地基于 Cilium 源码验证最新改动依赖安装完成后直接运行make kind make kind-image make kind-install-cilium即可复现一条完整的编译 → 构建镜像 → 加载 → 部署流水线。常见故障排查无法连接 k8s API Server当 Cilium Agent 日志中出现如下错误时levelinfo msgEstablishing connection to apiserver hosthttps://10.96.0.1:443 subsysk8s levelerror msgUnable to contact k8s api-server errorGet https://10.96.0.1:443/api/v1/namespaces/kube-system: dial tcp 10.96.0.1:443: connect: no route to host ipAddrhttps://10.96.0.1:443 subsysk8s levelfatal msgUnable to initialize Kubernetes subsystem errorunable to create k8s client: unable to create k8s client: Get https://10.96.0.1:443/api/v1/namespaces/kube-system: dial tcp 10.96.0.1:443: connect: no route to host subsysdaemon原因通常是Kind 节点是共享宿主机内核的 Docker 容器若 Socket LB 未正确禁用Cilium 挂载的 eBPF 程序可能已过期不再把对 API Server10.96.0.1:443的流量路由到当前的kind-control-plane容器。解决方案是重建 Kind 集群并重新执行 Cilium 安装步骤使 eBPF 程序重新挂载到正确的路径上。Cilium Agent Pod 持续崩溃若 Agent Pod 反复崩溃日志中出现levelwarning msg bpftool cgroup attach /var/run/cilium/cgroupv2 connect6 pinned /sys/fs/bpf/tc/globals/cilium_cgroups_connect6 subsysdatapath-loader levelwarning msgError: failed to attach program subsysdatapath-loader levelwarning msg RETCODE255 subsysdatapath-loader这通常意味着当前环境中已经运行着另一个 Cilium 实例例如在 Cilium 开发 VM 中或者在 kind 节点容器的父级 cgroup 层级上存在其他重叠的 BPF cgroup 类型程序。处理方式为先拆除已有 Cilium或使用bpftool cgroup手动分离父级 cgroup 层级上重叠的 BPF cgroup 程序后重试。下一步验证后的延展方向集群验证通过后官方指南Documentation/installation/next-steps.rst建议的后续方向包括配置与使用 Hubble 可观测性Documentation/observability/hubble-setup.rst 等文档、通过 Cilium CLI 操作 Hubble、部署 Hubble UI、基于 HTTP 的 L7 策略实践以及在多集群场景下使用 Cluster Mesh。值得一提的是Kind 集群也常被用来在沙箱环境中模拟 Cluster Mesh 多集群拓扑为每个集群单独创建 kind 配置显式设置互不重叠的podSubnet与serviceSubnet然后分别kind create cluster --namecluster1 --configkind-cluster1.yaml创建多个集群再按 Cluster Mesh 指南完成部署与连接相关配置示例见 Documentation/installation/kind.rst 的 Cluster Mesh 小节。这样即可在单台机器上完整体验跨集群的 Service 联邦与网络策略编排。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考