- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
第一阶段:Service 。
初始的 Kubernetes 内部服务向外暴露,使用的是自身的 LoadBlancer 和 NodePort 类型的 Service.
在集群规模逐渐扩大的时候,这种 Service 管理的方式满足不了我们的需求.
第二阶段:Ingress 。
接着 Kubernetes 提供了一个内置的资源对象 Ingress API 来暴露 HTTP 服务给外部用户.
Ingress 的创建,是为了标准化的将 Kubernetes 中的服务流量暴露给外部,Ingress API 通过引入路由功能,克服了默认服务类型 NodePort 和 LoadBalancer 的限制.
在创建 Ingress 资源的时候通过 IngressClass 指定该网关使用的控制器,主要是靠 Ingress 控制器不断监听 Kubernetes API Server 中 IngressClass 以及 Ingress 资源的的变动,配置或更新入口网关和路由规则.
IngressClass 实现了网关与后台的解耦,但也有着很多的局限性.
当然也有很多第三方的网关组件,例如 istio 和 apisix 等。它们提供了丰富的流量管理功能,如负载均衡、动态路由、动态 upstream、A/B测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等,还可以处理南北流量以及服务之间的东西向流量。对外提供路由功能,对内提供流量筛选,已经很好的满足了当下网络环境的所有需求。但对于小集群来说,这两个网关的部署成本有点高,而且太多类型的网关,不同的配置项、独立的开发接口、接口的兼容性、学习成本、使用成本、维护成本以及迁移成本都很高.
第三阶段:Gateway API 。
这种情况下,就急需一种兼容所有厂商 API 的接口网关,所以 Kubernetes 推出了 Gateway API.
Gateway API 是 Kubernetes 1.19 版本引入的一种新的 API 规范,会成为 Ingress 的下一代替代方案。主要原因是 Ingress 资源对象不能很好的满足网络需求,很多场景下 Ingress 控制器都需要通过定义 annotations 或者 crd 来进行功能扩展,这对于使用标准和支持是非常不利的,新推出的 Gateway API 旨在通过可扩展的面向角色的接口来增强服务网络.
Gateway API(之前叫 Service API)是由 SIG-NETWORK 社区管理的开源项目,项目地址:https://gateway-api.sigs.k8s.io/.
Gateway API 有着 Ingress 的所有功能,且提供更丰富的功能.
与 Ingress Api 工作类似的,Gateway Controller 会持续监视 Kubernetes API Server 中的 GatewayClass 和 Gateway 对象的变动,根据集群运维的配置来创建或更新其对应的网关和路由.
其实,API 网关、入口控制器和服务网格的核心都是一种代理,目的在于内外部服务通信.
当前版本 。
Gateway API 目前的最新版本是 v1.1(2024年6月).
此版本将服务网格和 GRPCRoute 的支持从实验阶段转移到了标准通道,意味着这些功能现在是一般可用(GA)状态.
还引入了会话持久性和客户端证书验证等新的实验性特性,增强了 Gateway API 的功能范围.
v1.1 版本的发布标志着四个关键特性从实验阶段变成了稳定版,这表明对 API 的稳定性有了足够的信心,并且会提供向后兼容性的保证.
Gateway API 发展时间还是比较短的,相信随着时间的推进,Gateway API 的各方面功能将不断完善,以应对不同场景的需求。包括性能、扩展性、传输过程中的加密和身份验证等.
适用场景 。
主要有以下几个应用场景:
目前 Gateway API 还处于开发阶段,尽管 Gateway API 还不算成熟和稳定,但由于其强大的功能和作为 Kubernetes 官方项目的影响力,已经获得大量项目的支持和兼容.
例如 Apache APISIX,它来实现高性能、高可用性的 API 网关,通过 Gateway API 实现请求路由、安全认证、限流等功能。同时,Apache APISIX 还支持灰度发布、集群管理和插件机制等特性,可以满足大部分企业级 API 网关的需求.
Gateway API 是 Kubernetes 中的一个 API 资源集合,包括 GatewayClass、Gateway、HTTPRoute、TCPRoute、Service 等,这些资源共同为各种网络用例构建模型.
其中最主要有三种对象类型:GatewayClass、Gateway、Route,下文将逐一简单介绍下.
GatewayClass 定义了一组共享配置和行为的 Gateway,GatewayClass 是一个集群范围的资源,必须至少定义一个 GatewayClass,Gateway 引用该 GatewayClass 才能够生效.
每个 GatewayClass 必须关联一个控制器 Controller ,控制器可以处理多个 GatewayClass。控制器 Controller 作用就是持续监视 Kubernetes API Server 中的 GatewayClass 和 Gateway 对象的变动,创建或更新其对应的网关和路由配置.
通俗讲 GatewayClass 就是一类 Gateway 的集合的入口,Gateway 想要实现转发必须要关联到某一个 GatewayClass 上,而 GatewayClass 也需要关联到一个网关控制器 Controller,控制器可以监听 API Server 资源中 GatewayClass 以及 Gateway 的变化.
比如 Istio、Traefik、Apisix 等根据 Gateway Api 的标准和要求,实现了一个 Controller,能够让 Gateway 依赖 GatewayClass 创建对应的网关.
一般 GatewayClass 不需要人工手动创建,参与支持 Gateway Api 工程的第三方网关组件安装时会自动创建.
GatewayClass 与控制器 Controller 使用 spec.controllerName 关联.
下面是一个最精简的 GatewayClass 示例:
apiVersion: gateway.networking.k8s.io/v1 # 指定了使用的 API 版本,v1:第一个稳定版本
kind: GatewayClass # 资源类型为 GatewayClass
metadata: # 包含资源的元数据信息
name: example-class # 指定了 GatewayClass 的名称,这个名称在集群中应该是唯一的
spec: # 指定 GatewayClass 的具体配置
controllerName: example.com/gateway-controller # 指定与该 GatewayClass 相关联的控制器名称
Gateway 负责外部请求到集群内的流量接入,以及往后转发,定义了对特定负载均衡器配置的请求.
Gateway 实现了 GatewayClass 配置和行为的约定,该资源可以由运维人员直接创建,也可以由处理 GatewayClass 的控制器创建.
Gateway 资源是一个中间层,需要定义所要监听的端口、协议、TLS 配置等信息,可以将网络流量的管理和控制集中到一个位置,提高集群的可用性和安全性.
配置完成后,由 GatewayClass 绑定的 Controller 为我们提供一个具体存在的 Pod 作为流量入口.
下面是一个精简的 Gateway 资源示例:
apiVersion: gateway.networking.k8s.io/v1 # 指定了使用的 API 版本
kind: Gateway # 定义了资源类型为 Gateway
metadata: # 包含了资源的元数据信息
name: example-gateway # 指定了 Gateway 的名称,在集群中应该是【唯一】的
spec: # 指定了 Gateway 的具体配置
gatewayClassName: example-class # 指定了这个 Gateway 所属的 GatewayClass 名称,必填
listeners: # 定义了一个或多个监听器,每个监听器代表一种协议和一个端口号,必填
# name 指定了监听器的名称,在 Gateway 中应该是【唯一】的
# 未指定时,匹配所有主机名。对于不需要基于主机名匹配的协议,此字段将被忽略
- name: http # 指定了监听器的名称,在 Gateway 中应该是【唯一】的
hostname: www.gateway.*.com # 定义一个域名,一般为泛域名、匹配来自该域名的流量
protocol: HTTP # 指定了监听器使用的协议
port: 80 # 指定了监听器使用的端口号
allowedRoutes: # 定义了允许哪些路由通过该监听器
namespaces: # 指定了允许路由的命名空间范围
from: All # All 表示允许所有命名空间
- name: https
protocol: HTTPS # 协议为 https
port: 81
allowedRoutes:
namespaces:
from: All
tls: # 为 HTTPS 配置加密协议
mode: Terminate # 加密协议类型,Terminate 或 Passthrough
certificateRefs: # 定义了一个或多个证书引用,用于验证服务器身份
- kind: Secret # 指定了证书引用的类型
name: cafe-secret # 指定了证书引用的名称
namespace: default # 指定了证书引用所在的命名空间
addresses: # 定义了一个或多个地址,用于接收流量
- value: "192.168.1.1" # 指定了 IP 地址的值
type: IPAddress # 指定了地址的类型
在此示例中,若未指定 addresses 字段,则对应实现的控制器负责将地址或主机名设置到 Gateway 之上。该地址用作网络端点,用于处理路由中定义的后端网络端点的流量.
Addresses:定义为此 Gateway 请求的网络地址。用于指定该 Gateway 可以通过哪些网络地址访问的,此字段非必填。Addresses 字段表示外部流量将使用的“Gateway 外部”的地址,该流量绑定到此网关的地址。这可以是外部负载均衡器或其他网络基础架构的 IP 地址或主机名,或者其他一些流量将被发送到的地址.
两个加密协议类型:
不同的监听器协议,支持不同的 TLS 模式和路由类型:
监听器协议 | TLS 模式 | 路由类型 |
TLS | Passthrough | TLSRoute |
TLS | Terminate | TCPRoute |
HTTPS | Terminate | HTTPRoute |
ReferenceGrant 可用于在 Gateway API 中启用跨命名空间引用。特别的,Router 可能会将流量转发到其他命名空间中的后端,或者 Gateway 可能会引用另一个命名空间中的 Secret.
如果从其命名空间外部引用一个对象,则该对象的所有者必须创建一个 ReferenceGrant 资源以显式允许该引用,否则跨命名空间引用是无效的。ReferenceGrant 由两个列表组成,一个是引用来源的资源列表,另一个是被引用的资源列表.
以下示例,显示命名空间 foo 中的 HTTP 路由如何引用命名空间 bar 中的服务。在此示例中,bar 命名空间中的引用授予明确允许从 foo 命名空间中的 HTTP 路由引用服务.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: cross-namespace-tls-gateway
namespace: gateway-api-example-ns1
spec:
gatewayClassName: istio
listeners:
- name: https
protocol: HTTPS
port: 443
hostname: "*.cai-inc.com"
tls:
mode: Terminate
certificateRefs:
- kind: Secret
group: ""
name: allow-ns1-gateways-to-ref-secrets
namespace: gateway-api-example-ns2
---
apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
name: allow-ns1-gateways-to-ref-secrets
namespace: gateway-api-example-ns2
spec:
from:
- group: gateway.networking.k8s.io
kind: Gateway
namespace: gateway-api-example-ns1
to:
- group: ""
kind: Secret
一个 Gateway 可以包含一个或多个 Route 引用,每个 Route 都要绑定一个 Gateway.
这些 Route 的作用是将一个子集的流量引导到一个特定的服务上.
目前支持 4 种路由类型:HTTPRoute、TLSRoute、TCPRoute、GRPCRoute.
HTTPRoute 适用于多路复用 HTTP 或 HTTPS 请求,并使用 HTTP 请求进行路由或修改的场景,比如使用 HTTP Headers 头进行路由,url路径的重定向或者重写,灰度发布涉及权重等.
HTTPRoute 的配置示例如下:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: httproute-example
spec:
parentRefs: # 定义此路由要绑定到的 Gateway
- name: gateway-istio
hostnames:
- "zcy.cai-inc.com"
rules:
- matches: ## 前缀为 monitor 的服务转发到后端 monitor-center 的6099端口
- path:
type: PathPrefix
value: /monitor
# 指定后端服务的引用,它包含一个后端服务的列表,每个服务由名称和端口号组成
# 可以使用不同的负载均衡算法,将请求路由到后端服务的其中一个实例中,实现负载均衡
# 如果未指定后端列表,则规则不进行转发
backendRefs:
- name: monitor-center1 ## 90%的流量转发给monitor-center1
port: 6099
weight: 90
- name: monitor-center2
port: 6099
weight: 10
# 由一个或多个匹配条件组成,这些匹配条件可以基于HTTP请求的各种属性进行匹配
# (如请求method方法、path路径、headers头部、queryParams查询参数等)
# 从而确定哪些请求应该被路由到该规则对应的后端服务
- matches: ## 请求头包含 env=prod 前缀为 /api2/otel 的服务转发到 otel-dashboard 的7099
- headers: ## Exact 精确匹配,也可以使用支持 POSIX、PCRE 或正则表达式
- name: env
type: Exact
value: prod
path:
type: PathPrefix
value: "/api2/otel"
# 对传入请求进行更细粒度的控制,定义了必须在请求或响应生命周期中完成的处理步骤
# 例如修改请求的头部、转发请求到其他服务、将请求重定向到不同的 URL 等
# 它们由一组规则组成,每个规则都包含一个或多个过滤器
# 这些过滤器可以在请求被路由到后端服务之前或之后进行处理,以实现各种不同的功能
filters:
- type: RequestHeaderModifier ## 请求头添加 cookie=test1
requestHeaderModifier:
add:
- name: cookie
value: test1
# - type: RequestHeaderModifier ## 请求头修改已存在的 cookie=test2
# requestHeaderModifier:
# set:
# - name: cookie
# value: test2
# - type: RequestHeaderModifier ## 删除请求头 cookie
# requestHeaderModifier:
# remove: ["cookie"]
- type: ResponseHeaderModifier ## 添加响应头
responseHeaderModifier:
add:
- name: X-Header-Add-1
value: header-add-1
- name: X-Header-Add-2
value: header-add-2
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
backendRefs:
- name: otel-dashboard
port: 7099
其中,关于 hostnames:
定义用于匹配 HTTP 请求的主机头的主机名列表,当请求匹配主机名时,将选择 HTTPRoute 执行请求路由。主机名是由 RFC 3986 定义的网络主机的完全限定域名,但要注意的是:不允许使用 IP;禁止使用端口;可以使用通配符标签(*)前缀,但通配符标签必须单独出现作为第一个标签;如果未指定主机名,则匹配所有绑定在 Gateway 上的路由.
当 Gateway 的 Listener 和 HTTPRoute 中都指定了主机名,只有有交集的主机名才会绑定到 Listener,没有绑定的 HTTPRoute 的 RouteParentStatus 中 Accepted 为 False 状态.
如果多个 HTTPRoute 指定重叠的主机名(例如,通配符匹配和精确匹配主机名重叠),则优先给予最长匹配主机名字符数的 HTTPRoute 的规则。 。
TLSRoute 用于 TLS 连接,通过 SNI 进行区分,它适用于希望使用 SNI 作为主要路由方法的地方,并且对 HTTP 等更高级的协议不感兴趣,连接的字节流不经任何检查就被代理到后端。它的配置和 HTTPRoute 类似,不同点在于 rules 的配置中只有 backendRefs, 没有 matches 和 filters,官网对 TLSRoute 介绍不多,可能建议 tls 统一配置在 Gateway 处,详情请看上面 3.1.2 Gateway 中的 tls 相关配置.
注:SNI(Server Name Indication)是 TLS 协议的一种扩展,用于在 TLS 握手过程中传递服务器的域名信息.
TCPRoute(和 UDPRoute)可以根据目的 IP 地址、目的端口号和协议等匹配规则来确定流量,将 TCP 流量动态路由到符合应用需求的后端服务上.
完成 TCPRoute 路由的配置,需要在绑定的 Gateway listeners.protocol 配置为 TCP.
Gateway 中的 listeners.name 与 TCPRoute 的 parentRefs.sectionName 绑定区分后端的服务 service。通过这种方式,每个 TCP 路由将自身绑定到网关上的不同端口,以便 Gateway.listeners.name --> TCPRoute.parentRefs.sectionName --> service 从集群外部获取端口 XXX 的流量。它的配置和 TLSRoute 类似,与 HTTPRoute 相比 rules 的配置中只有 backendRefs,没有 matches 和 filters.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: tcp-gateway
spec:
gatewayClassName: istio
listeners:
- name: foo # 与 TCPRoute sectionName 绑定
protocol: TCP # tcp 协议
port: 8080
allowedRoutes: # 绑定为 TCPRoute
kinds:
- kind: TCPRoute
- name: bar
protocol: TCP
port: 8090
allowedRoutes:
kinds:
- kind: TCPRoute
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: tcp-app-1
spec:
parentRefs:
- name: tcp-gateway
sectionName: foo # 对应 Gateway 的 listeners.name
rules:
- backendRefs:
- name: foo-service
port: 6000
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: tcp-app-2
spec:
parentRefs:
- name: tcp-gateway
sectionName: bar
rules:
- backendRefs:
- name: bar-service
port: 6000
GRPCRoute 用于路由 gRPC 请求,包括按主机名、gRPC 服务、gRPC 方法或 HTTP/2 头匹配请求的能力.
支持 GRPCRoute 的网关需要支持 HTTP/2,否则报错不支持的协议“UnsupportedProtocol”.
虽然可以通过 HTTPRoute 或自定义的 CRD 来路由 gRPC,但从长远来看,这会导致生态系统的碎片化.
gRPC 是一种业界广泛采用的流行 RPC 框架,该协议在 k8s 项目本身中被广泛地应用于许多接口,由于 gRPC 在 k8s 项目和应用层网络中的重要性,因此不允许过度细分,强制规定使用 GRPCRoute 来路由 gRPC.
支持 GRPC 路由的实现必须强制 GRPCRoute 和 HTTPRoute 之间 hostnames 的唯一性。如果 HTTP 路由或 GRPC 路由类型的路由 A 附加到 Gateway Listener,并且该 Listener 已经绑定了其他类型的另一个路由 B,并且 A 和 B 的 hostnames 交集非空,则路由 A 不会实现,建议对 gRPC 和非 gRPC HTTP 流量使用不同的主机名.
GRPCRoute 与 HTTPRoute rules 规则基本一致,定义了基于条件匹配 matches、过滤器 filters 以及将请求转发到后端 backendRefs。不同点在于 GRPCRoute.rules.matches 只支持 method 和 headers,headers参数为数组类型,method 参数为非数组。method 和 headers 匹配只支持精确匹配 Exact 和正则匹配 RegularExpression,且不能包含 / 字符。GRPCRoute.rules.filters 中不支持 url 重定向以及重写.
注:RPC(Remote Procedure Call)即远程过程调用,是一种网络通信协议,用于实现分布式系统中不同计算机之间的函数或方法调用 。
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: GRPCRoute
metadata:
name: grpcroute
spec:
parentRefs: # 绑定 Gateway
- name: gateway-istio
hostnames: # 绑定主机名
- my.example.com
rules:
- matches:
- method: # 包含 com.example.User.Login 方法且头部包含 version: "2"
service: com.example.User
method: Login
headers:
- type: Exact
name: version
value: "2"
backendRefs: # 不配置则不会转发
- name: foo-svc
port: 50051
- matches: # 包含 grpc.reflection.v1.ServerReflection 方法添加请求头 my-header:bar
- method:
service: grpc.reflection.v1.ServerReflection
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
add:
- name: my-header
value: bar
backendRefs:
- name: bar-svc1
port: 50052
weight: 90
- name: bar-svc2
port: 50052
weight: 10
Gateway API 支持跨 Namespace 路由 Route,网关 Gateway 和路由 Route 可以部署到不同的命名空间中.
路由可以跨 Namespace 边界绑定到网关的能力需要 Gateway 和 Route 双方协商同意。Route 和 Gateway 资源具有内置的控制,以允许或限制它们之间如何相互选择。当 Route 绑定到 Gateway 时,代表应用在 Gateway 上配置了底层的负载均衡器或代理.
一个 Kubernetes 集群管理员在 Infra 命名空间中部署了一个名为 shared-gw 的 Gateway,供不同的应用团队使用,以便将其应用暴露在集群之外。团队 A 和团队 B(分别在命名空间 "A" 和 "B" 中)将他们的 Route 绑定到这个 Gateway。它们互不相识,只要它们的 Route 规则互不冲突,就可以继续隔离运行。团队 C 有特殊的网络需求(可能是性能、安全或关键性),他们需要一个专门的 Gateway 来代理他们的应用到集群外。团队 C 在 "C" 命名空间中部署了自己的 Gateway dedicated-gw,该 Gateway 只能由 "C" 命名空间中的应用使用。不同命名空间及 Gateway 与 Route 的绑定关系如下图所示:
网关和路由的绑定是双向的:只有网关所有者和路由所有者都同意绑定才会成功.
这种双向关系存在的原因有两个:
网关支持管理路由来源约束,使用 listeners 字段限制可以附加的路由。 网关支持命名空间和路由类型作为附加约束,不符合附加约束的任何路由都无法附加到该网关上。 路由通过父引用字段 parentRefs 显式引用它们要附加到的网关.
这些共同创建了一个协议,使基础设施所有者和应用程序所有者能够独立定义应用程序如何通过网关公开,有效地降低了管理开销。如何将路由与网关绑定:
将路由附加到网关的简单步骤:
总之,网关选择路由,路由控制它们的暴露。当网关选择一个允许自己暴露的路由时,那么该路由将与网关绑定。当路由与网关绑定时,意味着它们的集体路由规则被配置在了由该网关管理的底层负载均衡器或代理服务器上.
Gateway 根据 Route 元数据、Route 资源的种类、命名空间和标签来选择 Route。Route 实际上被绑定到 Gateway 中的监听器上,因此每个监听器都有一个 listeners.allowedRoutes 字段,它通过以下一个或多个标准来选择 Route:
其中,namespaces.from 支持三种可能的值:
下面的 Gateway 将在集群中的所有 Namespace 中选择 otel: true 的所有 HTTPRoute 资源.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: gatewayDemo
namespace: gateway-istio
spec:
gatewayClassName: istio
listeners:
- name: http
port: 80
protocol: HTTP
allowedRoutes:
kinds:
- kind: HTTPRoute
namespaces:
from: Selector
selector:
matchLabels:
otel: "true"
---
apiVersion: v1
kind: Namespace
metadata:
name: routeDemo-example
labels:
otel: "true"
---
# HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: routeDemo
namespace: routeDemo-example
spec:
parentRefs:
- kind: Gateway
name: gatewayDemo
namespace: gateway-istio
rules:
- backendRefs:
- name: otel
port: 7099
GatewayClass、Gateway、xRoute 和 Service 的组合将定义一个可实现的负载均衡器。下图说明了不同资源之间的关系.
使用反向代理实现的网关的典型客户端/网关 API 请求流程如下所示:
客户端向 http://foo.example.com 发出请求 DNS 将域名解析为 Gateway 网关地址 反向代理在监听器上接收请求,并使用 Host Header 来匹配 HTTPRoute (可选)反向代理可以根据 HTTPRoute 的匹配规则进行路由 (可选)反向代理可以根据 HTTPRoute 的过滤规则修改请求,即添加或删除 headers 最后,反向代理根据 HTTPRoute 的 forwardTo 规则,将请求转发给集群中的一个或多个对象,即服务.
Gateway API 的面向角色特性就是,通过角色划分将各层规则配置关注点分离,实现规则配置上的解耦.
基础设施都是为了共享而建的,共享基础设施有一个共同的挑战,那就是如何为基础设施用户提供灵活性的同时还能被所有者控制。Gateway API 通过面向角色的设计来实现这一目标,通过将资源对象分离,实现配置上的解耦,可以由不同的角色的人员来管理,平衡了灵活性和集中控制,解决了入口网关创建与管理职责界限的划分.
不同角色的配合如下图:
GatewayClass 资源是集群统一部署的,由平台提供,后续才需要其他角色的介入,如下图:
一个集群管理员(Cluster Operator)创建了从 GatewayClass 派生的 Gateway 资源:foo。该 Gateway 对访问 foo.example.com 的流量进行了统一的 TLS 配置并设置了默认策略(Default Policies).
在和集群管理员达成一致后,负责存储的开发人员(Store Developer)创建了一个 HTTPRoute,将访问 foo.example.com/store/ 的流量导入到 Store namespace 下的 foo-store 服务中,并且对这些流量进行了加权分发,将 90%的流量导入到 foo-store v1 中,另外 10%的流量导入到 foo-store v2 中.
另外一边,负责网站的开发人员(Site Developer)也创建了一个 HTTPRoute,将访问 foo.example.com/site/ 的流量导入到 Site namespace 下的 foo-site 服务中.
Store 和 Site 团队在他们自己的 namespaces 中运行,但是将他们的 Routes 绑定到同一个共享 Gateway,允许他们独立控制自己的路由逻辑.
这种用户模型在为基础设施提供灵活性的同时也保证了对不同角色之间的控制.
目前已经有很多 Gateway API 的控制器实现方案了,比如 Contour、Google Kubernetes Engine、Istio、Traefik 等等.
关于如何实现,本文将不再介绍,可参考以下参考链接.
参考:https://cloud.tencent.com/developer/article/2321881 https://zhuanlan.zhihu.com/p/627229130 。
https://docs.youdianzhishi.com/k8s/network/gateway-api/ https://kubernetes.io/zh-cn/docs/concepts/services-networking/gateway/ 。
最后此篇关于k8s中的GatewayAPI的背景和简介【k8s系列之四】的文章就讲到这里了,如果你想了解更多关于k8s中的GatewayAPI的背景和简介【k8s系列之四】的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
目录 一、前言 二、『Echarts』简介 1. 什么是『Echarts』 三、数据可视化 四、『Echarts』
Go语言最主要的特性 复制代码 代码如下: 自动垃圾回收 更丰富的内置类型 函数多返回值 错误处理 匿名函数和闭包 类型和接口 并发编程 反射 语言交互性
在ASP中,FSO的意思是File System Object,即文件系统对象。 我们将要操纵的计算机文件系统,在这里是指位于web服务器之上。所以,确认你对此拥有合适的权限。理
Java是由Sun Microsystems公司于1995年5月推出的Java面向对象程序设计语言和Java平台的总称。由James Gosling和同事们共同研发,并在1995年正式推出。 Ja
C# 是一个现代的、通用的、面向对象的编程语言,它是由微软(Microsoft)开发的,由 Ecma 和 ISO 核准认可的。 C# 是由 Anders Hejlsberg 和他的团队在 .Net
SQL 是一门 ANSI 的标准计算机语言,用来访问和操作数据库系统。SQL 语句用于取回和更新数据库中的数据。SQL 可与数据库程序协同工作,比如 MS Access、DB2、Informix、M
什么是Apache Storm? Apache Storm是一个分布式实时大数据处理系统。Storm设计用于在容错和水平可扩展方法中处理大量数据。它是一个流数据框架,具有最高的摄取率。虽然Storm
SQLite 简介 本教程帮助您了解什么是 SQLite,它与 SQL 之间的不同,为什么需要它,以及它的应用程序数据库处理方式。 SQLite是一个软件库,实现了自给自足的、无服务器的、零配置的
简介 介绍 很高兴能向大家介绍 Gradle,这是一个基于 JVM 的富有突破性构建工具。 它为您提供了: 一个像 ant 一样,通用的灵活的构建工具 一种可切换的,像 maven
hystrix介绍 Hystrix 供分布式系统使用,提供延迟和容错功能,隔离远程系统、访问和第三方程序库的访问点,防止级联失败,保证复杂的分布系统在面临不可避免的失败时,仍能有其弹性。 hyst
设计模式(Design pattern)是重构解决方案 这点很重要,尤其是现在 B/S 一统天下的局面,过早考虑设计模式,得不偿失 设计模式(Design pattern)代表了最佳的实
Ruby 是一种纯粹的面向对象编程语言。 Ruby 由日本的松本行弘(まつもとゆきひろ/Yukihiro Matsumoto)创建于1993年。 Ruby 是 "程序员的最佳朋友&quo
OWL设计的初衷是处理 web 信息 学习 OWL 之前应具备的基础知识 OWL是基于 XML 和 RDF,所以,在我们开始学习 OWL 之前,希望你对 XML、XML 命名空间以及 RDF 有基
资源描述框架(RDF)是用于描述网络资源的 W3C 标准, 比如网页的标题、作者、修改日期、内容以及版权信息 你应当具备的基础知识 在继续学习之前,我们希望你对下面的知识有基本的了解 HT
Perl 像 C 一样强大,像 awk、sed 等脚本描述语言一样方便 Perl 又名实用报表提取语言, 是 Practical Extraction and Report Language 的缩写
AWK是一个命令行工具,它和其它的 Unix/Linux 命令行工具,比如 curl 和 wget 一样,没有界面。 AWK是一门语言,对的,一门语言,而且是一个解释性编程语言。 AWK设计之初就
WSDL 是基于 XML 的用于描述 Web Services 以及如何访问 Web Services 的语言 学习 WSDL 之前应当具备的基础知识 在继续学习之前,我们希望你对下面的知识有基本
我们提供了 Web 版的 JSON 编辑器,你可以依托于我们的 Web 编辑器编辑 JavaScript 代码,然后通过点击一个按钮来查看结果 <!DOCTYPE html> <h
SVG是使用 XML 来描述二维图形和绘图程序的语言, SVG 画出来的图形具有可伸缩不失真的特性 学习之前应具备的基础知识: 继续学习之前,我们应该对以下内容有基本的了解,这样更能方便你了解一些
XML设计的初衷是用来传输和存储数据 继续学习 XML 教程前应该掌握的基础知识 在我们继续学习 XML 之前,希望你对知识有基本的了解 1、 HTML; 2、 JavaScript; 如果你
我是一名优秀的程序员,十分优秀!