构建云原生微服务网关: Ambassador

前言：
在微服务架构中，API 网关是一个十分重要的存在。一方面它为外部的流量访问提供了统一的入口，使得可以方便的进行防火墙的策略实施；另一方面，可以在网关处进行流量控制、认证、授权、灰度发布、日志收集、性能分析等各种高级功能，使得业务功能与非业务功能有效解耦，给予了系统架构更大的灵活性。

网关选型标准

其实 kubernetes 本身有一个 ingress controller，基于 Nginx 或 HAProxy 等 7 层代理进行流量的转发。不过 ingress 只能进行简单的反向代理，不支持流控、灰度、认证、授权等网关必备的功能。所以一般意义认为，ingress 是一个 7 层 http 代理，而非 api 网关。这次主要分析 Ambassador、Traefik、Kong 等具备微服务所需能力的网关产品。

什么是 Ambassador？

这里引用官网的一段描述
Ambassador 是一个基于 Envoy proxy 构建的，kubernetes 原生的开源微服务网关。Ambassador 在构建之初就致力于支持多个独立的团队，这些团队需要为最终用户快速发布、监控和更新服务。Ambassador 还具有 Kubernetes ingress 和负载均衡的能力。

注意这里的几个关键词：Envoy，kubernetes 原生，微服务。现在市面上网关产品不少，不过 Kubernetes 原生的产品倒真的不多。传统的网关产品一般是基于 rest api 或者 yaml 文件来进行配置（谁让这些老大哥出来的早呢，他们火的时候 k8 还没出来呢），而 Ambassador 完全基于 k8s 标准的 annotation 或者 CRD 来进行各类配置，没错，非常的native。

Ambassador 架构

了解 istio 的同学，看到这张图会有十分熟悉的感觉，没错，Ambassador 也是具有控制平面和数据平面的。数据平面自然是老伙计 Envoy，Ambassador 的控制平面负责监听 k8s 中的 Service 资源的变化，并将配置下发 Envoy，实际的流量转发通过 Envoy 来完成。（感觉就是一个轻量级的 istio）
具体流程如下：

服务所有者在 kubernetes manifests 中定义配置 (通过 annotation 或者 CRD)。
当 manifest 应用到集群时，kubernetes api 会将更改通知 Ambassador。
Ambassador 解析更改并将配置转换为一种中间语义。Envoy 的配置由该 IR 生成。
新的配置通过基于 gRPC 的聚合发现服务（ADS）api 传递给 Envoy。
流量通过重新配置的 Envoy，而不会断开任何连接。

扩展性和可用性

Ambassador 依靠 Kubernetes 实现扩展性、高可用性和持久性。所有 Ambassador 配置都直接存储在 Kubernetes 中（etcd），没有数据库。Ambassador 被打包成一个单独的容器，其中包含控制平面和一个 Ambassador 代理实例。默认情况下，Ambassador 部署为 kubernetes deployment，可以像其他 kubernetes deployment 一样进行扩展和管理。

与其他网关产品比较

目前主流的网关产品可以分为三类：

托管的 API 网关，比如 Amazon api gateway
传统的 API 网关，比如 Kong
7 层代理，比如 Traefik, NGINX, HAProxy, or Envoy, 或者是基于这些代理的 Ingress controllers

所有这些托管的和传统的 API 网关的问题是：

不是自服务的。传统 API 网关上的管理接口不是为开发人员自服务而设计的，为开发人员提供的安全性和可用性有限。
不是 Kubernetes 原生的。它们通常使用 REST apis 进行配置，这使得采用云原生模式（如 GitOps 和声明式配置）变得很困难。
为 API 管理而设计，而非微服务。

一般来说，7 层代理可以用作 API 网关，但需要额外的定制开发来支持微服务用例。事实上，许多 API 网关都将 API 网关所需的附加功能打包在 L7 代理之上。Ambassador 使用 Envoy，而 Kong 使用 Nginx。

Istio

Istio 是一个基于 Envoy 的开源服务网格。服务网格用于管理东/西流量，而 API 网关用于管理南/北流量。一般来说，我们发现南/北流量与东/西流量有很大不同（比如说，在南北流量中你无法控制客户端）。

安装 Ambassador

Ambassador 安装非常的简单，直接使用 helm 安装。如果对于 helm 还不是很了解，可以参考我之前的文章 helm 介绍。使用 helm 安装只需要执行如下命令：

# Add the Repo:
helm repo add datawire https://app.getambassador.io
helm repo update
 
