Cilium L7 流量管理基于 CiliumEnvoyConfig CRD 的 Envoy 代理配置实战指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇围绕 Cilium 的 L7 感知流量管理能力展开Cilium 通过在 Cilium Agent 内置的 Envoy 代理上开放CiliumEnvoyConfig/CiliumClusterwideEnvoyConfig两类 CRD让运维人员可以直接以 Envoy xDS 资源Listener、RouteConfiguration、Cluster的形式改写七层流量行为。读完本文你将掌握该能力的启用方式Helm / Cilium CLI、适用前提、必须遵守的配置约束尤其是cec.cilium.io/use-original-source-address注解并完整复刻五个官方示例——L7 路径重写、加权负载均衡、URL 改写、熔断、流量灰度迁移——同时理解这些 CRD 在 pkg/ciliumenvoyconfig 源码中的解析、冲突检测与 xDS 下发链路。一、能力概述Cilium 如何用 CRD 控制 L7 流量Cilium 提供了通过 CRD 控制七层L7流量的方式官方文档见 L7-Aware Traffic Management。核心机制是每个 Cilium Agent 节点上运行一个为 Cilium 定制的 Envoy 实例负责 HTTP 策略执行与可观测性用户通过CiliumEnvoyConfigCEC命名空间级或CiliumClusterwideEnvoyConfigCCEC集群级提交标准 Envoy v3 API 资源spec.resources中一组带type的google.protobuf.Any消息Cilium Agent 解析这些资源合并进节点本地 Envoy 的 xDS 配置快照并下发从而改变流量走向。典型用途包括场景对应官方示例文档L7 路径重写 / 自定义 ListenerPrometheus 指标端口L7 Path Translation多后端加权负载均衡 URL 重写L7 Load Balancing and URL re-writing熔断circuit breaking与异常节点剔除L7 Circuit BreakinggRPC 等场景的 Service 级代理负载均衡betaProxy Load Balancing for Kubernetes Services按权重灰度切流v1 90% / v2 10%L7 Traffic Shifting二、前置条件与启用方式2.1 硬性前提kube-proxy replacement官方文档明确Cilium 必须以 kube-proxy 替换模式运行即kubeProxyReplacementtrue。这是因为 L7 流量管理依赖 Envoy 通过 EDSEndpoint Discovery Service直接获取 Service 的后端端点只有 Cilium 自身承担了 Service 数据面才能把上游端点动态推送给 Envoy。2.2 启用方式安装步骤在 installation.rst 中给出两条路径二者都要求先确认cilium status正常Helm 方式# 启用 Cilium Ingress Controller同时启用 Envoy 流量管理基础设施 helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \ --set ingressController.enabledtrue \ --set ingressController.loadbalancerModededicated kubectl -n kube-system rollout restart deployment/cilium-operator kubectl -n kube-system rollout restart ds/cilium # 若只需要 Envoy 流量管理功能、不使用 Ingress 支持则只需开启 helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \ --set envoyConfig.enabledtrue kubectl -n kube-system rollout restart deployment/cilium-operator kubectl -n kube-system rollout restart ds/cilium # 可选Service 级代理负载均衡见第五节 helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \ --set loadBalancer.l7.backendenvoy kubectl -n kube-system rollout restart deployment/cilium-operator kubectl -n kube-system rollout restart ds/ciliumCilium 还可以通过--set ingressController.defaulttrue成为默认 Ingress Controller此时即使ingressClass未设置也会创建 ingress 条目。Cilium CLI 方式# 启用 Ingress Controller cilium install --version chart-version \ --set kubeProxyReplacementtrue \ --set ingressController.enabledtrue \ --set ingressController.loadbalancerModededicated # 仅启用 Envoy 流量管理 cilium install --version chart-version \ --set kubeProxyReplacementtrue \ --set envoyConfig.enabledtrue # 加上 Service 级代理负载均衡 cilium install --version chart-version \ --set kubeProxyReplacementtrue \ --set envoyConfig.enabledtrue \ --set loadBalancer.l7.backendenvoy文档同时建议安装 Hubble CLI后续验证流量都会用到hubble observe。三、Envoy API 版本与扩展资源类型官方文档对可写入 CRD 的资源范围有明确约定仅支持 Envoy API v3。所有spec.resources条目必须是 v3 类型的Any消息例如type.googleapis.com/envoy.config.listener.v3.Listenertype.googleapis.com/envoy.config.route.v3.RouteConfigurationtype.googleapis.com/envoy.config.cluster.v3.Cluster这类 Envoy 官方文档中常见的标准资源类型始终可用。Cilium 定制的 Envoy 镜像是裁剪构建。Cilium 节点部署的 Envoy 镜像针对 Cilium Agent 的 HTTP 策略执行与可观测性需求做了优化不包含 Envoy 代码库中的大部分扩展。可用扩展的完整清单以 Cilium 维护的 proxy 构建配置extensions_build_config.bzl为准其中未被#注释掉的扩展才会编入 Cilium Envoy 镜像。因此编写 CEC 时若引用了某个 filter 或 cluster 扩展需先确认它存在于该构建中否则节点本地 Envoy 会拒绝加载。四、必须知道的限制与约束Caveats这是原档中最容易被忽视、也最容易在生产环境踩坑的部分逐条说明校验极其有限、无冲突消解语义。多个 CEC 若修改了 Envoy 配置的同一部分结果不可预测。kubectl apply对 Envoy 资源不做任何 K8s 层面校验——即使节点本地 Envoy 解析或安装该资源失败了apply 也会报告成功。目前唯一可靠的验证手段是观察 Cilium Agent 日志中的错误与告警Agent 会对集群内冲突的 Envoy 资源打印 warning。官方给出的排查命令kubectl logs -n kube-system ds/cilium | grep -E level(error|warning)配置正确性反馈很少。CEC 产生非预期行为时需要直接检查节点 Envoy 的实际配置和日志来排障而不能只看 CEC 本身。两类 CRD 属于集群管理员资源。它们应被视为实现细节implementation details不应把配置权限下放给其他用户。与自动生成的 Ingress / Gateway API 配置隔离。Cilium 的 Ingress 和 Gateway API 控制器也会使用 CEC 来把流量导向各节点的 Envoy 代理如果你的手写 CEC 与之冲突或改动了自动生成的配置结果不可预测。Cilium 的做法是保证自身生成的配置尽可能语义有效但用户侧仍需格外小心。E/W东西向流量的use-original-source-address注解。若你直接创建 CEC而非经由 Cilium Ingress / Gateway API 控制器来管理东西向流量必须设置注解cec.cilium.io/use-original-source-address: false。否则 Envoy 会把上游连接池的 socket 绑定到原始源地址/端口当 Pod 在同一条流水线式 HTTP/1.1 或 HTTP/2 连接上发送多个请求时可能引发 5 元组冲突。这条规则在源码中体现为 UseOriginalSourceAddress 的判定逻辑可以精确复现文档描述的行为若对象存在OwnerReference且 Kind 为Ingress或Gateway直接返回false即 Cilium Ingress / Gateway API 控制器生成的 CEC 默认不使用原始源地址否则读取注解cec.cilium.io/use-original-source-addressstrconv.ParseBool解析注解缺失时回退到已弃用的同名 label两者都没有时默认返回true——这正是文档所说其他所有 CEC 都被视为true的出处。解析结果最终写入 listener 的UseOriginalSourceAddress字段见 cec_resource_parser.go#L626。五、CRD 结构解剖一个完整的 CCEC 长什么样以官方示例 envoy-traffic-management-test.yaml 为例该文件定义了一个CiliumClusterwideEnvoyConfigapiVersion: cilium.io/v2 kind: CiliumClusterwideEnvoyConfig metadata: name: envoy-lb-listener spec: services: - name: echo-service-1 namespace: default - name: echo-service-2 namespace: default resources: # 1) ListenerHTTP 连接管理器 路由器过滤器 - type: type.googleapis.com/envoy.config.listener.v3.Listener name: envoy-lb-listener filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: envoy-lb-listener rds: route_config_name: lb_route use_remote_address: true skip_xff_append: true http_filters: - name: envoy.filters.http.router typed_config: type: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router # 2) RouteConfiguration50/50 加权集群 重试策略 正则 URL 重写 - type: type.googleapis.com/envoy.config.route.v3.RouteConfiguration name: lb_route virtual_hosts: - name: lb_route domains: [ * ] routes: - match: prefix: / route: weighted_clusters: clusters: - name: default/echo-service-1 weight: 50 - name: default/echo-service-2 weight: 50 retry_policy: retry_on: 5xx num_retries: 3 per_try_timeout: 1s regex_rewrite: pattern: google_re2: { } regex: ^/foo.*$ substitution: / # 3) 两个 EDS 类型的 Cluster端点由 Cilium 通过 EDS 动态下发 - type: type.googleapis.com/envoy.config.cluster.v3.Cluster name: default/echo-service-1 connect_timeout: 5s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 - type: type.googleapis.com/envoy.config.cluster.v3.Cluster name: default/echo-service-2 connect_timeout: 3s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2三个关键结构点spec.services声明该配置关联的 Kubernetes Service。集群资源type: EDS、lb_policy: ROUND_ROBIN与这些 Service 的端点绑定只要存在spec.servicesCilium 就会自动向非内部 Listener 注入 Cilium 的 Envoy network/L7 过滤器——这一点由 InjectCiliumEnvoyFilters 实现注解cec.cilium.io/inject-cilium-filters可显式覆盖否则回退为len(spec.Services) 0。spec.resources一组google.protobuf.Any包装的 Envoy v3 消息可混合包含 Listener / RouteConfiguration / Cluster彼此通过名称引用如上例中rds.route_config_name: lb_route、weighted_clusters中的default/echo-service-1。命名空间级 CECCiliumEnvoyConfig结构与 CCEC 相同只是作用域限定在 metadata 所在命名空间CCEC 是集群级资源metadata.name必须在集群内唯一除非你想整体替换同名资源。六、示例一L7 路径重写与自定义 ListenerPrometheus 指标端口L7 Path Translation 示例复刻了--proxy-prometheus-port命令行选项已有的功能——在每个 Cilium 节点上向端口9090暴露一个 Envoy Listener把默认 Prometheus 抓取路径/metrics翻译成 Envoy 的 Prometheus 指标路径/stats/prometheus。示例的意义在于演示过去需要改 Cilium Agent 代码才能实现的能力现在只需一个 CRD。操作步骤# 应用示例 CRDCiliumClusterwideEnvoyConfig集群级资源名称集群内唯一 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-prometheus-metrics-listener.yaml # 验证节点端口是否响应指标请求 curl http://node-IP:9090/metrics对应仓库文件为 envoy-prometheus-metrics-listener.yaml。清理kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-prometheus-metrics-listener.yaml七、示例二多后端负载均衡 URL 重写 L7 策略叠加这是最能说明 CEC 与 Cilium 网络策略如何协同的示例envoy-traffic-management.rst。流量行为对发往echo-service-1或echo-service-2的流量按50/50在两个后端之间负载均衡把路径/foo重写为/使原本 404 的请求成功未重写成功的非/路径仍被 L7 网络策略拒绝403 Forbidden。步骤 1部署测试应用kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application.yaml kubectl get pods --show-labels -o wide测试负载包含两个客户端 Deploymentclient、client2和两个服务echo-service-1、echo-service-2。注意只有client2带有otherclient标签供后续 CiliumNetworkPolicy 选择器使用export CLIENT2$(kubectl get pods -l nameclient2 -o jsonpath{.items[0].metadata.name})步骤 2Hubble 观察基线流量kubectl -n kube-system port-forward deployment/hubble-relay 4245:4245 hubble observe --from-pod $CLIENT2 -f此时分别请求两个后端都能成功kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/ kubectl exec -it $CLIENT2 -- curl -v echo-service-2:8080/Hubble 中这些流都是to/from-stack、to/from-overlay或to/from-endpoint——还没有流量经过代理前提是集群中没有其他 L7 策略影响该流量。请求不存在的 URL 会 404kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/foo步骤 3加入 L7 策略Envoy 进入转发路径kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/client-egress-l7-http.yaml kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/client-egress-only-dns.yaml kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/加入 L7 策略后 Envoy 被引入路径Hubble 输出出现to-proxy流并显示七层 HTTP 信息例如HTTP/1.1 GET http://echo-service-1:8080/。注意Envoy 可能会对某些 HTTP 头做 sanitize清洗。若需要 Envoy 信任上一跳、避免改写特定头部可通过 Helm 值envoy.xffNumTrustedHopsL7PolicyIngress与envoy.xffNumTrustedHopsL7PolicyEgress设置信任跳数。对出口策略而言上一跳就是源 Pod对入口策略而言上一跳可能是源 Pod、L7 策略透明代理、Cilium Ingress Controller、Cilium Gateway API 或其他 Ingress 代理/基础设施。信任上一跳属于安全敏感配置需结合环境评估。步骤 4验证策略强制403策略只放行 GET/其他 URL 的包被丢弃并返回 403。Hubble 中可见类似Jul 7 08:40:15.076: default/client2-8b4c4fd75-6pgvl:58586 - default/echo-service-1-97748874-n7758:8080 http-request DROPPED (HTTP/1.1 GET http://echo-service-1:8080/foo)步骤 5应用 CCEC启用负载均衡与 URL 重写kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-traffic-management-test.yaml # /foo 现在成功被重写为 / kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/foo # /bar 依然被策略拒绝未被重写Hubble 显示 DROPPED kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/bar多次请求同一后端时Hubble 输出约一半的流量会被另一个后端处理——这正是 50/50weighted_clusters的效果例如Jul 7 08:45:25.808: default/client2-8b4c4fd75-6pgvl:57942 - default/echo-service-1:8080 to-proxy FORWARDED (TCP Flags: SYN) Jul 7 08:45:25.809: default/client2-8b4c4fd75-6pgvl:57942 - default/echo-service-2-76c584c4bf-874dm:8080 to-endpoint FORWARDED (TCP Flags: SYN) Jul 7 08:45:25.809: default/client2-8b4c4fd75-6pgvl:57942 - default/echo-service-2-76c584c4bf-874dm:8080 http-request FORWARDED (HTTP/1.1 GET http://echo-service-1:8080/)可以看到同一个源端口57942的 TCP 连接先到echo-service-1to-proxy再由 Envoy 转到echo-service-2to-endpoint——即客户端连接服务 1但约一半请求实际由服务 2 处理。八、示例三熔断Circuit Breaking与异常节点剔除L7 Circuit Breaking 演示如何用 CCEC 配置连接/并发上限并故意触发熔断器。对应资源文件 envoy-circuit-breaker.yaml 的核心 Cluster 片段- type: type.googleapis.com/envoy.config.cluster.v3.Cluster name: default/echo-service connect_timeout: 5s lb_policy: ROUND_ROBIN type: EDS edsClusterConfig: serviceName: default/echo-service circuit_breakers: thresholds: - priority: DEFAULT max_requests: 2 max_pending_requests: 1 outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2max_pending_requests: 1与max_requests: 2意味着并发连接/请求一旦超过该阈值Envoy 就对后续请求打开熔断直接失败。验证流程# 部署测试应用fortio 压测客户端 echo-service kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application-proxy-circuit-breaker.yaml # 应用熔断配置 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-circuit-breaker.yaml kubectl get ccec envoy-circuit-breaker -oyaml # 2 并发、20 次请求个别请求收到 503Code 200 : 19 / Code 503 : 1 export FORTIO_POD$(kubectl get pods -l appfortio -o jsonpath{.items[0].metadata.name}) kubectl exec $FORTIO_POD -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 http://echo-service:8080 # 4 并发、20 次请求熔断明显Code 200 : 7 / Code 503 : 13 kubectl exec $FORTIO_POD -c fortio -- /usr/bin/fortio load -c 4 -qps 0 -n 20 http://echo-service:8080并发提升到 4 时20 次请求中仅 35% 成功其余被熔断为 503——这正是阈值设置生效的表现。配置中同时启用了outlier_detectionconsecutive_local_origin_failure: 2连续 2 次本地发起失败的后端节点会被暂时剔除。清理kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-circuit-breaker.yaml kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application-proxy-circuit-breaker.yaml九、示例四按权重灰度切流90/10 Traffic ShiftingL7 Traffic Shifting 演示把发往helloworldService 的流量按 90% →helloworld-v1、10% →helloworld-v2分配。要点是先为每个后端 Deployment 建立独立的 Service再用命名空间级CiliumEnvoyConfig做加权路由对应文件 envoy-helloworld-v1-90-v2-10.yaml。# 1) 部署客户端与两个版本的服务端 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/client-helloworld.yaml export CLIENT$(kubectl get pods -l nameclient -o jsonpath{.items[0].metadata.name}) # 基线未加配置时约 50/50 for i in {1..10}; do kubectl exec -it $CLIENT -- curl helloworld:5000/hello; done # 2) 为每个后端建立独立 Service kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/helloworld-service-v1-v2.yaml # 3) 应用 90/10 加权路由CiliumEnvoyConfig kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-helloworld-v1-90-v2-10.yaml # 4) 再次压测约 90% 响应来自 v1、10% 来自 v2 for i in {1..10}; do kubectl exec -it $CLIENT -- curl helloworld:5000/hello; done清理时删除 CEC 与测试应用两个 YAML 即可恢复原状。十、示例五Service 级代理负载均衡betaProxy Load Balancing for Kubernetes Services 是独立于 Ingress 的特性对某个 Kubernetes Service 打标后发往该 Service 的流量会被重定向到 Cilium 管理的 Envoy 代理做负载均衡适合 gRPC 等需要 L7 感知的 LB 场景。# 部署测试应用client 两个后端 Pod 的 echo-service kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application-proxy-loadbalancing.yaml CLIENT$(kubectl get pods -l nameclient -o jsonpath{.items[0].metadata.name}) # Hubble 观察服务流量 kubectl -n kube-system port-forward deployment/hubble-relay 4245:4245 hubble observe --service echo-service -f kubectl exec -it $CLIENT -- curl -v echo-service:8080/ # 给 Service 加 L7 负载均衡注解Envoy 进入转发路径 kubectl annotate service echo-service service.cilium.io/lb-l7enabled kubectl exec -it $CLIENT -- curl -v echo-service:8080/注解后 Hubble 输出由 L3-L4 的pre-xlate-fwd/post-xlate-rev变为to-proxy FORWARDED→to-endpoint FORWARDED说明流量已经经过 Envoy 再到达后端。支持的 Service 注解默认值遵循 Helm 配置注解说明可取值默认值service.cilium.io/lb-l7为该 Service 启用 L7 负载均衡enabled、disableddisabledservice.cilium.io/lb-l7-algorithm使用的 LB 算法round_robin、least_request、randomHelm 值loadBalancer.l7.algorithm十一、源码纵深CEC 从 apply 到 xDS 的下发链路结合仓库源码可以理清一条完整调用链位于 pkg/ciliumenvoyconfigK8s 反射k8s_reflector.go 监听两类 CRD 的增删改写入 statedb 中的 CEC 表解析cec_resource_parser.go 的ParseResources把spec.resources反序列化为 Envoy v3 消息并按UseOriginalSourceAddress第三节注解逻辑与InjectCiliumEnvoyFiltersspec.services非空时自动注入 Cilium 过滤器计算 listener 行为端口分配与资源落表newPortAllocator复用proxyports.ProxyPorts为每个需要监听端口的 CEC 分配节点本地端口解析产物进入EnvoyResources表对账与下发reconciler.go 中envoyOps.Initializer先等待资源表初始化再用当前快照 seed xDS cache保证 Envoy xDS server 启动时即持有最新配置随后注册 statedb reconciler按EnvoyConfigRetryInterval周期重试解析失败或资源冲突即体现为 Cilium Agent 日志中的 error/warning——这与第四节apply 必然成功、需看 Agent 日志的约束完全对应。从源码结构看冲突检测发生在资源表合并与重复 filter chain 校验层面参见 duplicate_filter_chain_test.go 与 main_test.go 中的冲突场景测试因此官方文档多个 CEC 修改同一部分结果不可预测的警告并非虚言系统会告警但不会替你仲裁。十二、排障清单综合以上各节日常操作建议遵循apply 之后永远看 Agent 日志kubectl logs -n kube-system ds/cilium | grep -E level(error|warning)——这是验证 Envoy 资源是否被成功安装的唯一可靠途径东西向 CEC 记得加注解cec.cilium.io/use-original-source-address: false避免 5 元组冲突不要触碰 Ingress / Gateway API 控制器自动生成的 CEC手写 CEC 与其共存时检查 Agent 日志确认无冲突引用扩展前先确认其存在于 Cilium 定制 Envoy 构建否则节点本地 Envoy 会拒绝加载该配置用 Hubble 观察流量路径变化to-proxy出现即表示 Envoy 已介入DROPPED (HTTP/1.1 GET ...)表示 L7 策略拦截二者是验证 CEC 与策略协同是否生效的最直接信号。小结Cilium 的 L7 流量管理把 Envoy 的控制能力以 CRD 形式暴露给集群CiliumEnvoyConfig/CiliumClusterwideEnvoyConfig承载标准 Envoy v3 资源覆盖路径重写、加权负载均衡、URL 改写、熔断、灰度切流与 Service 级代理 LB 等典型场景。其设计取舍也很明确——校验与冲突消解被有意保持到最薄换取配置的完全自由度代价是配置正确性验证必须依赖 Cilium Agent 日志与 Hubble 流量观察且这两类 CRD 应严格作为集群管理员资源使用。理解了use-original-source-address、spec.services与注入过滤器的联动源码见 pkg/ciliumenvoyconfig/cec_resource_parser.go以及 reconcile 到 xDS 的下发链路后你就具备了在生产集群中安全使用这一能力并独立排障的全部要素。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cilium L7 流量管理基于 CiliumEnvoyConfig CRD 的 Envoy 代理配置实战指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇围绕 Cilium 的 L7 感知流量管理能力展开Cilium 通过在 Cilium Agent 内置的 Envoy 代理上开放CiliumEnvoyConfig/CiliumClusterwideEnvoyConfig两类 CRD让运维人员可以直接以 Envoy xDS 资源Listener、RouteConfiguration、Cluster的形式改写七层流量行为。读完本文你将掌握该能力的启用方式Helm / Cilium CLI、适用前提、必须遵守的配置约束尤其是cec.cilium.io/use-original-source-address注解并完整复刻五个官方示例——L7 路径重写、加权负载均衡、URL 改写、熔断、流量灰度迁移——同时理解这些 CRD 在 pkg/ciliumenvoyconfig 源码中的解析、冲突检测与 xDS 下发链路。一、能力概述Cilium 如何用 CRD 控制 L7 流量Cilium 提供了通过 CRD 控制七层L7流量的方式官方文档见 L7-Aware Traffic Management。核心机制是每个 Cilium Agent 节点上运行一个为 Cilium 定制的 Envoy 实例负责 HTTP 策略执行与可观测性用户通过CiliumEnvoyConfigCEC命名空间级或CiliumClusterwideEnvoyConfigCCEC集群级提交标准 Envoy v3 API 资源spec.resources中一组带type的google.protobuf.Any消息Cilium Agent 解析这些资源合并进节点本地 Envoy 的 xDS 配置快照并下发从而改变流量走向。典型用途包括场景对应官方示例文档L7 路径重写 / 自定义 ListenerPrometheus 指标端口L7 Path Translation多后端加权负载均衡 URL 重写L7 Load Balancing and URL re-writing熔断circuit breaking与异常节点剔除L7 Circuit BreakinggRPC 等场景的 Service 级代理负载均衡betaProxy Load Balancing for Kubernetes Services按权重灰度切流v1 90% / v2 10%L7 Traffic Shifting二、前置条件与启用方式2.1 硬性前提kube-proxy replacement官方文档明确Cilium 必须以 kube-proxy 替换模式运行即kubeProxyReplacementtrue。这是因为 L7 流量管理依赖 Envoy 通过 EDSEndpoint Discovery Service直接获取 Service 的后端端点只有 Cilium 自身承担了 Service 数据面才能把上游端点动态推送给 Envoy。2.2 启用方式安装步骤在 installation.rst 中给出两条路径二者都要求先确认cilium status正常Helm 方式# 启用 Cilium Ingress Controller同时启用 Envoy 流量管理基础设施 helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \ --set ingressController.enabledtrue \ --set ingressController.loadbalancerModededicated kubectl -n kube-system rollout restart deployment/cilium-operator kubectl -n kube-system rollout restart ds/cilium # 若只需要 Envoy 流量管理功能、不使用 Ingress 支持则只需开启 helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \ --set envoyConfig.enabledtrue kubectl -n kube-system rollout restart deployment/cilium-operator kubectl -n kube-system rollout restart ds/cilium # 可选Service 级代理负载均衡见第五节 helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \ --set loadBalancer.l7.backendenvoy kubectl -n kube-system rollout restart deployment/cilium-operator kubectl -n kube-system rollout restart ds/ciliumCilium 还可以通过--set ingressController.defaulttrue成为默认 Ingress Controller此时即使ingressClass未设置也会创建 ingress 条目。Cilium CLI 方式# 启用 Ingress Controller cilium install --version chart-version \ --set kubeProxyReplacementtrue \ --set ingressController.enabledtrue \ --set ingressController.loadbalancerModededicated # 仅启用 Envoy 流量管理 cilium install --version chart-version \ --set kubeProxyReplacementtrue \ --set envoyConfig.enabledtrue # 加上 Service 级代理负载均衡 cilium install --version chart-version \ --set kubeProxyReplacementtrue \ --set envoyConfig.enabledtrue \ --set loadBalancer.l7.backendenvoy文档同时建议安装 Hubble CLI后续验证流量都会用到hubble observe。三、Envoy API 版本与扩展资源类型官方文档对可写入 CRD 的资源范围有明确约定仅支持 Envoy API v3。所有spec.resources条目必须是 v3 类型的Any消息例如type.googleapis.com/envoy.config.listener.v3.Listenertype.googleapis.com/envoy.config.route.v3.RouteConfigurationtype.googleapis.com/envoy.config.cluster.v3.Cluster这类 Envoy 官方文档中常见的标准资源类型始终可用。Cilium 定制的 Envoy 镜像是裁剪构建。Cilium 节点部署的 Envoy 镜像针对 Cilium Agent 的 HTTP 策略执行与可观测性需求做了优化不包含 Envoy 代码库中的大部分扩展。可用扩展的完整清单以 Cilium 维护的 proxy 构建配置extensions_build_config.bzl为准其中未被#注释掉的扩展才会编入 Cilium Envoy 镜像。因此编写 CEC 时若引用了某个 filter 或 cluster 扩展需先确认它存在于该构建中否则节点本地 Envoy 会拒绝加载。四、必须知道的限制与约束Caveats这是原档中最容易被忽视、也最容易在生产环境踩坑的部分逐条说明校验极其有限、无冲突消解语义。多个 CEC 若修改了 Envoy 配置的同一部分结果不可预测。kubectl apply对 Envoy 资源不做任何 K8s 层面校验——即使节点本地 Envoy 解析或安装该资源失败了apply 也会报告成功。目前唯一可靠的验证手段是观察 Cilium Agent 日志中的错误与告警Agent 会对集群内冲突的 Envoy 资源打印 warning。官方给出的排查命令kubectl logs -n kube-system ds/cilium | grep -E level(error|warning)配置正确性反馈很少。CEC 产生非预期行为时需要直接检查节点 Envoy 的实际配置和日志来排障而不能只看 CEC 本身。两类 CRD 属于集群管理员资源。它们应被视为实现细节implementation details不应把配置权限下放给其他用户。与自动生成的 Ingress / Gateway API 配置隔离。Cilium 的 Ingress 和 Gateway API 控制器也会使用 CEC 来把流量导向各节点的 Envoy 代理如果你的手写 CEC 与之冲突或改动了自动生成的配置结果不可预测。Cilium 的做法是保证自身生成的配置尽可能语义有效但用户侧仍需格外小心。E/W东西向流量的use-original-source-address注解。若你直接创建 CEC而非经由 Cilium Ingress / Gateway API 控制器来管理东西向流量必须设置注解cec.cilium.io/use-original-source-address: false。否则 Envoy 会把上游连接池的 socket 绑定到原始源地址/端口当 Pod 在同一条流水线式 HTTP/1.1 或 HTTP/2 连接上发送多个请求时可能引发 5 元组冲突。这条规则在源码中体现为 UseOriginalSourceAddress 的判定逻辑可以精确复现文档描述的行为若对象存在OwnerReference且 Kind 为Ingress或Gateway直接返回false即 Cilium Ingress / Gateway API 控制器生成的 CEC 默认不使用原始源地址否则读取注解cec.cilium.io/use-original-source-addressstrconv.ParseBool解析注解缺失时回退到已弃用的同名 label两者都没有时默认返回true——这正是文档所说其他所有 CEC 都被视为true的出处。解析结果最终写入 listener 的UseOriginalSourceAddress字段见 cec_resource_parser.go#L626。五、CRD 结构解剖一个完整的 CCEC 长什么样以官方示例 envoy-traffic-management-test.yaml 为例该文件定义了一个CiliumClusterwideEnvoyConfigapiVersion: cilium.io/v2 kind: CiliumClusterwideEnvoyConfig metadata: name: envoy-lb-listener spec: services: - name: echo-service-1 namespace: default - name: echo-service-2 namespace: default resources: # 1) ListenerHTTP 连接管理器 路由器过滤器 - type: type.googleapis.com/envoy.config.listener.v3.Listener name: envoy-lb-listener filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: envoy-lb-listener rds: route_config_name: lb_route use_remote_address: true skip_xff_append: true http_filters: - name: envoy.filters.http.router typed_config: type: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router # 2) RouteConfiguration50/50 加权集群 重试策略 正则 URL 重写 - type: type.googleapis.com/envoy.config.route.v3.RouteConfiguration name: lb_route virtual_hosts: - name: lb_route domains: [ * ] routes: - match: prefix: / route: weighted_clusters: clusters: - name: default/echo-service-1 weight: 50 - name: default/echo-service-2 weight: 50 retry_policy: retry_on: 5xx num_retries: 3 per_try_timeout: 1s regex_rewrite: pattern: google_re2: { } regex: ^/foo.*$ substitution: / # 3) 两个 EDS 类型的 Cluster端点由 Cilium 通过 EDS 动态下发 - type: type.googleapis.com/envoy.config.cluster.v3.Cluster name: default/echo-service-1 connect_timeout: 5s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 - type: type.googleapis.com/envoy.config.cluster.v3.Cluster name: default/echo-service-2 connect_timeout: 3s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2三个关键结构点spec.services声明该配置关联的 Kubernetes Service。集群资源type: EDS、lb_policy: ROUND_ROBIN与这些 Service 的端点绑定只要存在spec.servicesCilium 就会自动向非内部 Listener 注入 Cilium 的 Envoy network/L7 过滤器——这一点由 InjectCiliumEnvoyFilters 实现注解cec.cilium.io/inject-cilium-filters可显式覆盖否则回退为len(spec.Services) 0。spec.resources一组google.protobuf.Any包装的 Envoy v3 消息可混合包含 Listener / RouteConfiguration / Cluster彼此通过名称引用如上例中rds.route_config_name: lb_route、weighted_clusters中的default/echo-service-1。命名空间级 CECCiliumEnvoyConfig结构与 CCEC 相同只是作用域限定在 metadata 所在命名空间CCEC 是集群级资源metadata.name必须在集群内唯一除非你想整体替换同名资源。六、示例一L7 路径重写与自定义 ListenerPrometheus 指标端口L7 Path Translation 示例复刻了--proxy-prometheus-port命令行选项已有的功能——在每个 Cilium 节点上向端口9090暴露一个 Envoy Listener把默认 Prometheus 抓取路径/metrics翻译成 Envoy 的 Prometheus 指标路径/stats/prometheus。示例的意义在于演示过去需要改 Cilium Agent 代码才能实现的能力现在只需一个 CRD。操作步骤# 应用示例 CRDCiliumClusterwideEnvoyConfig集群级资源名称集群内唯一 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-prometheus-metrics-listener.yaml # 验证节点端口是否响应指标请求 curl http://node-IP:9090/metrics对应仓库文件为 envoy-prometheus-metrics-listener.yaml。清理kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-prometheus-metrics-listener.yaml七、示例二多后端负载均衡 URL 重写 L7 策略叠加这是最能说明 CEC 与 Cilium 网络策略如何协同的示例envoy-traffic-management.rst。流量行为对发往echo-service-1或echo-service-2的流量按50/50在两个后端之间负载均衡把路径/foo重写为/使原本 404 的请求成功未重写成功的非/路径仍被 L7 网络策略拒绝403 Forbidden。步骤 1部署测试应用kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application.yaml kubectl get pods --show-labels -o wide测试负载包含两个客户端 Deploymentclient、client2和两个服务echo-service-1、echo-service-2。注意只有client2带有otherclient标签供后续 CiliumNetworkPolicy 选择器使用export CLIENT2$(kubectl get pods -l nameclient2 -o jsonpath{.items[0].metadata.name})步骤 2Hubble 观察基线流量kubectl -n kube-system port-forward deployment/hubble-relay 4245:4245 hubble observe --from-pod $CLIENT2 -f此时分别请求两个后端都能成功kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/ kubectl exec -it $CLIENT2 -- curl -v echo-service-2:8080/Hubble 中这些流都是to/from-stack、to/from-overlay或to/from-endpoint——还没有流量经过代理前提是集群中没有其他 L7 策略影响该流量。请求不存在的 URL 会 404kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/foo步骤 3加入 L7 策略Envoy 进入转发路径kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/client-egress-l7-http.yaml kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/client-egress-only-dns.yaml kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/加入 L7 策略后 Envoy 被引入路径Hubble 输出出现to-proxy流并显示七层 HTTP 信息例如HTTP/1.1 GET http://echo-service-1:8080/。注意Envoy 可能会对某些 HTTP 头做 sanitize清洗。若需要 Envoy 信任上一跳、避免改写特定头部可通过 Helm 值envoy.xffNumTrustedHopsL7PolicyIngress与envoy.xffNumTrustedHopsL7PolicyEgress设置信任跳数。对出口策略而言上一跳就是源 Pod对入口策略而言上一跳可能是源 Pod、L7 策略透明代理、Cilium Ingress Controller、Cilium Gateway API 或其他 Ingress 代理/基础设施。信任上一跳属于安全敏感配置需结合环境评估。步骤 4验证策略强制403策略只放行 GET/其他 URL 的包被丢弃并返回 403。Hubble 中可见类似Jul 7 08:40:15.076: default/client2-8b4c4fd75-6pgvl:58586 - default/echo-service-1-97748874-n7758:8080 http-request DROPPED (HTTP/1.1 GET http://echo-service-1:8080/foo)步骤 5应用 CCEC启用负载均衡与 URL 重写kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-traffic-management-test.yaml # /foo 现在成功被重写为 / kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/foo # /bar 依然被策略拒绝未被重写Hubble 显示 DROPPED kubectl exec -it $CLIENT2 -- curl -v echo-service-1:8080/bar多次请求同一后端时Hubble 输出约一半的流量会被另一个后端处理——这正是 50/50weighted_clusters的效果例如Jul 7 08:45:25.808: default/client2-8b4c4fd75-6pgvl:57942 - default/echo-service-1:8080 to-proxy FORWARDED (TCP Flags: SYN) Jul 7 08:45:25.809: default/client2-8b4c4fd75-6pgvl:57942 - default/echo-service-2-76c584c4bf-874dm:8080 to-endpoint FORWARDED (TCP Flags: SYN) Jul 7 08:45:25.809: default/client2-8b4c4fd75-6pgvl:57942 - default/echo-service-2-76c584c4bf-874dm:8080 http-request FORWARDED (HTTP/1.1 GET http://echo-service-1:8080/)可以看到同一个源端口57942的 TCP 连接先到echo-service-1to-proxy再由 Envoy 转到echo-service-2to-endpoint——即客户端连接服务 1但约一半请求实际由服务 2 处理。八、示例三熔断Circuit Breaking与异常节点剔除L7 Circuit Breaking 演示如何用 CCEC 配置连接/并发上限并故意触发熔断器。对应资源文件 envoy-circuit-breaker.yaml 的核心 Cluster 片段- type: type.googleapis.com/envoy.config.cluster.v3.Cluster name: default/echo-service connect_timeout: 5s lb_policy: ROUND_ROBIN type: EDS edsClusterConfig: serviceName: default/echo-service circuit_breakers: thresholds: - priority: DEFAULT max_requests: 2 max_pending_requests: 1 outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2max_pending_requests: 1与max_requests: 2意味着并发连接/请求一旦超过该阈值Envoy 就对后续请求打开熔断直接失败。验证流程# 部署测试应用fortio 压测客户端 echo-service kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application-proxy-circuit-breaker.yaml # 应用熔断配置 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-circuit-breaker.yaml kubectl get ccec envoy-circuit-breaker -oyaml # 2 并发、20 次请求个别请求收到 503Code 200 : 19 / Code 503 : 1 export FORTIO_POD$(kubectl get pods -l appfortio -o jsonpath{.items[0].metadata.name}) kubectl exec $FORTIO_POD -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 http://echo-service:8080 # 4 并发、20 次请求熔断明显Code 200 : 7 / Code 503 : 13 kubectl exec $FORTIO_POD -c fortio -- /usr/bin/fortio load -c 4 -qps 0 -n 20 http://echo-service:8080并发提升到 4 时20 次请求中仅 35% 成功其余被熔断为 503——这正是阈值设置生效的表现。配置中同时启用了outlier_detectionconsecutive_local_origin_failure: 2连续 2 次本地发起失败的后端节点会被暂时剔除。清理kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-circuit-breaker.yaml kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application-proxy-circuit-breaker.yaml九、示例四按权重灰度切流90/10 Traffic ShiftingL7 Traffic Shifting 演示把发往helloworldService 的流量按 90% →helloworld-v1、10% →helloworld-v2分配。要点是先为每个后端 Deployment 建立独立的 Service再用命名空间级CiliumEnvoyConfig做加权路由对应文件 envoy-helloworld-v1-90-v2-10.yaml。# 1) 部署客户端与两个版本的服务端 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/client-helloworld.yaml export CLIENT$(kubectl get pods -l nameclient -o jsonpath{.items[0].metadata.name}) # 基线未加配置时约 50/50 for i in {1..10}; do kubectl exec -it $CLIENT -- curl helloworld:5000/hello; done # 2) 为每个后端建立独立 Service kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/helloworld-service-v1-v2.yaml # 3) 应用 90/10 加权路由CiliumEnvoyConfig kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/envoy-helloworld-v1-90-v2-10.yaml # 4) 再次压测约 90% 响应来自 v1、10% 来自 v2 for i in {1..10}; do kubectl exec -it $CLIENT -- curl helloworld:5000/hello; done清理时删除 CEC 与测试应用两个 YAML 即可恢复原状。十、示例五Service 级代理负载均衡betaProxy Load Balancing for Kubernetes Services 是独立于 Ingress 的特性对某个 Kubernetes Service 打标后发往该 Service 的流量会被重定向到 Cilium 管理的 Envoy 代理做负载均衡适合 gRPC 等需要 L7 感知的 LB 场景。# 部署测试应用client 两个后端 Pod 的 echo-service kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/servicemesh/envoy/test-application-proxy-loadbalancing.yaml CLIENT$(kubectl get pods -l nameclient -o jsonpath{.items[0].metadata.name}) # Hubble 观察服务流量 kubectl -n kube-system port-forward deployment/hubble-relay 4245:4245 hubble observe --service echo-service -f kubectl exec -it $CLIENT -- curl -v echo-service:8080/ # 给 Service 加 L7 负载均衡注解Envoy 进入转发路径 kubectl annotate service echo-service service.cilium.io/lb-l7enabled kubectl exec -it $CLIENT -- curl -v echo-service:8080/注解后 Hubble 输出由 L3-L4 的pre-xlate-fwd/post-xlate-rev变为to-proxy FORWARDED→to-endpoint FORWARDED说明流量已经经过 Envoy 再到达后端。支持的 Service 注解默认值遵循 Helm 配置注解说明可取值默认值service.cilium.io/lb-l7为该 Service 启用 L7 负载均衡enabled、disableddisabledservice.cilium.io/lb-l7-algorithm使用的 LB 算法round_robin、least_request、randomHelm 值loadBalancer.l7.algorithm十一、源码纵深CEC 从 apply 到 xDS 的下发链路结合仓库源码可以理清一条完整调用链位于 pkg/ciliumenvoyconfigK8s 反射k8s_reflector.go 监听两类 CRD 的增删改写入 statedb 中的 CEC 表解析cec_resource_parser.go 的ParseResources把spec.resources反序列化为 Envoy v3 消息并按UseOriginalSourceAddress第三节注解逻辑与InjectCiliumEnvoyFiltersspec.services非空时自动注入 Cilium 过滤器计算 listener 行为端口分配与资源落表newPortAllocator复用proxyports.ProxyPorts为每个需要监听端口的 CEC 分配节点本地端口解析产物进入EnvoyResources表对账与下发reconciler.go 中envoyOps.Initializer先等待资源表初始化再用当前快照 seed xDS cache保证 Envoy xDS server 启动时即持有最新配置随后注册 statedb reconciler按EnvoyConfigRetryInterval周期重试解析失败或资源冲突即体现为 Cilium Agent 日志中的 error/warning——这与第四节apply 必然成功、需看 Agent 日志的约束完全对应。从源码结构看冲突检测发生在资源表合并与重复 filter chain 校验层面参见 duplicate_filter_chain_test.go 与 main_test.go 中的冲突场景测试因此官方文档多个 CEC 修改同一部分结果不可预测的警告并非虚言系统会告警但不会替你仲裁。十二、排障清单综合以上各节日常操作建议遵循apply 之后永远看 Agent 日志kubectl logs -n kube-system ds/cilium | grep -E level(error|warning)——这是验证 Envoy 资源是否被成功安装的唯一可靠途径东西向 CEC 记得加注解cec.cilium.io/use-original-source-address: false避免 5 元组冲突不要触碰 Ingress / Gateway API 控制器自动生成的 CEC手写 CEC 与其共存时检查 Agent 日志确认无冲突引用扩展前先确认其存在于 Cilium 定制 Envoy 构建否则节点本地 Envoy 会拒绝加载该配置用 Hubble 观察流量路径变化to-proxy出现即表示 Envoy 已介入DROPPED (HTTP/1.1 GET ...)表示 L7 策略拦截二者是验证 CEC 与策略协同是否生效的最直接信号。小结Cilium 的 L7 流量管理把 Envoy 的控制能力以 CRD 形式暴露给集群CiliumEnvoyConfig/CiliumClusterwideEnvoyConfig承载标准 Envoy v3 资源覆盖路径重写、加权负载均衡、URL 改写、熔断、灰度切流与 Service 级代理 LB 等典型场景。其设计取舍也很明确——校验与冲突消解被有意保持到最薄换取配置的完全自由度代价是配置正确性验证必须依赖 Cilium Agent 日志与 Hubble 流量观察且这两类 CRD 应严格作为集群管理员资源使用。理解了use-original-source-address、spec.services与注入过滤器的联动源码见 pkg/ciliumenvoyconfig/cec_resource_parser.go以及 reconcile 到 xDS 的下发链路后你就具备了在生产集群中安全使用这一能力并独立排障的全部要素。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
