南北入口网关选型

南北向网关的选型之旅

背景

我们这边的容器云是国内外混合云，这里的混合云是指

• 从提供者来分包含：

  • 阿里云
  • 华为云
  • AWS
  • Oracle
  • 自建

• 从地域来分包含：

  • 国内
  • 海外
    • 法兰克福
    • 俄罗斯
    • 新加坡
    • ……

所以我们希望网关方案能够

• 涵盖住所有集群、所有地域
• 最好是能直接用云产品
• 对接各个集群的方案是统一的
• 能够涵盖
  • Ingress Nginx的能力
  • 业务开发对于网关的日常需求

我们一期的目标是先弄南北向网关，二期看情况再弄服务网格(东西向)
所以本方案主要侧重在南北向网关的选择，但如果后期要弄服务网格也要能支持

基于上面的背景，业界可以选择的方案，大概有这些：

• Istio Gateway
• 阿里云ASM
• 华为云ASM
• Kubernetes Gateway API

先捋一下业务网关的基础能力

• HTTP 路由
• HTTP 流量拆分
  ◦ Canary traffic rollout
  ◦ Blue-green traffic rollout
  ◦ ……
• Timeout
• Rewrite
• Redirect
• Header Modify
• Request Mirror
• WebSocket
• Retry
• Cors
• Rate Limits
• Circuit Breaking

上面的这些能力也涵盖住了Ingress Nginx的能力。

对于网关部分，大家有可能会想到为啥调研阿里云的MSE？
主要是MSE只能部署在阿里云的ACK中，对于非阿里云ACK及自建集群没法纳管。

下面开始逐一分析以上网关的优劣

网关优劣势分析

华为云ASM

基于Istio Gateway实现,能支持服务网格但实现方式Sidecar模式。

优势

• ASM 完全兼容istio CRD

劣势

• ASM基础版本(支持单集群、支持最大实例数是200、不保证SLA)
• UCS 服务网格商用受限(现在还没有人用过)
  • 注1：ASM企业版已经下线了
• 不支持纳管别的云或者自建集群
• 同样存在路由优先级问题

阿里云ASM

基于Istio Gateway实现,能支持服务网格，支持：Sidecar、Ambient两种模式，不过现阶段生产不推荐Ambient模式。

优势

• 能提供SLA保证
• 不需要自己运维相关组件
• 支持纳管别的云及自建集群
• 针对业务集群阿里云对应地域没有regin及海外网络差的情况，有针对性方案:ASM远程控制面
• 功能特性全
• 同一控制面支持纳管多个kubernetes集群
  *这里需要注意:这些集群都是类似镜像集群,集群内的ASM部署的CRD及下发的路由啥的都是一毛一样的,所以这个功能也没啥用

劣势

• 因为是直接基于Istio Gateway的，所以路由的顺序有问题
  • 同一个虚拟服务内部，按照声明顺序来匹配，匹配到一个满足的就停止了
  • 同一个域名，不同虚拟服务之间，顺序是不确定的
• 目前支持Kubernetes Gateway API v1.1.0，不支持v1.2.0的相关特性
  • 标准
    • HTTPRoute 超时
    • 后端协议支持WebSocket 和 HTTP/2

Istio Gateway / Kubernetes Gateway API

对于Istio Gateway这里分为两种方案：

• 对接标准，也就是Kubernetes Gateway API
  • 标准化：Kubernetes Gateway API旨在成为一种标准，用于描述在Kubernetes集群中如何暴露服务。这意味着它不仅仅限于与某个特定的服务网格或入口控制器（如Istio）一起使用。通过采用Gateway API，您可以更容易地切换不同的实现或服务提供商，而无需重写您的配置。
  • 概念一致性：跟大家之前使用的MSE、APISIX保持一致
  • 更好的集成能力：由于Gateway API是Kubernetes原生的API，因此它能够更好地与其他Kubernetes原生工具和系统集成
  • 支持路由优先级
• 直接对接Istio Gateway
  • 现阶段Istio Gateway的能力比Kubernetes Gateway API涵盖的范围更广，比如：熔断、限流
  • 但会引入Istio Gateway虚拟服务(VirtualService)、目标规则(DestinationRule)等概念，增加用户的学习成本
  • 路由顺序不确定

到这里可以看出来只看路由优先级这么一个点就过滤掉了云ASM及直接对接Istio Gateway。

但还有几个点需要注意：

• Kubernetes Gateway API目前不支持熔断、限流
• 对于跨域，也需要等到Milestone v1.3.0 （当前版本v1.2.1，下一个版本应该就是v1.3.0,但具体发布时间不确定）

Service Mesh

从官网上看，Istio对于Kubernetes Gateway API服务网格的支持也已经GA。

Kubernetes Gateway API路由优先级

从HTTPRoutes生成的代理或负载均衡器路由配置必须根据以下标准优先匹配，并在出现平局时继续比较。在适用路由上指定的所有规则中，优先级应给予具有以下条件的匹配：

• “精确”路径匹配。
• 具有最多字符的“前缀”路径匹配。
• 方法匹配。
• 最大数量的头部匹配。
• 最大数量的查询参数匹配。

注：正则表达式路径匹配的优先级是具体实现相关的。

如果在多个路由之间仍然存在平局，匹配优先级必须按照以下标准依次确定，并在出现平局时继续比较：

• 基于创建时间戳的最早的路由。
• 按“{命名空间}/{名称}”字母顺序排列的第一个路由。

如果在HTTPRoute内仍然存在平局，则应将匹配优先级授予符合上述条件的第一个匹配规则（按列表顺序）。

如果未成功附加与请求匹配的规则到请求来源的父级，则必须返回HTTP 404状态码。

原文地址：
https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule

从文档注释的位置可以判断同一个HTTPRouteRule内的多个HTTPRouteMatch应该是会满足以上规则的，那么多个HTTPRouteRule之间呢？

下面逐一验证下以上两种情况：

验证结果

针对常用的

• 多个前缀匹配之间的优先级
• 前缀匹配与精确匹配的优先级
  进行验证，通过验证结果可以看出istio路由是遵循了Kubernetes Gateway API规范的。

结果

从文中所列举的几种方案来看，目前最可行的方案就是

• 自己部署Istio Gateway，然后直接对接Kubernetes Gateway API的CRD。
  • 这个真实要用起来也要等Milestone v1.3.0 发布及istio支持之后
• 或者等阿里云ASM支持Milestone v1.3.0之后

其它

云ASM支持Kubernetes版本的范围及云ASM Istio版本

• 阿里云
• 华为云

Sidecar vs Ambient

https://istio.io/latest/zh/docs/overview/dataplane-modes/#choosing-between-sidecar-and-ambient

Istio 与 Kubernetes Gateway API

Istio 支持 Kubernetes Gateway API， 并计划将其作为未来流量管理的默认 API。

Istio是如何实现Kubernetes Gateway API路由优先级的？

https://github.com/istio/istio/blob/master/pilot/pkg/config/kube/gateway/conversion.go#L823