首页
学习
活动
专区
圈层
工具
发布
技术百科首页 >Gateway API >Gateway API 如何实现跨命名空间的流量路由?

Gateway API 如何实现跨命名空间的流量路由?

词条归属:Gateway API

1. allowedRoutes 控制绑定范围

  • Gateway 监听器通过 allowedRoutes 限定可绑定的命名空间来源(如 Same、Selector、All),默认仅接受同命名空间路由,防止未授权暴露。

2. ReferenceGrant 授权跨命名空间引用

  • 当某命名空间的 Route 需要引用另一个命名空间的后端 Service 时,目标命名空间必须存在对应的 ReferenceGrant,显式授权该引用。
  • ReferenceGrant 通过 from(引用方 group/kind/namespace)与 to(被引用方 group/kind/name)描述授权关系,是 Gateway API 跨命名空间安全模型的基石,缺失授权时跨命名空间后端引用会被拒绝。
相关文章
再见 Ingress!Kubernetes 流量管理新利器来了!
Gateway API 是 Kubernetes 中定义集群入口流量规则的下一代 API 规范,旨在替代传统 Ingress,提供更丰富、灵活且可扩展的流量管理能力,是 Kubernetes 生态向现代化网络架构演进的关键一步。
民工哥
2026-03-24
6950
Kubernetes Gateway API
初始的 Kubernetes 内部服务向外暴露,使用的是自身的 LoadBlancer 和 NodePort 类型的Service,在集群规模逐渐扩大的时候,这种 Service 管理的方式满足不了我们的需求,比如 NodePort 需要大量的端口难以维护,多了一层NAT,请求量大会对性能有影响;LoadBlancer 需要每个 Service 都有一个外部负载均衡器。接着 Kubernetes 提供了一个内置的资源对象 Ingress API 来暴露 HTTP 服务给外部用户,它的创建是为了标准化的将 Kubernetes 中的服务流量暴露给外部,Ingress API 通过引入路由功能,克服了默认服务类型 NodePort 和 LoadBalancer 的限制。在创建 Ingress 资源的时候通过 IngressClass 指定该网关使用的控制器,主要是靠 Ingress 控制器不断监听 Kubernetes API Server 中 IngressClass 以及 Ingress 资源的的变动,配置或更新入口网关和路由规则。IngressClass实现了网关与后台的解耦,但也有着很多的局限性。Ingress 配置过于简单,只支持 http 和 https 协议的服务路由和负载均衡,缺乏对其他协议和定制化需求的支持,而且 http 路由只支持 host 和 path 的匹配,对于高级路由只能通过注解来实现,当然这取决于 Ingress 控制器的实现方式,不同的 Ingress 控制器使用不同的注解,来扩展功能,使用注解对于 Ingress 的可用性大打折扣;路由无法共享一个命名空间的网关,不够灵活;网关的创建和管理的权限没有划分界限,开发需要配置路由以及网关。当然也有很多第三方的网关组件,例如 istio 和 apisix 等,提供了丰富的流量管理功能,如负载均衡、动态路由、动态 upstream、A/B测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等,还可以处理南北流量以及服务之间的东西向流量。对外提供路由功能,对内提供流量筛选,已经很好的满足了当下网络环境的所有需求。但对于小集群来说,这两个网关的部署成本有点高;而且太多类型的网关,不同的配置项、独立的开发接口、接口的兼容性、学习成本、使用成本、维护成本以及迁移成本都很高。急需一种兼容所有厂商 API 的接口网关。所以应运而生,Kubernetes 推出了 Gateway API。Gateway API 是 Kubernetes 1.19 版本引入的一种新的 API 规范,会成为 Ingress 的下一代替代方案。它有着 Ingress 的所有功能,且提供更丰富的功能,它支持更多的路由类型选择,除了 http路由外,还支持 tcp 以及 grpc 路由类型;它通过角色划分将各层规则配置关注点分离,实现规则配置上的解耦;并提供跨 namespace 的路由与网关支持使其更适应多云环境等。与 Ingress Api 工作类似的,Gateway Controller 会持续监视 Kubernetes API Server 中的 GatewayClass 和 Gateway 对象的变动,根据集群运维的配置来创建或更新其对应的网关和路由。API 网关、入口控制器和服务网格的核心都是一种代理,目的在于内外部服务通信。更多的功能并不等于更好的工具,尤其是在 Kubernetes 中,工具的复杂性可能是一个杀手。
政采云前端团队
2023-09-01
2K0
使用Linkerd实现流量管理:学习如何使用Linkerd的路由规则来实现流量的动态控制
🎉大家好!猫头虎博主回来了!在当今微服务的盛行时代,流量管理成为了服务运维的关键环节。而Linkerd,作为一个轻量级的服务网格,为我们提供了简单而强大的流量管理工具。在这篇文章中,我将为大家详细展示如何使用Linkerd的路由规则来实现流量的动态控制,从而提高应用的可用性和灵活性。对于关心服务网格、流量控制和Linkerd的 技术 的朋友们,这篇文章将带给你前所未有的启示!🚀
猫头虎
2024-04-09
6330
Kubernetes Service APIs 介绍
Kubernetes 服务 APIs(Service APIs)是由 SIG-NETWORK 社区管理的开源项目,项目地址:https://github.com/kubernetes-sigs/service-apis。该项目的目标是在 Kubernetes 生态系统中发展服务网络 API,服务 API 提供了暴露 Kubernetes 应用的接口-- Services、Ingress 等。
我是阳明
2021-01-04
1.5K0
了解下 Kuberentes Gateway API
在 Kubernetes 集群边缘对外提供网络服务的时候,通常需要借助 Ingress 对象,这个对象提供了暴露 Service 所必须的核心要素,例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候,往往会有更多的具体需求,这时 Ingress 对象所提供的核心功能就有些力不从心了,各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解,来完成对 Ingress 特定行为的控制,完成各自的个性化功能,例如认证、路径变更、黑白名单等,这就让 Ingress 对象变成了一个奇怪的东西:结构化的核心结构,和非结构化的标注结合起来形成各种 Ingress 方言,并且后期还出现了 Traefik Middleware 这样的 CRD 配置,这给 Ingress 功能的集中管理造成了一个较大的困扰;另外 Ingress 中可以随意定制主机名、路径以及后端服务,也给共享集群的用户造成了一定的安全隐患。包括 Contour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达,客观上也让 Ingress 世界更为分裂。
张善友
2022-09-23
5780
点击加载更多
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
领券