API网关云原生微服务【免费下载链接】kgatewayThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/kg/kgateway点击查看免费下载kgateway 的目标是成为基于 Kubernetes Gateway API 的厂商中立、开源 API 网关因此它需要逐步淘汰从 Gloo Gateway 继承的遗留类型。本文以设计提案 EP-10611 为主体完整解析将Upstream.kgateway.dev重命名为Backend.kgateway.dev的动机、两阶段 API 语义拆分后端类型与后端策略、与 K8s Gateway API 的对齐思路并结合当前仓库源码验证重命名落地后的真实 API 形态、配置示例与测试用例。读者读完将掌握 kgateway 后端资源Backend的来龙去脉、设计取舍以及当前可用的配置字段与示例。背景为什么需要重新审视Upstream类型kgateway 的核心定位是提供厂商中立、开源的 OSS API 网关底层基于 Kubernetes Gateway API。为此项目的主要工作方向之一是移除遗留的 Gloo Gateway 类型并重塑那些与 K8s Gateway API 语义和惯用法不一致的 Gloo Gateway API。Upstream.gloo.solo.io正是这样一个需要被重新审视的类型。它从 Gloo Gateway 直接继承而来其名称与概念在 Gloo Gateway 用户群体中根深蒂固但它的 API 形态与 K8s Gateway API 的语义并不完全吻合。在 Gloo Gateway以及当前 kgateway中Upstream这个资源实际上承载了两个不同层次的配置层次作用举例Backend type后端类型定义路由的目标routing destinationAWS Lambda 函数、GCP Cloud Run 服务、静态外部主机、K8s Service 等Backend policy后端策略描述与后端交互时的行为与后端类型无关mTLS 连接、TLS 证书配置等这两个层次在语义上截然不同却被塞进了同一个资源里。这正是后续拆分与重命名的根本原因。第一层语义Backend type用独立资源表达非 K8s 后端Backend type 允许用户定义路由的目标。常见后端类型包括AWS Lambda 函数GCP Cloud Run 服务静态外部主机K8s Service其中AWS Lambda 和 GCP Cloud Run 服务在 Kubernetes 中没有原生表示因此用独立的 CRD 资源来表达它们是合理且必要的。静态/外部主机在理论上可以通过 K8sService的ExternalName类型来表达但这一用法在 Gloo Gateway以及现在的 kgateway中并不被支持主要原因是用例需求不足同时ExternalNameService 本身存在一些使用上的注意事项例如 DNS 解析行为如果有可行的替代方案通常会倾向于避免使用它。因此使用独立的Upstream/Backend资源来定义外部主机同样是有意义的。其他项目也有类似的概念例如 Istio 的ServiceEntry类型用于声明服务网格外的流量入口。然而核心 K8sService本身已经能够表达集群内流量目标是一种合法的后端类型那么为什么 Gloo Gateway 的Upstream还要支持Service作为后端类型呢这个冗余的答案就藏在第二个语义层次——backend policy中。第二层语义Backend policy策略为何要挂在后端资源上Backend policy 是一个宽泛的概念大致描述与后端交互相关的行为它与后端的类型无关注意某些策略只适用于特定后端类型但总体原则不变。典型场景是 mTLS用户希望以 mTLS 方式连接后端就需要一种表达该策略的方式。在 Gloo Gateway 中Upstream类型就是用户配置这类策略的位置。以 mTLS 为例用户需要提供一个包含证书和密钥的Secret用于在与目标后端建立连接时完成 mTLS 握手。这种把“类型”和“策略”耦合在同一个资源里的设计正是与 K8s Gateway API 理念冲突的核心。与 K8s Gateway API 的差异策略应该独立挂载Upstream的名称和概念对 Gloo Gateway 用户来说耳熟能详但其现有 API 形态并不能完全契合 K8s Gateway API 的语义与惯用法。第一层——定义各种没有 K8s 原生表示的后端类型——在 K8s Gateway API 语境下依然相关且重要唯一的例外是不再需要支持原生Service因为 K8sService本身就是路由目标。事实上在 Gateway API 中定义一个自定义类型作为后端引用正是支持非 K8s 后端的核心扩展点extension point。第二层——backend policy——K8s Gateway API 则走向了完全不同的方向策略应表达为独立的资源通过“挂载attach”到目标对象上来增强与后端的交互这样无需修改后端类型的spec即可定义策略典型例证是 Gateway API 的BackendTLSPolicy类型——它专门为后端提供 TLS 策略而不触碰后端资源本身的定义。也就是说K8s Gateway API 将“后端是什么”与“如何与后端交互”彻底解耦。kgateway 的演进方向正是要顺应这一趋势。kgateway 现状一个名字上的遗留kgateway 目前有一个后端类型Upstream.kgateway.dev这个名称纯粹是从最初的 Gloo GatewayUpstream继承而来的遗留产物。但正如上文所述kgateway 希望让这个类型朝着 K8s Gateway API 的方向演进。这意味着 kgateway 的Upstream.kgateway.dev将拥有与Upstream.gloo.solo.io不同的语义并持续分化——两者实际上是不同的资源却共用了同一个名字。动机目标与非目标目标Goals就Upstreams.gloo.solo.io类型与 K8s Gateway API 语义之间的不兼容之处达成一致认识就表达后端目标的新kind名称达成一致。非目标Non-Goals不涉及Backend类型的具体设计或 API 形态的确定这是另一份独立 EP 的范畴。这份设计提案的边界非常清晰只解决“改名”与“语义对齐方向”两个问题不越界去设计具体的 API 细节。提案重命名为Backend.kgateway.dev本提案的核心内容是一句话将Upstream.kgateway.dev类型重命名为Backend.kgateway.dev。之所以这么做理由包括区分两种不同资源明确提示用户这是不同的资源、具有不同的语义减少 Gloo Gateway 老用户迁移到 kgateway 时的困惑也能降低他们翻到旧版 Gloo Gateway 文档、示例时产生的误解遵循 K8s Gateway API 的术语习惯在 Gateway API 语境中“backend” 就是表达“路由目标”的公认术语与核心路由原语保持一致Gateway API 的核心路由原语全部通过backendRefs来定义路由规则例如HTTPRoute中的HTTPBackendRef此外还有前述的BackendTLSPolicy为后端提供 TLS 策略——这些都以 “backend” 为统一命名附带收益——避免类型冲突当用户在同一集群中同时安装 Gloo Gateway 和 kgateway 进行迁移时重命名可以避免两个系统存在同名upstream类型。如果不改名CLI 或任何使用非限定名称的工具在与集群交互时都会遭遇糟糕的体验资源名冲突导致歧义。备选方案Alternatives设计过程中还评估过其他候选名称Upstream维持现状但与 Gloo Gateway 语义混淆被否决Destination语义偏路由目标未采用KUpstream带前缀的变体命名未采用。最终选择Backend因为它与 Gateway API 生态的术语体系完全一致。落地方案验证当前仓库中的Backend.kgateway.dev设计文档是提案层面的论述而当前仓库已经完整实现了这一重命名。从源码中可以清晰看到Backend.kgateway.dev的真实形态。1. API 类型定义在 backend_types.go 中定义了完整的Backend资源// kubebuilder:printcolumn:nameType,typestring,JSONPath.spec.type,descriptionWhich backend type? // kubebuilder:printcolumn:nameAccepted,typestring,JSONPath.status.conditions[?(.typeAccepted)].status,descriptionBackend configuration acceptance status // kubebuilder:printcolumn:nameAge,typedate,JSONPath.metadata.creationTimestamp,descriptionThe age of the backend. // genclient // kubebuilder:object:roottrue // kubebuilder:subresource:status type Backend struct { metav1.TypeMeta json:,inline metav1.ObjectMeta json:metadata,omitempty Spec BackendSpec json:spec Status BackendStatus json:status,omitempty }当前支持的BackendType枚举为见 backend_types.goAWSAWS Lambda / EC2 后端Static静态主机列表后端DynamicForwardProxy动态正向代理后端GCPGCP 服务后端PriorityGroups优先级组故障转移后端值得注意的一个演进信号BackendSpec中的Type字段已被标记为Deprecated注释明确说明“后端类型将从配置推断The backend type is inferred from the configuration”并通过 CEL 校验ExactlyOneOfaws;static;dynamicForwardProxy;gcp;priorityGroups来保证配置互斥见 backend_types.go。这正是“第一层语义类型”走向更符合 Gateway API 表达方式的体现——类型不再需要显式声明而是由后端配置本身推导。2. 资源标识GVK / GVR在 wellknown/kgw.go 中Backend已被正式注册为 kgateway 核心类型之一BackendGVK buildKgatewayGvk(Backend) BackendGVR BackendGVK.GroupVersion().WithResource(backends)即 API 组为gateway.kgateway.dev资源名为backends这与其核心类型TrafficPolicy、BackendConfigPolicy、ListenerPolicy等并列。3. 翻译插件实现后端从 CRD 到 Envoy 集群的翻译由 backend 插件完成位于 pkg/kgateway/extensions2/plugins/backend/其中包括aws.go、ec2.go、gcp.go、static.go、dfp.go、priority_groups.go等子实现。插件通过 KRT 集合krt.NewCollection监听Backend资源变化将其翻译为内部表示IR进而生成 Envoy 配置见 plugin.go。4. 策略分离BackendConfigPolicy重命名设计中最核心的理念——“策略独立于后端类型”——在当前仓库中已经通过BackendConfigPolicy落地。该类型定义在 backend_config_policy_types.go 中其targetRefs/targetSelectors的 CEL 校验明确要求引用三类目标之一K8sService、gateway.kgateway.dev的Backend或 IstioHostname见 backend_config_policy_types.go。也就是说策略不再写在后端资源内部而是作为独立资源挂载到后端上。这与提案中强调的 Gateway API 方向BackendTLSPolicy模式完全一致。BackendConfigPolicy支持的策略配置非常丰富常见字段包括connectTimeout建立新连接的超时tlsTLS origination 配置secretRef、sni、verifySubjectAltNames、insecureSkipVerify、alpnProtocols、simpleTLS控制是否默认启用 mTLS等loadBalancer负载均衡策略leastRequest、roundRobin、ringHash、maglev、random、healthyPanicThreshold、zoneAware等healthCheck主动健康检查HTTP 或 gRPCoutlierDetection被动健康检查连续 5xx 驱逐等circuitBreakers熔断阈值dnsDNS 刷新率与 jitterhttp1ProtocolOptions/http2ProtocolOptions/commonHttpProtocolOptions协议选项示例为 Service 后端配置熔断仓库中 example-backendconfigpolicy-circuit-breakers.yaml 展示了最直接的用法——把策略挂载到 K8sService上apiVersion: gateway.kgateway.dev/v1alpha1 kind: BackendConfigPolicy metadata: name: httpbin-cb namespace: default spec: targetRefs: - group: kind: Service name: httpbin circuitBreakers: maxConnections: 1000 maxPendingRequests: 500 maxRequests: 2000 maxRetries: 10示例为 Service 后端配置连接参数example-svc-with-attached-backend-config-policy.yaml 则展示了一个完整的场景HTTPRoute通过backendRefs指向example-svc而策略以独立资源BackendConfigPolicy挂载到同一个 ServiceapiVersion: gateway.kgateway.dev/v1alpha1 kind: BackendConfigPolicy metadata: name: example-svc-policy spec: targetRefs: - name: example-svc group: kind: Service connectTimeout: 5s perConnectionBufferLimitBytes: 1024注意这里的核心模式路由规则使用backendRefsGateway API 原生语义而策略通过targetRefs独立挂载——后端“类型”与后端“策略”完全分离正是 EP-10611 所追求的架构形态。5.Backend资源的使用示例test/e2e/features/backends/testdata/backend.yaml 给出了一个 Static 类型后端的完整 YAMLapiVersion: gateway.kgateway.dev/v1alpha1 kind: Backend metadata: name: nginx-static namespace: kgateway-base spec: type: Static static: hosts: - host: nginx.nginx-shared.svc # 静态引用共享的 nginx Service port: 8080对应的 e2e 测试位于 test/e2e/features/backends/suite.go其中TestConfigureBackingDestinationsWithUpstream测试案例会应用该 Backend 并通过网关发起请求验证路由可达性见 suite.go。测试方法名仍保留着历史命名痕迹但实际使用的资源已经是Backend。6. 从backendRefs引用Backend资源在 e2e 测试的 priority-groups.yaml 中可以清楚看到HTTPRoute如何通过backendRefs引用自定义Backend类型apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: priority-groups-route namespace: kgateway-base spec: parentRefs: - name: gateway hostnames: - failover.example.com rules: - backendRefs: - name: priority-groups kind: Backend group: gateway.kgateway.dev这印证了提案中“核心路由原语都通过backendRefs定义路由规则”的论断——Backend正是作为backendRefs中kind: Backend, group: gateway.kgateway.dev的合法引用目标存在的。演进后的延伸优先级组PriorityGroups后端作为重命名落地的直接产物kgateway 在后端能力上还扩展了PriorityGroups后端类型。相关设计见 design/13643-backend-priority-groups.md它允许在一个Backend上表达有序的故障转移组列表apiVersion: gateway.kgateway.dev/v1alpha1 kind: Backend metadata: name: priority-groups spec: priorityGroups: - backendRefs: # group 0主后端priority 0 - name: primary-nginx - backendRefs: # group 1故障转移priority 1 - name: failover-echo - name: failover-httpbin翻译时每个组映射为 Envoy 集群负载分配中的一个 priority 层级配合BackendConfigPolicy的主动健康检查驱动故障转移与自动恢复。这进一步说明Backend资源作为 Gateway API 的扩展点已经成为 kgateway 表达各类非 K8s 原生后端与复杂路由语义的统一载体。总结从命名到架构的语义对齐EP-10611 表面上是一次类型改名实质上是 kgateway 架构理念的一次关键对齐概念拆分将 Gloo GatewayUpstream中耦合的“后端类型”与“后端策略”两层语义彻底拆开命名对齐以 Gateway API 生态公认的Backend术语命名路由目标与backendRefs、BackendTLSPolicy等原语形成一致的命名体系策略独立通过BackendConfigPolicy等独立策略资源挂载到后端无需修改后端spec即可增强交互行为迁移友好同一集群共存 Gloo Gateway 与 kgateway 时不再因upstream同名造成 CLI 与工具链的 UX 困扰。从当前仓库源码来看这一设计已全面落地Backend.kgateway.dev的类型定义backend_types.go、GVK/GVR 注册wellknown/kgw.go、翻译插件extensions2/plugins/backend/、策略资源backend_config_policy_types.go以及配套示例examples/和 e2e 测试test/e2e/features/backends/均已就绪读者可以按上述示例直接上手配置与验证。赞分享API网关云原生微服务【免费下载链接】kgatewayThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/kg/kgateway点击查看免费下载相关推荐N_m3u8DL-RE 保姆级教程3 分钟下载 MPD/M3U8/ISM 流媒体附避坑清单N_m3u8DL RE 保姆级教程3 分钟下载 MPD/M3U8/ISM 流媒体附避坑清单 N_m3u8DL RE 是一款跨平台的流媒体下载工具专门处理CLI音视频kgateway 采纳 Kubernetes 式 Changelog 管理从 PR 描述生成 Release Notes 的设计与落地实践kgateway 采纳 Kubernetes 式 Changelog 管理从 PR 描述生成 Release Notes 的设计与落地实践 导读本文基于 kAPI网关云原生微服务云原生的定义从 Pivotal 到 CNCF 的演进脉络与 Kubernetes 生态中的落地实践云原生的定义从 Pivotal 到 CNCF 的演进脉络与 Kubernetes 生态中的落地实践 云原生Cloud Native是当前基础设施与软件架构教程云原生容器编排上一篇探索未来编程的新境界Skyvern AI 的 Skyvern 平台下一篇7大自由度开源机械臂OpenArm 2.0从硬件构建到AI部署的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kgateway 从 Upstream 到 Backend 的类型演进：对齐 Kubernetes Gateway API 语义的设计方案与实践落地
API网关云原生微服务【免费下载链接】kgatewayThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/kg/kgateway点击查看免费下载kgateway 的目标是成为基于 Kubernetes Gateway API 的厂商中立、开源 API 网关因此它需要逐步淘汰从 Gloo Gateway 继承的遗留类型。本文以设计提案 EP-10611 为主体完整解析将Upstream.kgateway.dev重命名为Backend.kgateway.dev的动机、两阶段 API 语义拆分后端类型与后端策略、与 K8s Gateway API 的对齐思路并结合当前仓库源码验证重命名落地后的真实 API 形态、配置示例与测试用例。读者读完将掌握 kgateway 后端资源Backend的来龙去脉、设计取舍以及当前可用的配置字段与示例。背景为什么需要重新审视Upstream类型kgateway 的核心定位是提供厂商中立、开源的 OSS API 网关底层基于 Kubernetes Gateway API。为此项目的主要工作方向之一是移除遗留的 Gloo Gateway 类型并重塑那些与 K8s Gateway API 语义和惯用法不一致的 Gloo Gateway API。Upstream.gloo.solo.io正是这样一个需要被重新审视的类型。它从 Gloo Gateway 直接继承而来其名称与概念在 Gloo Gateway 用户群体中根深蒂固但它的 API 形态与 K8s Gateway API 的语义并不完全吻合。在 Gloo Gateway以及当前 kgateway中Upstream这个资源实际上承载了两个不同层次的配置层次作用举例Backend type后端类型定义路由的目标routing destinationAWS Lambda 函数、GCP Cloud Run 服务、静态外部主机、K8s Service 等Backend policy后端策略描述与后端交互时的行为与后端类型无关mTLS 连接、TLS 证书配置等这两个层次在语义上截然不同却被塞进了同一个资源里。这正是后续拆分与重命名的根本原因。第一层语义Backend type用独立资源表达非 K8s 后端Backend type 允许用户定义路由的目标。常见后端类型包括AWS Lambda 函数GCP Cloud Run 服务静态外部主机K8s Service其中AWS Lambda 和 GCP Cloud Run 服务在 Kubernetes 中没有原生表示因此用独立的 CRD 资源来表达它们是合理且必要的。静态/外部主机在理论上可以通过 K8sService的ExternalName类型来表达但这一用法在 Gloo Gateway以及现在的 kgateway中并不被支持主要原因是用例需求不足同时ExternalNameService 本身存在一些使用上的注意事项例如 DNS 解析行为如果有可行的替代方案通常会倾向于避免使用它。因此使用独立的Upstream/Backend资源来定义外部主机同样是有意义的。其他项目也有类似的概念例如 Istio 的ServiceEntry类型用于声明服务网格外的流量入口。然而核心 K8sService本身已经能够表达集群内流量目标是一种合法的后端类型那么为什么 Gloo Gateway 的Upstream还要支持Service作为后端类型呢这个冗余的答案就藏在第二个语义层次——backend policy中。第二层语义Backend policy策略为何要挂在后端资源上Backend policy 是一个宽泛的概念大致描述与后端交互相关的行为它与后端的类型无关注意某些策略只适用于特定后端类型但总体原则不变。典型场景是 mTLS用户希望以 mTLS 方式连接后端就需要一种表达该策略的方式。在 Gloo Gateway 中Upstream类型就是用户配置这类策略的位置。以 mTLS 为例用户需要提供一个包含证书和密钥的Secret用于在与目标后端建立连接时完成 mTLS 握手。这种把“类型”和“策略”耦合在同一个资源里的设计正是与 K8s Gateway API 理念冲突的核心。与 K8s Gateway API 的差异策略应该独立挂载Upstream的名称和概念对 Gloo Gateway 用户来说耳熟能详但其现有 API 形态并不能完全契合 K8s Gateway API 的语义与惯用法。第一层——定义各种没有 K8s 原生表示的后端类型——在 K8s Gateway API 语境下依然相关且重要唯一的例外是不再需要支持原生Service因为 K8sService本身就是路由目标。事实上在 Gateway API 中定义一个自定义类型作为后端引用正是支持非 K8s 后端的核心扩展点extension point。第二层——backend policy——K8s Gateway API 则走向了完全不同的方向策略应表达为独立的资源通过“挂载attach”到目标对象上来增强与后端的交互这样无需修改后端类型的spec即可定义策略典型例证是 Gateway API 的BackendTLSPolicy类型——它专门为后端提供 TLS 策略而不触碰后端资源本身的定义。也就是说K8s Gateway API 将“后端是什么”与“如何与后端交互”彻底解耦。kgateway 的演进方向正是要顺应这一趋势。kgateway 现状一个名字上的遗留kgateway 目前有一个后端类型Upstream.kgateway.dev这个名称纯粹是从最初的 Gloo GatewayUpstream继承而来的遗留产物。但正如上文所述kgateway 希望让这个类型朝着 K8s Gateway API 的方向演进。这意味着 kgateway 的Upstream.kgateway.dev将拥有与Upstream.gloo.solo.io不同的语义并持续分化——两者实际上是不同的资源却共用了同一个名字。动机目标与非目标目标Goals就Upstreams.gloo.solo.io类型与 K8s Gateway API 语义之间的不兼容之处达成一致认识就表达后端目标的新kind名称达成一致。非目标Non-Goals不涉及Backend类型的具体设计或 API 形态的确定这是另一份独立 EP 的范畴。这份设计提案的边界非常清晰只解决“改名”与“语义对齐方向”两个问题不越界去设计具体的 API 细节。提案重命名为Backend.kgateway.dev本提案的核心内容是一句话将Upstream.kgateway.dev类型重命名为Backend.kgateway.dev。之所以这么做理由包括区分两种不同资源明确提示用户这是不同的资源、具有不同的语义减少 Gloo Gateway 老用户迁移到 kgateway 时的困惑也能降低他们翻到旧版 Gloo Gateway 文档、示例时产生的误解遵循 K8s Gateway API 的术语习惯在 Gateway API 语境中“backend” 就是表达“路由目标”的公认术语与核心路由原语保持一致Gateway API 的核心路由原语全部通过backendRefs来定义路由规则例如HTTPRoute中的HTTPBackendRef此外还有前述的BackendTLSPolicy为后端提供 TLS 策略——这些都以 “backend” 为统一命名附带收益——避免类型冲突当用户在同一集群中同时安装 Gloo Gateway 和 kgateway 进行迁移时重命名可以避免两个系统存在同名upstream类型。如果不改名CLI 或任何使用非限定名称的工具在与集群交互时都会遭遇糟糕的体验资源名冲突导致歧义。备选方案Alternatives设计过程中还评估过其他候选名称Upstream维持现状但与 Gloo Gateway 语义混淆被否决Destination语义偏路由目标未采用KUpstream带前缀的变体命名未采用。最终选择Backend因为它与 Gateway API 生态的术语体系完全一致。落地方案验证当前仓库中的Backend.kgateway.dev设计文档是提案层面的论述而当前仓库已经完整实现了这一重命名。从源码中可以清晰看到Backend.kgateway.dev的真实形态。1. API 类型定义在 backend_types.go 中定义了完整的Backend资源// kubebuilder:printcolumn:nameType,typestring,JSONPath.spec.type,descriptionWhich backend type? // kubebuilder:printcolumn:nameAccepted,typestring,JSONPath.status.conditions[?(.typeAccepted)].status,descriptionBackend configuration acceptance status // kubebuilder:printcolumn:nameAge,typedate,JSONPath.metadata.creationTimestamp,descriptionThe age of the backend. // genclient // kubebuilder:object:roottrue // kubebuilder:subresource:status type Backend struct { metav1.TypeMeta json:,inline metav1.ObjectMeta json:metadata,omitempty Spec BackendSpec json:spec Status BackendStatus json:status,omitempty }当前支持的BackendType枚举为见 backend_types.goAWSAWS Lambda / EC2 后端Static静态主机列表后端DynamicForwardProxy动态正向代理后端GCPGCP 服务后端PriorityGroups优先级组故障转移后端值得注意的一个演进信号BackendSpec中的Type字段已被标记为Deprecated注释明确说明“后端类型将从配置推断The backend type is inferred from the configuration”并通过 CEL 校验ExactlyOneOfaws;static;dynamicForwardProxy;gcp;priorityGroups来保证配置互斥见 backend_types.go。这正是“第一层语义类型”走向更符合 Gateway API 表达方式的体现——类型不再需要显式声明而是由后端配置本身推导。2. 资源标识GVK / GVR在 wellknown/kgw.go 中Backend已被正式注册为 kgateway 核心类型之一BackendGVK buildKgatewayGvk(Backend) BackendGVR BackendGVK.GroupVersion().WithResource(backends)即 API 组为gateway.kgateway.dev资源名为backends这与其核心类型TrafficPolicy、BackendConfigPolicy、ListenerPolicy等并列。3. 翻译插件实现后端从 CRD 到 Envoy 集群的翻译由 backend 插件完成位于 pkg/kgateway/extensions2/plugins/backend/其中包括aws.go、ec2.go、gcp.go、static.go、dfp.go、priority_groups.go等子实现。插件通过 KRT 集合krt.NewCollection监听Backend资源变化将其翻译为内部表示IR进而生成 Envoy 配置见 plugin.go。4. 策略分离BackendConfigPolicy重命名设计中最核心的理念——“策略独立于后端类型”——在当前仓库中已经通过BackendConfigPolicy落地。该类型定义在 backend_config_policy_types.go 中其targetRefs/targetSelectors的 CEL 校验明确要求引用三类目标之一K8sService、gateway.kgateway.dev的Backend或 IstioHostname见 backend_config_policy_types.go。也就是说策略不再写在后端资源内部而是作为独立资源挂载到后端上。这与提案中强调的 Gateway API 方向BackendTLSPolicy模式完全一致。BackendConfigPolicy支持的策略配置非常丰富常见字段包括connectTimeout建立新连接的超时tlsTLS origination 配置secretRef、sni、verifySubjectAltNames、insecureSkipVerify、alpnProtocols、simpleTLS控制是否默认启用 mTLS等loadBalancer负载均衡策略leastRequest、roundRobin、ringHash、maglev、random、healthyPanicThreshold、zoneAware等healthCheck主动健康检查HTTP 或 gRPCoutlierDetection被动健康检查连续 5xx 驱逐等circuitBreakers熔断阈值dnsDNS 刷新率与 jitterhttp1ProtocolOptions/http2ProtocolOptions/commonHttpProtocolOptions协议选项示例为 Service 后端配置熔断仓库中 example-backendconfigpolicy-circuit-breakers.yaml 展示了最直接的用法——把策略挂载到 K8sService上apiVersion: gateway.kgateway.dev/v1alpha1 kind: BackendConfigPolicy metadata: name: httpbin-cb namespace: default spec: targetRefs: - group: kind: Service name: httpbin circuitBreakers: maxConnections: 1000 maxPendingRequests: 500 maxRequests: 2000 maxRetries: 10示例为 Service 后端配置连接参数example-svc-with-attached-backend-config-policy.yaml 则展示了一个完整的场景HTTPRoute通过backendRefs指向example-svc而策略以独立资源BackendConfigPolicy挂载到同一个 ServiceapiVersion: gateway.kgateway.dev/v1alpha1 kind: BackendConfigPolicy metadata: name: example-svc-policy spec: targetRefs: - name: example-svc group: kind: Service connectTimeout: 5s perConnectionBufferLimitBytes: 1024注意这里的核心模式路由规则使用backendRefsGateway API 原生语义而策略通过targetRefs独立挂载——后端“类型”与后端“策略”完全分离正是 EP-10611 所追求的架构形态。5.Backend资源的使用示例test/e2e/features/backends/testdata/backend.yaml 给出了一个 Static 类型后端的完整 YAMLapiVersion: gateway.kgateway.dev/v1alpha1 kind: Backend metadata: name: nginx-static namespace: kgateway-base spec: type: Static static: hosts: - host: nginx.nginx-shared.svc # 静态引用共享的 nginx Service port: 8080对应的 e2e 测试位于 test/e2e/features/backends/suite.go其中TestConfigureBackingDestinationsWithUpstream测试案例会应用该 Backend 并通过网关发起请求验证路由可达性见 suite.go。测试方法名仍保留着历史命名痕迹但实际使用的资源已经是Backend。6. 从backendRefs引用Backend资源在 e2e 测试的 priority-groups.yaml 中可以清楚看到HTTPRoute如何通过backendRefs引用自定义Backend类型apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: priority-groups-route namespace: kgateway-base spec: parentRefs: - name: gateway hostnames: - failover.example.com rules: - backendRefs: - name: priority-groups kind: Backend group: gateway.kgateway.dev这印证了提案中“核心路由原语都通过backendRefs定义路由规则”的论断——Backend正是作为backendRefs中kind: Backend, group: gateway.kgateway.dev的合法引用目标存在的。演进后的延伸优先级组PriorityGroups后端作为重命名落地的直接产物kgateway 在后端能力上还扩展了PriorityGroups后端类型。相关设计见 design/13643-backend-priority-groups.md它允许在一个Backend上表达有序的故障转移组列表apiVersion: gateway.kgateway.dev/v1alpha1 kind: Backend metadata: name: priority-groups spec: priorityGroups: - backendRefs: # group 0主后端priority 0 - name: primary-nginx - backendRefs: # group 1故障转移priority 1 - name: failover-echo - name: failover-httpbin翻译时每个组映射为 Envoy 集群负载分配中的一个 priority 层级配合BackendConfigPolicy的主动健康检查驱动故障转移与自动恢复。这进一步说明Backend资源作为 Gateway API 的扩展点已经成为 kgateway 表达各类非 K8s 原生后端与复杂路由语义的统一载体。总结从命名到架构的语义对齐EP-10611 表面上是一次类型改名实质上是 kgateway 架构理念的一次关键对齐概念拆分将 Gloo GatewayUpstream中耦合的“后端类型”与“后端策略”两层语义彻底拆开命名对齐以 Gateway API 生态公认的Backend术语命名路由目标与backendRefs、BackendTLSPolicy等原语形成一致的命名体系策略独立通过BackendConfigPolicy等独立策略资源挂载到后端无需修改后端spec即可增强交互行为迁移友好同一集群共存 Gloo Gateway 与 kgateway 时不再因upstream同名造成 CLI 与工具链的 UX 困扰。从当前仓库源码来看这一设计已全面落地Backend.kgateway.dev的类型定义backend_types.go、GVK/GVR 注册wellknown/kgw.go、翻译插件extensions2/plugins/backend/、策略资源backend_config_policy_types.go以及配套示例examples/和 e2e 测试test/e2e/features/backends/均已就绪读者可以按上述示例直接上手配置与验证。赞分享API网关云原生微服务【免费下载链接】kgatewayThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/kg/kgateway点击查看免费下载相关推荐N_m3u8DL-RE 保姆级教程3 分钟下载 MPD/M3U8/ISM 流媒体附避坑清单N_m3u8DL RE 保姆级教程3 分钟下载 MPD/M3U8/ISM 流媒体附避坑清单 N_m3u8DL RE 是一款跨平台的流媒体下载工具专门处理CLI音视频kgateway 采纳 Kubernetes 式 Changelog 管理从 PR 描述生成 Release Notes 的设计与落地实践kgateway 采纳 Kubernetes 式 Changelog 管理从 PR 描述生成 Release Notes 的设计与落地实践 导读本文基于 kAPI网关云原生微服务云原生的定义从 Pivotal 到 CNCF 的演进脉络与 Kubernetes 生态中的落地实践云原生的定义从 Pivotal 到 CNCF 的演进脉络与 Kubernetes 生态中的落地实践 云原生Cloud Native是当前基础设施与软件架构教程云原生容器编排上一篇探索未来编程的新境界Skyvern AI 的 Skyvern 平台下一篇7大自由度开源机械臂OpenArm 2.0从硬件构建到AI部署的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 报考提示：本文涉及的批次、材料要求可能随上级文件调整，报名前建议再确认一次。你所在的工种、城市、当前进度如果拿不准，可以直接电话 18236992212 或在线预约，我们按你的情况单独捋一遍流程，不白跑。
