API网关云原生微服务【免费下载链接】kgatewayThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/kg/kgateway点击查看免费下载导读kgateway 的端到端e2e测试需要在真实运行的 Kubernetes 集群上执行如果只用一个集群串行跑完全部测试CI 流水线会耗时漫长。为了最大化硬件利用效率kgateway 将全部 e2e 测试按运行时长负载均衡到一批 Kubernetes 集群上并通过 GitHub Actions 矩阵.github/workflows/e2e.yaml统一编排。读完本文你将掌握 kgateway 的集群分片调度策略cattle, not pets、分片覆盖率的自动校验机制、何时及如何重新平衡测试分片以及如何为新增测试选择合适的集群。背景为什么需要对 e2e 测试做负载均衡目标高效利用 CI 硬件kgateway 的每个端到端测试都运行在一个真实的 Kubernetes 集群上例如由kind或k3d临时创建的测试集群。如果所有测试都集中到单个集群上且串行执行那么CI 流水线总耗时等于全部测试耗时之和随着测试套件持续增长合并门槛的等待时间会越来越长单个集群一旦被某类重负载测试占用其他轻量测试只能排队等待硬件资源严重闲置。因此 kgateway 在 CI 中引入测试负载均衡将测试拆分成多个分片shard每个分片由一个独立的集群并行执行让一批集群的总体运行时间趋于一致从而最大化 CI 硬件的吞吐效率。这一目标在 .github/workflows/e2e.yaml 的注释中也有明确表述——项目为端到端测试设置了30 分钟的上限阈值负载均衡的目的就是让 PR 上的测试能快速迭代一旦某个集群超时就需要重新平衡分片详见该文件matrix.test前的注释。旧策略按领域分组扩展性差kgateway 过去的做法是按领域domain对测试分组例如把所有路由类测试放一组、所有安全类测试放另一组。这个策略存在天然缺陷不同领域的测试数量差异很大热门领域如路由、认证测试量大冷门领域测试量小结果就是有些测试集群跑完一轮需要的时间是其他集群的两倍集群之间负载严重失衡硬件浪费明显。也就是说按领域分组只保证了同类测试在一起却没有保证每个集群耗时相近无法随着测试总量增长而平滑扩展。现行策略按运行时长分组把集群当牲畜kgateway 当前的做法是按运行时长runtime对测试分组而不是按领域把跑得快的测试和跑得慢的测试按实测时长大致均分到各个集群使每个分片的整体运行时间尽量接近测试在集群之间可以方便地迁移不会因为领域归属而绑定在某个集群上。这正是 Kubernetes 社区名言cattle, not pets把集群当牲畜而非宠物在测试编排上的体现——任何一个集群都是可替换的、临时的资源测试分片可以在集群之间自由流动集群被删除或重建都不会影响测试的组织结构。分组的具体定义全部收敛在GitHub Actions 矩阵中.github/workflows/e2e.yaml。这样做的关键好处是把负载均衡的复杂度完全隔离在 CI 流水线内不打扰本地开发。本地开发者跑测试时根本不需要关心分片归属只需按 README-e2e-framework.md 中描述的方式如./hack/run-e2e-test.sh SessionPersistence直接运行即可。分片的真相来源GitHub Actions 矩阵负载均衡的全部编排逻辑都落在end_to_end_tests作业的strategy.matrix.test列表中。矩阵中的每一项代表一个独立集群核心字段包括字段作用示例cluster-name集群唯一标识用于创建 kind/k3d 集群并命名产物cluster-one、cluster-upgradego-test-args传给go test的参数通常为超时上限-timeout25m、-timeout5mgo-test-run-regex该集群要执行的测试的-run正则多个测试用\|分隔^TestKgateway$$/^BasicRouting$$\|...localstack是否启动 localstackAWS 相关测试需要如 Lambda、EC2true/falseordered-ads是否启用有序 ADS 通道true/falsegateway-api-version指定使用的 Gateway API 版本用于升级类测试v1.5.1每个集群定义上方都注释了该分片最近一次 CI 运行时的实测耗时如May 29, 2026: ~9 minutes这些注释正是后续重新平衡时文档化新旧结果的依据。截至当前仓库矩阵共定义了10 个集群cluster-one约 9 分钟BasicRouting、PathMatching、HTTPRouteServices、TLSRouteServices、GRPCRouteServices、SessionPersistencecluster-two约 13 分钟TestKgatewayWaypointWaypoint 全量套件cluster-three约 10 分钟DynamicForwardProxy、Lambda、EC2、AccessLog、LocalRateLimit、Cors、BackendConfigPolicy、ListenerPolicy、Tracing、DirectResponse、AdminServer、FaultInjection并启用localstack: truecluster-four约 8 分钟ExtProc、ExtAuth、PolicySelector、Backends、BackendTLSPolicies、CSRF、AutoHostRewrite、LeaderElection、Compression、GlobalRateLimit、InternalRedirect、TestCustomGWPcluster-five约 10 分钟TimeoutRetry、HeaderModifiers、RBAC、HttpACL、APIKeyAuth、Deployer、Transforms、TestRouteReplacement、RouteDelegation、JWT、BasicAuth、WebSocketcluster-six约 10 分钟TestListenerSet、TCPRouteServices、TestKgatewayIstioAutoMtls、TestZeroDowntimeRollout并启用ordered-ads: truecluster-seven约 4 分钟TestAPIValidation、OAuth、TrafficPolicyStatus、XdsStarvation、XdsIdentityRace显式设置ordered-ads: falsecluster-eight约 5 分钟TestKgatewayMetrics、TestControlPlaneTLS、FrontendTLScluster-multi-install约 4 分钟TestMultipleInstalls单独设置-timeout5mcluster-upgrade约 6 分钟TestUpgrade并固定gateway-api-version: v1.5.1——注释明确警告不要往这个集群加测试因为它运行的是旧版 Gateway API只应在升级时按 n-1 版本同步。矩阵中go-test-run-regex里的$$是Make 对字面量$的转义正则最终会经 Makefile 传给go test -run实际等价于$。整个正则采用^TestKgateway$$/^BasicRouting$$这种多级锚定写法把顶层测试函数TestKgateway与套件级子测试BasicRouting逐段精确锁定避免误匹配同名或前缀相同的测试。在流水线执行时每个矩阵项都会复用.github/actions/kubernetes-e2e-tests/action.yaml这个 composite action由其把run-regex与test-args拼装成GO_TEST_USER_ARGS并执行make e2e-testaction.yaml。对应的 Makefile 目标为e2e-test: go-test最终通过 gotestsum 携带-tagse2e运行./test/e2e/tests包见 Makefile 与 Makefile。自动化防线TestAllE2ETestsInShards校验分片覆盖率负载均衡策略要长期可靠前提是每个测试都至少被一个分片覆盖。如果新增测试后忘了把它加进矩阵CI 里会永远跑不到它——这正是 kgateway 用单测来约束 CI 配置的原因。TestAllE2ETestsInShards位于 test/e2e/tests/shards_test.go会在 PR 检查中自动验证每一个注册的 e2e 测试都至少被e2e.yaml中的一个 shard 正则覆盖凡是没被覆盖的测试都会在测试失败信息里列出来并提示更新.github/workflows/e2e.yaml以包含这些测试。其实现链路从源码结构看分四步发现测试路径discoverE2ETestPaths扫描test/e2e/tests/下所有带//go:build e2e构建标签的 Go 文件用正则解析出顶层Test*函数、套件 runner 调用如SuiteRunner().Run(以及子包委托调用如kgateway.Run(t, ...)再结合各套件内的静态字符串.Register(SuiteName, ...)调用生成形如TestKgateway/JWT的完整测试路径列表。解析工作流配置parseE2EWorkflowPaths读取../../../.github/workflows/e2e.yaml反序列化到workflowConfig结构体提取每个作业矩阵项里的go-test-run-regex并按|切分得到所有正则备选。正则转路径regexToShardPath将^TestKgateway$$/^JWT$$这种含 Make 转义的正则还原为字面量拆分成{topLevel: TestKgateway, suite: JWT}结构。覆盖率判定isCoveredByShardPaths检查测试路径与分片条目的匹配关系——顶层函数套件精确匹配算覆盖某个分片条目只锚定了顶层函数无套件限定时表示整个函数及其所有子测试都被覆盖shards_test.go。此外该测试还维护了一张豁免清单e2eTestsNotRequiredInPRShards列出那些不需要出现在 PR 分片里的测试及其原因shards_test.goTestKgateway/AttachedRoutes在专门的 nightly 负载测试工作流中运行TestKgateway/StrictChurn、TestKgateway/XdsCost、TestKgateway/XdsFleet均为 opt-in 的压力/成本基准测试分别通过make run-load-tests-strict-churn、make run-xds-cost-bench、make run-xds-fleet-bench按需运行见 MakefileTestZoneAwareRouting需要多可用区、多 worker 的 kind 集群按 hack/kind/setup-zone-aware-routing.sh 手动运行。这些套件的注册代码位于 test/e2e/tests/kgateway/suite_runner.go例如Deployer、Lambda、SessionPersistence等慢速测试集中注册在前BasicRouting、ExtAuth、JWT等快速测试注册在后StrictChurn、XdsCost、XdsFleet三个套件会改动 controller Deployment因此被环境变量如KGW_ENABLE_STRICT_CHURN硬性门控避免被宽泛的正则如 nightly 的^TestKgateway隐式触发。分片矩阵正是针对这些套件名逐一锚定正则的。重新平衡Re-Balancing什么情况下需要重新平衡重新平衡测试分片被刻意设计成非常简单的动作——它不常发生但发生时应能轻松完成。以下两种情况触发一个集群上的测试远早于另一个集群完成说明分片之间负载失衡慢集群拖累了整体流水线所有集群都已耗尽需要引入新集群说明测试总量增长到现有分片无法容纳或单个分片时长逼近 30 分钟上限。操作步骤按原文档的流程重新平衡共四步审查最近的 CI 结果确定可以迁移的测试从 GitHub Actions 的Run ././github/actions/kubernetes-e2e-tests步骤耗时中找出各分片的实际运行时间这也是矩阵注释里统一采用的标准——使用 GitHub Action 步骤时间而非go test时间或整个 job 时间因为它更容易采集且相当稳定调整 .github/workflows/e2e.yaml 中被调用的 run 函数即修改对应集群项的go-test-run-regex把选中的测试从超载集群的正则中移除、追加到欠载集群的正则中在运行测试的矩阵上文档化新的结果将迁移后各集群的实测耗时更新到矩阵定义上方的注释里保持每个分片时长信息的时效性开 PR并在 PR 描述中清晰记录变更前后的结果让评审者能直观看到负载均衡的效果对比哪个集群从多少分钟降到多少分钟。值得注意的是原文档步骤编号中有个笔误两个第 4 步实际操作以更新注释 → 开 PR 记录前后结果为完整闭环即可。新增测试如何选择目标集群当你想往 kgateway 的 e2e 测试套件里加入一个新的测试套件时负载均衡要求你做一次按耗时归档查看最近合并 PR 的 Kubernetes 测试 action 结果确认当前各分片的实际运行时长找出运行时长最低的集群即耗时最短、最有余量的分片把你的测试套件加入该集群在 .github/workflows/e2e.yaml 中的定义把套件名追加到该集群的go-test-run-regex中用|分隔并按^TestKgateway$$/^YourSuite$$的格式锚定。同时README-e2e-framework.md 还补充了两条配套纪律新测试应加入所有 PR 都会运行的Kubernetes Tests即 e2e.yaml以保证 PR 运行与 nightly 运行之间的覆盖一致性加入列表时更新对应测试的日期与时长注释确保分片负载数据不陈旧唯一的例外是 Upgrade 测试——它不运行在 main 分支上而是运行在全部 LTS 分支上。新增套件的代码侧步骤在 features 目录下建子目录、在testdata/放清单、定义suite.go并通过Register(SuiteName, ...)注册、再由顶层测试函数委托执行详见 README-e2e-framework.md这里不再展开。分片之外的验证夜间测试与负载测试PR 矩阵并非 e2e 验证的全部。除了 PR 分片kgateway 还通过 .github/workflows/nightly-tests.yaml 在每天 05:00 UTC 对main及每个受支持的 LTS 分支执行更广的验证Conformance针对 experimental 与 standard 两个 Gateway API 通道分别在最大/最小版本组合上运行上游 Gateway API 一致性套件Load Tests运行kube_gateway_api_load_tests作业E2E使用一条宽泛的正则^TestKgateway|^TestAPIValidation|^TestListenerSet|...在 4 个 Gateway API 版本 × 2 个通道上跑全量 e2e这与 PR 分片的精确锚定正则形成互补——分片正则负责把测试精确分配到集群而夜间全量正则负责兜底验证。之所以 PR 分片能精确到套件级别而不怕漏测正是因为TestAllE2ETestsInShards这条单测防线会在 PR 阶段强制每个测试至少命中一个分片正则。对于StrictChurn、XdsCost等 opt-in 负载测试则通过make run-load-tests-strict-churn等 Make 目标在夜间负载测试通道中显式执行不进入 PR 分片。本地开发不受影响负载均衡的复杂度被隔离在 CI 层本地开发者的体验保持不变。无论是按套件运行还是按单个测试方法运行都可以直接使用 hack/run-e2e-test.sh# 运行整个套件默认失败时保留现场便于调试 ./hack/run-e2e-test.sh SessionPersistence # 运行套件内的某个测试方法 ./hack/run-e2e-test.sh TestCookieSessionPersistence # 运行顶层测试函数 ./hack/run-e2e-test.sh TestKgateway # 跳过已有集群上的安装步骤加快本地迭代 PERSIST_INSTALLtrue ./hack/run-e2e-test.sh SessionPersistence # 列出所有可用的测试套件与顶层测试 ./hack/run-e2e-test.sh --list该脚本会通过git grep自动把测试名解析成最精确的go test -run正则套件解析为^TestKgateway$/^SessionPersistence$这种多级锚定形式因此本地跑单个测试时使用的正则语义与 CI 矩阵完全一致。更多手动运行方式如直接go test -tagse2e -run ^TestKgateway$ ./test/e2e/tests可参考 README-e2e-framework.md。小结kgateway 的 e2e 测试负载均衡是一条配置即真相 测试守护配置的工程闭环策略按运行时长而非领域分组让每个集群耗时相近集群可替换、可增删cattle, not pets载体所有分片定义在 .github/workflows/e2e.yaml 的 Actions 矩阵中复杂度与本地开发彻底隔离防线TestAllE2ETestsInShards单测test/e2e/tests/shards_test.go自动校验每个测试都命中至少一个分片正则杜绝新增测试悄悄漏出 CI流程重新平衡和新增测试都有明确、轻量的操作步骤且要求把前后耗时文档化在矩阵注释与 PR 描述中。如果你正在为 kgateway 贡献 e2e 测试或希望在自己项目的 CI 中引入类似的多集群分片调度这套按耗时分组 配置校验自动化的模式可以直接借鉴。赞分享API网关云原生微服务【免费下载链接】kgatewayThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/kg/kgateway点击查看免费下载相关推荐Dear ImGui终极指南5分钟打造专业C图形界面Dear ImGui终极指南5分钟打造专业C图形界面 你是否厌倦了复杂的GUI框架和繁琐的界面设计Dear ImGui为你提供了一个轻量级、无依赖的CUI组件前端桌面应用图形学kgateway高可用部署多集群与负载均衡配置kgateway高可用部署多集群与负载均衡配置 Kgateway作为云原生API网关和AI网关其高可用部署配置对于企业级应用至关重要。本文将详细介绍如何通过API网关云原生微服务Kue Redis 集群性能调优分片与负载均衡配置Kue Redis 集群性能调优分片与负载均衡配置 你是否正面临 Kue 任务队列在高并发场景下的性能瓶颈随着业务增长单节点 Redis 已无法满足大规模任务调度后端消息队列上一篇MXNet 入门第一课用 NP on MXNet 操作 ndarray 数据下一篇Roc 快照回归测试深度解析嵌套绑定多次引用顶层值时不再误报 self-assignmentissue 9635创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考