一文搞懂 Kubernetes Gateway API 的 Policy Attachment 关注我们（本文阅读时间：1

关注我们
（本文阅读时间：10分钟）
在《SMI与GatewayAPI的GAMMA倡议意味着什么？》的一文中，介绍过KubernetesGatewayAPI处理东西向（网格）流量的可能性。让我们重新看下GatewayAPI中对流量定义（路由）的定义，以HTTP路由为例：apiVersion:gateway.networking.k8s.io/v1beta1kind:HTTPRoutemetadata:name:my-routenamespace:gateway-api-example-ns2spec:parentRefs:-kind:Gatewayname:foo-gatewaynamespace:gateway-api-example-ns1hostnames:-foo.example.comrules:-backendRefs:-name:foo-svcport:8080
上面的YAML中，使用parentRefs字段将路由策略附加到了网关资源foo-gateway上。网关foo-gateway会根据请求头部的HOST来选择合适的HTTPRoute ，然后将流量代理到上游Servicefoo-svc 。简单来说，就是定义了“网关->路由->后端”的映射。

文章图片
ingress-vs-mesh
通过对流量的定义以及处理流量的资源的选择，实现7层HTTP协议的反向代理和负载均衡。但在实际的场景下，简单的代理路由策略还并不够，可能还需要配合治理策略来提升服务的健壮性，比如限流、重试、超时、熔断、自定义健康检查等等。
我们看下Istio的超时配置，首先使用了reviews进行流量的匹配，然后再根据路由的策略uri前缀/review进行路由匹配，将流量代理到目的地v2的reviews 。与此同时，该路由的超时为0.5s 。 apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:reviewsspec:hosts:-reviewshttp:-match:-uri:prefix:"/review"route:-destination:host:reviewssubset:v2timeout:0.5s
在这段定义中耦合了流量匹配、路由匹配、后端指定、超时，如果需要配置重试呢，再加个retries字段。如此一来，灵活性大打折扣。
微软MVP实验室研究员

文章图片
张晓辉-微软MVP
Flomesh高级云原生架构师，资深程序员， LFAPAC开源布道师，云原生社区管委会成员，公众号“云原生指北”作者。有多年的微服务和基础架构实践经验，主要工作涉及微服务、容器、Kubernetes、DevOps等。
目标
KubernetesGatewayAPI的策略附件（PolicyAttachment）的设计目标：策略和资源关联标准化支持策略的默认值和覆盖值不同资源上策略生效的优先级
为资源施加策略的时候，既要考虑通用性（标准化）又要考虑灵活性（策略值优先级）。
这里说的资源可以是网关相关的任何资源，比如GatewayClass、Gateway、路由（如HTTPRoute、TCPRoute、GRPCRoute）、Kubernetes核心资源（如Namespace、Service）。后面几种资源还会分命名空间，比如是请求发起方（Gateway、服务消费方）或者请求接收方（服务提供方）的命名空间。

文章图片
resource-level
这些资源的影响范围各有不同，我们暂且称为粒度，比如GatewayClass影响某类网关实现所有实例上的流量；Gateway资源则特指进入某个网关实例的流量；Namespace特指由该命名空间下的资源发出或者接收的流量；路由则特指具有某种特征的流量，并且路由的定义可以定义在发起方的命名空间，也可以定义在接收方的命名空间。
可见虽然策略是附加在资源上，但作用的最终目标还是流量：南北向流量和东西向流量，分别对应入口策略和网格策略。
▍入口策略

文章图片
ingress-policy-attachment
▍网格策略