Cilium 使用外部 etcdKVStore安装与配置指南打破循环依赖、启用 TLS 与验证集群【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文基于 Cilium 官方安装指南k8s-install-external-etcd.rst完整讲解如何在 Kubernetes 集群中将 Cilium 的状态存储从 Kubernetes CRD 切换到外部 etcd 集群。你将掌握何时应该引入外部 KVStore、如何用 Helm 配置etcd.endpoints接入多节点 etcd、如何打破 Cilium 与 etcd 之间的循环依赖、如何为 etcd 连接启用 TLS 证书认证以及安装完成后如何用 Cilium CLI 和 kubectl 双重验证网络连通性。读完本文你可以直接复制文中命令在一套满足前置条件的集群上完成外部 etcd 模式的 Cilium 部署。何时需要使用外部 KVStore默认情况下参考快速安装流程Cilium 将节点、身份identity等状态存储在 Kubernetes CRD 中。但在以下三类场景中官方建议引入外部 KVStore如 etcd环境中的Kubernetes 事件导致状态同步开销过高——例如大量 Pod 频繁创建/销毁时CRD 模式下的状态传播会产生明显负载你不希望 Cilium 将状态存储在 Kubernetes CRD 中希望状态与 Kubernetes API Server 解耦集群的Pod 数、节点数超过官方可扩展性测试覆盖的规模参见文档中的 scalability guide需要更高性能的状态同步路径。使用外部 etcd 可以提供更好的性能适用于更大规模的集群环境。安装前置条件在开始之前请确认 Kubernetes 环境满足以下要求详见 requirements-intro.rstKubernetes 1.16Linux 内核 5.10或同等版本Kubernetes 运行在CNI 模式所有工作节点上均已挂载 eBPF 文件系统推荐在kube-controller-manager中启用 PodCIDR 分配--allocate-node-cidrs此外外部 etcd 版本要求为3.4.0 或更高。KVStore 与 Cilium 之间的循环依赖使用外部 KVStore 时最关键的问题是打破 Cilium 与 KVStore 之间的循环依赖如果 KVStoreetcdPod 运行在同一集群内并使用 Pod 网络那么 etcd 的数据面依赖 Cilium 提供的网络连通性而 Cilium 的状态存储身份分配、节点信息等又依赖 etcd两者互相等待形成循环依赖导致集群无法正常启动。官方给出两种推荐的破环方式将 KVStore 部署在集群外部或部署在独立管理的另一个集群中本文即采用外部 etcd天然满足此方案若必须将 KVStore 部署在同一集群内则给 KVStore Pod 指定hostNetwork: true使其直接使用宿主机网络绕过 Cilium 管理的 Pod 网络。用 Helm 配置 Cilium 接入外部 etcd1. 添加 Helm 仓库并获取 Chart首先按 k8s-install-download-release.rst 中的说明添加 Helm 仓库helm repo add cilium https://helm.cilium.io/Cilium Chart 也同时发布在OCI 注册表Quay.io 与 Docker Hub上无需任何额外配置可直接使用oci://URL 安装关于 Chart 签名校验与基于 digest 的安装方式可参考 k8s-install-helm.rst。2. 部署 Cilium Release启用 etcd 模式使用 Helm 安装 Cilium并通过--set参数启用 etcd 模式、指定外部 etcd 端点helm install cilium cilium/cilium \ --namespace kube-system \ --set etcd.enabledtrue \ --set etcd.endpoints[0]http://etcd-endpoint1:2379 \ --set etcd.endpoints[1]http://etcd-endpoint2:2379 \ --set etcd.endpoints[2]http://etcd-endpoint3:2379对应到 Helm Chart 的 values 结构见 values.yaml底层实际生效的是三个参数values 参数默认值含义etcd.enabledfalse为 agent 启用 etcd 模式置为true后才会生成 KVStore 相关配置etcd.endpoints[https://CHANGE-ME:2379]etcd 端点列表支持传入多个端点做高可用etcd.sslfalse是否启用 TLS/SSL 连接 etcd3. 生成的 ConfigMap 究竟做了什么从 Helm 模板源码可以看到当etcd.enabledtrue时cilium-configmap.yaml 会向cilium-configConfigMap 注入以下关键配置kvstore: etcd kvstore-opt: {etcd.config: /var/lib/etcd-config/etcd.config} etcd-config: |- --- endpoints: - http://etcd-endpoint1:2379 - http://etcd-endpoint2:2379 - http://etcd-endpoint3:2379其中kvstore指定后端类型为 etcdkvstore-opt指向挂载到 agent Pod 内的 etcd 配置文件路径etcd-config则包含实际的 etcd 端点列表。在 daemonset.yaml 中这些配置以etcd-config-path卷来自cilium-configConfigMap的形式挂载进 agent 容器供其读取。4. 可选将身份分配模式切换为 KVStoreCilium 的身份identity分配模式决定节点间如何共享身份信息。默认的crd模式把身份存储在 Kubernetes CRD 中如果你不希望 Cilium 在 CRD 中存储任何状态可以显式切换到kvstore模式helm install cilium cilium/cilium \ --namespace kube-system \ --set etcd.enabledtrue \ --set etcd.endpoints[0]http://etcd-endpoint1:2379 \ --set identityAllocationModekvstore从源码注释cilium-configmap.yaml可知identity-allocation-mode可选值为crd、kvstore、doublewrite-readkvstore/doublewrite-readcrd。Cilium 1.6 之前的版本只支持 kvstore 后端从旧版本升级的用户应当继续使用 kvstore 模式。doublewrite系列模式会同时写入 KVStore 与 CRD用于从 kvstore 模式无缝迁移到 crd 模式。可选为 etcd 连接配置 SSL 证书如果外部 etcd 启用了 TLS 双向认证需要完成以下两步1. 创建 Kubernetes Secret将 etcd 的根 CA 证书、客户端密钥与客户端证书打包为一个 Secretkubectl create secret generic -n kube-system cilium-etcd-secrets \ --from-fileetcd-client-ca.crtca.crt \ --from-fileetcd-client.keyclient.key \ --from-fileetcd-client.crtclient.crt2. 重新生成 Helm 模板启用 SSL调整 Helm 参数开启etcd.ssltrue并将端点协议从http改为httpshelm install cilium cilium/cilium \ --namespace kube-system \ --set etcd.enabledtrue \ --set etcd.ssltrue \ --set etcd.endpoints[0]https://etcd-endpoint1:2379 \ --set etcd.endpoints[1]https://etcd-endpoint2:2379 \ --set etcd.endpoints[2]https://etcd-endpoint3:2379从模板源码看启用etcd.ssl后会发生两件事cilium-configmap.yaml 会在etcd-config中追加三个 TLS 文件路径trusted-ca-file: /var/lib/etcd-secrets/etcd-client-ca.crt key-file: /var/lib/etcd-secrets/etcd-client.key cert-file: /var/lib/etcd-secrets/etcd-client.crtdaemonset.yaml 会新增etcd-secrets卷从cilium-etcd-secretsSecret 挂载证书文件defaultMode: 0400optional: trueagent 即可通过/var/lib/etcd-secrets/下的文件与 etcd 建立 mTLS 连接。验证安装安装完成后按照 k8s-install-validate.rst 提供两种方式验证。方式一使用 Cilium CLI安装 Cilium CLI参见 cli-download.rstLinux 下的安装命令为CILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) aarch64 ]; then CLI_ARCHarm64; 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}检查 Cilium 组件状态$ 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运行连通性测试参见 cli-connectivity-test.rst$ 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)注意连通性测试可能因 Pod 中打开文件数过多而部署失败。若遇到该错误请提高宿主机上的inotify资源限制。方式二手动使用 kubectl观察组件启动过程参见 kubectl-status.rst$ 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与cilium-operator最终应达到1/1 Running。部署 connectivity-check 验证 Pod 间连通性参见 kubectl-connectivity-test.rst。建议单独创建命名空间kubectl create ns cilium-test kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml它会部署一系列 Deployment覆盖有无 Service 负载均衡、多种 NetworkPolicy 组合等连通路径。Pod 名称即表示连通性变体readiness/liveness 探针状态表示测试成败$ 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注意如果部署在单节点集群上检查多节点功能的 Pod 会一直停留在Pending状态这是预期行为——这些 Pod 至少需要 2 个节点才能被调度。测试完成后清理命名空间kubectl delete ns cilium-test后续步骤外部 etcd 模式安装验证通过后可以根据需要继续深入以下能力详见 next-steps.rst启用 Hubble 可观测性hubble_setup、hubble_cli、hubble_ui获取流量与安全策略的可视化视图基于 HTTP 的七层策略实践gs_http多集群互联 ClusterMeshclustermesh在多个 Kubernetes 集群之间打通服务发现与网络安全策略。小结外部 etcd 模式是 Cilium 在超大规模集群下的推荐部署形态。本文的核心操作链路为确认前置条件 → 打破循环依赖 → Helm 注入etcd.endpoints→ 可选启用 TLS Secret 与identityAllocationModekvstore→ 用cilium status/cilium connectivity test或 kubectl 验证。通过 cilium-configmap.yaml 与 daemonset.yaml 的模板源码可以清楚看到etcd.enabled、etcd.ssl等参数最终如何转化为 agent 实际读取的 kvstore 配置与挂载卷这为排查 etcd 连接问题提供了明确的底层依据。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cilium 使用外部 etcd（KVStore）安装与配置指南：打破循环依赖、启用 TLS 与验证集群
Cilium 使用外部 etcdKVStore安装与配置指南打破循环依赖、启用 TLS 与验证集群【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文基于 Cilium 官方安装指南k8s-install-external-etcd.rst完整讲解如何在 Kubernetes 集群中将 Cilium 的状态存储从 Kubernetes CRD 切换到外部 etcd 集群。你将掌握何时应该引入外部 KVStore、如何用 Helm 配置etcd.endpoints接入多节点 etcd、如何打破 Cilium 与 etcd 之间的循环依赖、如何为 etcd 连接启用 TLS 证书认证以及安装完成后如何用 Cilium CLI 和 kubectl 双重验证网络连通性。读完本文你可以直接复制文中命令在一套满足前置条件的集群上完成外部 etcd 模式的 Cilium 部署。何时需要使用外部 KVStore默认情况下参考快速安装流程Cilium 将节点、身份identity等状态存储在 Kubernetes CRD 中。但在以下三类场景中官方建议引入外部 KVStore如 etcd环境中的Kubernetes 事件导致状态同步开销过高——例如大量 Pod 频繁创建/销毁时CRD 模式下的状态传播会产生明显负载你不希望 Cilium 将状态存储在 Kubernetes CRD 中希望状态与 Kubernetes API Server 解耦集群的Pod 数、节点数超过官方可扩展性测试覆盖的规模参见文档中的 scalability guide需要更高性能的状态同步路径。使用外部 etcd 可以提供更好的性能适用于更大规模的集群环境。安装前置条件在开始之前请确认 Kubernetes 环境满足以下要求详见 requirements-intro.rstKubernetes 1.16Linux 内核 5.10或同等版本Kubernetes 运行在CNI 模式所有工作节点上均已挂载 eBPF 文件系统推荐在kube-controller-manager中启用 PodCIDR 分配--allocate-node-cidrs此外外部 etcd 版本要求为3.4.0 或更高。KVStore 与 Cilium 之间的循环依赖使用外部 KVStore 时最关键的问题是打破 Cilium 与 KVStore 之间的循环依赖如果 KVStoreetcdPod 运行在同一集群内并使用 Pod 网络那么 etcd 的数据面依赖 Cilium 提供的网络连通性而 Cilium 的状态存储身份分配、节点信息等又依赖 etcd两者互相等待形成循环依赖导致集群无法正常启动。官方给出两种推荐的破环方式将 KVStore 部署在集群外部或部署在独立管理的另一个集群中本文即采用外部 etcd天然满足此方案若必须将 KVStore 部署在同一集群内则给 KVStore Pod 指定hostNetwork: true使其直接使用宿主机网络绕过 Cilium 管理的 Pod 网络。用 Helm 配置 Cilium 接入外部 etcd1. 添加 Helm 仓库并获取 Chart首先按 k8s-install-download-release.rst 中的说明添加 Helm 仓库helm repo add cilium https://helm.cilium.io/Cilium Chart 也同时发布在OCI 注册表Quay.io 与 Docker Hub上无需任何额外配置可直接使用oci://URL 安装关于 Chart 签名校验与基于 digest 的安装方式可参考 k8s-install-helm.rst。2. 部署 Cilium Release启用 etcd 模式使用 Helm 安装 Cilium并通过--set参数启用 etcd 模式、指定外部 etcd 端点helm install cilium cilium/cilium \ --namespace kube-system \ --set etcd.enabledtrue \ --set etcd.endpoints[0]http://etcd-endpoint1:2379 \ --set etcd.endpoints[1]http://etcd-endpoint2:2379 \ --set etcd.endpoints[2]http://etcd-endpoint3:2379对应到 Helm Chart 的 values 结构见 values.yaml底层实际生效的是三个参数values 参数默认值含义etcd.enabledfalse为 agent 启用 etcd 模式置为true后才会生成 KVStore 相关配置etcd.endpoints[https://CHANGE-ME:2379]etcd 端点列表支持传入多个端点做高可用etcd.sslfalse是否启用 TLS/SSL 连接 etcd3. 生成的 ConfigMap 究竟做了什么从 Helm 模板源码可以看到当etcd.enabledtrue时cilium-configmap.yaml 会向cilium-configConfigMap 注入以下关键配置kvstore: etcd kvstore-opt: {etcd.config: /var/lib/etcd-config/etcd.config} etcd-config: |- --- endpoints: - http://etcd-endpoint1:2379 - http://etcd-endpoint2:2379 - http://etcd-endpoint3:2379其中kvstore指定后端类型为 etcdkvstore-opt指向挂载到 agent Pod 内的 etcd 配置文件路径etcd-config则包含实际的 etcd 端点列表。在 daemonset.yaml 中这些配置以etcd-config-path卷来自cilium-configConfigMap的形式挂载进 agent 容器供其读取。4. 可选将身份分配模式切换为 KVStoreCilium 的身份identity分配模式决定节点间如何共享身份信息。默认的crd模式把身份存储在 Kubernetes CRD 中如果你不希望 Cilium 在 CRD 中存储任何状态可以显式切换到kvstore模式helm install cilium cilium/cilium \ --namespace kube-system \ --set etcd.enabledtrue \ --set etcd.endpoints[0]http://etcd-endpoint1:2379 \ --set identityAllocationModekvstore从源码注释cilium-configmap.yaml可知identity-allocation-mode可选值为crd、kvstore、doublewrite-readkvstore/doublewrite-readcrd。Cilium 1.6 之前的版本只支持 kvstore 后端从旧版本升级的用户应当继续使用 kvstore 模式。doublewrite系列模式会同时写入 KVStore 与 CRD用于从 kvstore 模式无缝迁移到 crd 模式。可选为 etcd 连接配置 SSL 证书如果外部 etcd 启用了 TLS 双向认证需要完成以下两步1. 创建 Kubernetes Secret将 etcd 的根 CA 证书、客户端密钥与客户端证书打包为一个 Secretkubectl create secret generic -n kube-system cilium-etcd-secrets \ --from-fileetcd-client-ca.crtca.crt \ --from-fileetcd-client.keyclient.key \ --from-fileetcd-client.crtclient.crt2. 重新生成 Helm 模板启用 SSL调整 Helm 参数开启etcd.ssltrue并将端点协议从http改为httpshelm install cilium cilium/cilium \ --namespace kube-system \ --set etcd.enabledtrue \ --set etcd.ssltrue \ --set etcd.endpoints[0]https://etcd-endpoint1:2379 \ --set etcd.endpoints[1]https://etcd-endpoint2:2379 \ --set etcd.endpoints[2]https://etcd-endpoint3:2379从模板源码看启用etcd.ssl后会发生两件事cilium-configmap.yaml 会在etcd-config中追加三个 TLS 文件路径trusted-ca-file: /var/lib/etcd-secrets/etcd-client-ca.crt key-file: /var/lib/etcd-secrets/etcd-client.key cert-file: /var/lib/etcd-secrets/etcd-client.crtdaemonset.yaml 会新增etcd-secrets卷从cilium-etcd-secretsSecret 挂载证书文件defaultMode: 0400optional: trueagent 即可通过/var/lib/etcd-secrets/下的文件与 etcd 建立 mTLS 连接。验证安装安装完成后按照 k8s-install-validate.rst 提供两种方式验证。方式一使用 Cilium CLI安装 Cilium CLI参见 cli-download.rstLinux 下的安装命令为CILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) aarch64 ]; then CLI_ARCHarm64; 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}检查 Cilium 组件状态$ 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运行连通性测试参见 cli-connectivity-test.rst$ 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)注意连通性测试可能因 Pod 中打开文件数过多而部署失败。若遇到该错误请提高宿主机上的inotify资源限制。方式二手动使用 kubectl观察组件启动过程参见 kubectl-status.rst$ 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与cilium-operator最终应达到1/1 Running。部署 connectivity-check 验证 Pod 间连通性参见 kubectl-connectivity-test.rst。建议单独创建命名空间kubectl create ns cilium-test kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml它会部署一系列 Deployment覆盖有无 Service 负载均衡、多种 NetworkPolicy 组合等连通路径。Pod 名称即表示连通性变体readiness/liveness 探针状态表示测试成败$ 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注意如果部署在单节点集群上检查多节点功能的 Pod 会一直停留在Pending状态这是预期行为——这些 Pod 至少需要 2 个节点才能被调度。测试完成后清理命名空间kubectl delete ns cilium-test后续步骤外部 etcd 模式安装验证通过后可以根据需要继续深入以下能力详见 next-steps.rst启用 Hubble 可观测性hubble_setup、hubble_cli、hubble_ui获取流量与安全策略的可视化视图基于 HTTP 的七层策略实践gs_http多集群互联 ClusterMeshclustermesh在多个 Kubernetes 集群之间打通服务发现与网络安全策略。小结外部 etcd 模式是 Cilium 在超大规模集群下的推荐部署形态。本文的核心操作链路为确认前置条件 → 打破循环依赖 → Helm 注入etcd.endpoints→ 可选启用 TLS Secret 与identityAllocationModekvstore→ 用cilium status/cilium connectivity test或 kubectl 验证。通过 cilium-configmap.yaml 与 daemonset.yaml 的模板源码可以清楚看到etcd.enabled、etcd.ssl等参数最终如何转化为 agent 实际读取的 kvstore 配置与挂载卷这为排查 etcd 连接问题提供了明确的底层依据。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考