使用istio服务网格作为api网关

API网关作为客户端访问后端的入口由来已久，主要是管理“南北”流量，近几年开始流行Service Mesh架构，主要是管理内部系统，（即“东西”流量），而像 Istio 这样的服务网格也有内置网关，可以将系统内外的流量置于统一控制之下。这通常会给 Istio 的初次用户带来困惑。 Service Mesh 和 API Gateway 是什么关系？ Istio 的网关是如何工作的？在 Istio 网格中暴露服务的方式有哪些？这篇文章给你答案。

Istio 服务网格的关键见解

• 服务网格最初是为了解决管理分布式系统内部流量的问题而创建的，但 API 网关早在它之前就存在了。
• 虽然网关内置于 Istio 中，但您仍然可以使用自定义 Ingress Controller 来代理外部流量。
• API 网关和服务网格正在融合

如何在 Istio 服务网格中公开服务？

下图显示了使用 Istio Gateway、Kubernetes Ingress、API Gateway 和 NodePort/LB 在 Istio 服务网格中公开服务的四种方法。

Istio 网格以阴影表示，网格中的流量是内部（东西向）流量，而来自 Kubernetes 集群内的客户端访问服务的流量是外部（南北向）流量。

由于 NodePort/LoadBalancer 是公开 Kubernetes 内置服务的基本方式，本文不会讨论该选项。下面将描述其他三种方法中的每一种。

使用 Kubernetes Ingress 暴露流量

我们都知道，Kubernetes 集群的客户端无法直接访问 Pod 的 IP 地址，因为 Pod 处于 Kubernetes 内置的网络平面中。我们可以使用 NodePort 或 Load Balancer Kubernetes 服务类型在集群外公开 Kubernetes 内的服务。为了支持虚拟托管、隐藏和保存 IP 地址，您可以使用 Ingress 资源在 Kubernetes 中公开服务。

Ingress是一个Kubernetes资源，它控制一个做流量巡回的ingress controller的行为，相当于一个负载均衡的定向代理服务器，比如Nginx、Apache等，其中还包括规则定义，即路由信息对于 URL，由 Ingress 控制器提供。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: istio
  name: ingress
spec:
  rules:
  - host: httpbin.example.com
    http:
      paths:
      - path: /status/*
        backend:
          serviceName: httpbin
          servicePort: 8000

上面示例中的 kubernetes.io/ingress.class: istio 注解表明 Ingress 使用 Istio Ingress Controller，而 Istio Ingress Controller 实际上使用了 Envoy 代理。

使用 Istio Gateway 暴露服务

Istio 是一种流行的服务网格实现，它从 Kubernetes 发展而来，它实现了 Kubernetes 没有的一些功能。 （请参阅什么是 Istio 以及为什么 Kubernetes 需要 Istio？）它使流量管理对应用程序透明，将此功能从应用程序转移到平台层并成为云原生基础设施。

Istio 在 Istio 0.8 之前的版本中使用 Kubernetes Ingress 作为流量入口，其中使用 Envoy 作为 Ingress Controller。从 Istio 0.8 及更高版本开始，Istio 创建了 Gateway 对象。 Gateway 和 VirtualService 用于表示 Istio Ingress 的配置模型，Istio Ingress 的默认实现使用相同的 Envoy 代理。通过这种方式，Istio 控制平面以一致的配置模型控制入口网关和内部 sidecar 代理。这些配置包括路由规则、策略实施、遥测和其他服务控制功能。

Istio Gateway 资源本身只能为 L4 到 L6 配置，例如暴露的端口、TLS 设置等；但是，网关可以绑定到 VirtualService，其中可以在 L7 上配置路由规则，例如版本化流量路由、故障注入、HTTP 重定向、HTTP 重写以及网格内支持的所有其他路由规则。

下面是网关绑定到 VirtualService 的示例。带有“istio: ingressgateway”标签的 pod 将充当 Ingress 控制器并将 HTTP 流量路由到 httpbin.example.com 虚拟主机的端口 80。这个和使用Kubernetes Ingress最大的区别是需要我们手动将VirtualService绑定到Gateway上，并指定Gateway所在的pod。这个配置相当于给Kubernetes开了一个入口，供外部访问。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "httpbin.example.com"

下面的 VirtualService 通过网关绑定到上面的网关，以接受来自该网关的流量。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "httpbin.example.com"
  gateways:
  - httpbin-gateway
  http:
  - match:
    - uri:
        prefix: /status
    route:
    - destination:
        port:
          number: 8000
        host: httpbin

使用 API 网关

API 网关是位于客户端和后端服务之间的 API 管理工具，广泛用于微服务中，作为将客户端接口与后端实现分离的一种方式。当客户端发出请求时，API 网关将其分解为多个请求，然后将它们路由到正确的位置，生成响应并跟踪所有内容。

API网关是微服务架构中的一类特殊服务，作为所有微服务的入口，负责执行路由请求、协议转换、聚合数据、鉴权、限速、熔断等功能。大多数企业 API 都是通过 API 网关部署的，API 网关通常处理跨 API 服务系统的常见任务，例如 TLS 终止、身份验证和授权、速率限制和统计信息。

网格中可以有一个或多个 API 网关。 API网关的职责是

• 请求路由和版本控制
• 促进单体应用程序向微服务的过渡
• 权限认证
• 数据聚合：监控和计费
• 协议转换
• 消息传递和缓存
• 安全和警报

上面的路由、权限认证等很多基础功能也可以通过Istio Gateway来实现，但是一些成熟的API网关在功能丰富性和可扩展性上可能更有优势。

• API Gateway的引入需要考虑API Gateway自身的部署、运维、负载均衡等场景，增加了后端服务的复杂度。
• API Gateway承载了大量的接口适配，维护难度大。
• 对于某些场景，增加一跳可能会导致性能下降。

目前，一些 API 网关模仿正在通过将它们部署在 sidecar 中来构建自己的服务网格。

概括

在 Istio 服务网格中，可以使用各种 Kubernetes Ingress Controller 作为入口网关，当然也可以直接使用 Istio 内置的 Istio Gateway，进行策略控制、流量管理、使用监控等。这样做的好处是可以直接通过 Istio 的控制平面来管理网关，而不需要额外的工具。但对于API语句周期管理、复杂计费、协议转换、鉴权等功能，传统的API网关可能更适合你。因此，您可以根据需要进行选择，也可以组合使用。

一些传统的反向代理也在走向Service Mesh，比如Nginx的Nginx Service Mesh和Traefik的Traefik Mesh，还有一些API网关产品也在走向Service Mesh，比如Kong和Kuma，未来我们会看到API 网关、反向代理和服务网格的更多融合。