# Create Namespace and Install:
kubectl create namespace ambassador && \
kubectl apply -f https://app.getambassador.io/yaml/edge-stack/3.10.1/aes-crds.yaml
 
kubectl wait --timeout=90s --for=condition=available deployment emissary-apiext -n emissary-system
 
helm install edge-stack --namespace ambassador datawire/edge-stack \
  --set emissary-ingress.agent.cloudConnectToken=$CLOUD_CONNECT_TOKEN && \
kubectl -n ambassador wait --for condition=available --timeout=90s deploy -l product=aes

现版本的社区版需要申请一个密钥，才能完成上面helm的安装
安装完后可以看到有如下pods:

如果都是都是 running 状态，这样 Ambassador 就安装完成了接下来我们部署一下官网的应用

---
apiVersion: v1
kind: Service
metadata:
  name: tour
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: tour-ui_mapping
      prefix: /
      service: tour:5000
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: tour-backend_mapping
      prefix: /backend/
      service: tour:8080
      labels:
        ambassador:
          - request_label:
            - backend      
spec:
  ports:
  - name: ui
    port: 5000
    targetPort: 5000
  - name: backend
    port: 8080
    targetPort: 8080
  selector:
    app: tour
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tour
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tour
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: tour
    spec:
      containers:
      - name: tour-ui
        image: quay.io/datawire/tour:ui-0.2.4
        ports:
        - name: http
          containerPort: 5000
      - name: quote
        image: quay.io/datawire/tour:backend-0.2.4
        ports:
        - name: http
          containerPort: 8080
        resources:
          limits:
            cpu: "0.1"
            memory: 100Mi

这个 pod 里面有两个容器，分别是前端的 ui 以及后端的 backend。注意 annotation 里面的getambassador.io/config部分，这就是 ambassador 的配置了，分别定义了两个注释，kind 是Mapping，定义了前后端的匹配路径，服务名称及端口。这个配置的意思是，凡是匹配上/的，全部走 tour 的 5000 端口，凡是匹配上/backend的，全部走 tour 的 8080 端口（对应的就是 tour 的 service 配置）。也可以使用 CRD 方式配置，ambassador 已经默认创建了一组 crd

其中 mapping 就是核心资源，用于路由的转发配置，下面是一个 mapping 资源配置示例

apiVersion: v1
items:
- apiVersion: getambassador.io/v1
  kind: Mapping
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"getambassador.io/v1","kind":"Mapping","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"prefix":"/nginx","service":"nginx:80"}}        
    creationTimestamp: "2019-07-27T13:36:38Z"
    generation: 1
    name: nginx
    namespace: default
    resourceVersion: "420594"
    selfLink: /apis/getambassador.io/v1/namespaces/default/mappings/nginx
    uid: 8f1f4d33-b073-11e9-be4c-0800279f163b
  spec:
    prefix: /nginx
    service: nginx:80
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

一旦你修改了 service 里面的 annotation 设置，ambassador 的控制面会自动将变更下发给 Envoy，全程不需要中断服务。（也要感谢 Envoy 强大的 xDS api）

加密的配置方式

认证的配置方式

路由的配置方式

跟踪的配置方式

Ambassador 的不足

Ambassador 和同类的网关产品类似，分为社区版及商业版，社区版提供了最基础的路由、限速、TLS 加密、跟踪、认证（需要自己实现 external third party authentication service）等能力，但是微服务网关中十分重要的 OAuth2 集成认证、RBAC、custom filter 等功能都是需要在 pro 版中才能实现，这是比较遗憾的一点。尤其是 custom filter，根据我们目前的经验，一个能力完整、功能丰富的微服务网关，必然会引入 custom filter。而 custom filter 也需要使用 Golang 进行编写，对于不熟悉 Golang 的开发人员来说也会比较痛苦。

总结

Ambassador 作为一个较新推出的开源微服务网关产品，与 kubernetes 结合的相当好，基于 annotation 或 CRD 的配置方式与 k8s 浑然一体，甚至让人感觉这就是 k8s 自身功能的一部分，真正做到了kubernetes native。而底层基于 Envoy 进行流量代理，也让人不需要太担心性能问题。对于路由、加密、基础认证、链路跟踪等场景，可尝试使用。而对于像custom filter、rbac、advanced rate limiting等场景有需求的用户，使用 pro 版本可满足要求。本人也与 Ambassador 开发团队进行了联系，遗憾的是 Ambassador 目前在国内尚未有 reseller，若使用 pro 版，后期技术支持的便利性也是需要考虑的问题。

目录CONTENT