构建云原生微服务网关-篇一：Ambassador

时间 2019-11-06

标签构建原生微服网关 ambassador 繁體版

原文原文链接

在微服务架构中，API网关是一个十分重要的存在。一方面它为外部的流量访问提供了统一的入口，使得能够方便的进行防火墙的策略实施；另外一方面，能够在网关处进行流量控制、认证、受权、灰度发布、日志收集、性能分析等各类高级功能，使得业务功能与非业务功能有效解耦，给予了系统架构更大的灵活性。本系列文章尝试分析目前主流的云原生微服务网关，并比较它们各自的优劣。前端

网关选型标准

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

什么是Ambassador？

这里引用官网的一段描述数据库

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

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

Ambassador架构

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

具体流程以下：bash

服务全部者在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网关的问题是：app

不是自服务的。传统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安装只须要执行以下命令：

helm install --name my-release stable/ambassador
复制代码

这边插播一下，推荐使用微软azure的charts镜像http://mirror.azure.cn/kubernetes/charts/，基本和官方的同步，且能够正常访问，阿里云的charts不知道为何更新很不及时。安装完后能够看到有两个pods

$ kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
ambassador-3655608000-43x86   1/1       Running   0          2m
ambassador-3655608000-w63zf   1/1       Running   0          2m
复制代码

若是都是都是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

[root@MiWiFi-R1CM-srv zuul]# kubectl get crds|grep ambassador
authservices.getambassador.io                  2019-07-27T11:40:58Z
consulresolvers.getambassador.io               2019-07-27T11:40:58Z
kubernetesendpointresolvers.getambassador.io   2019-07-27T11:40:58Z
kubernetesserviceresolvers.getambassador.io    2019-07-27T11:40:58Z
mappings.getambassador.io                      2019-07-27T11:40:58Z
modules.getambassador.io                       2019-07-27T11:40:58Z
ratelimitservices.getambassador.io             2019-07-27T11:40:58Z
tcpmappings.getambassador.io                   2019-07-27T11:40:58Z
tlscontexts.getambassador.io                   2019-07-27T11:40:58Z
tracingservices.getambassador.io               2019-07-27T11:40:58Z
复制代码

其中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的几个使用场景：

用例

用例1：边缘（南/北）路由

这个是平时最多见的使用场景，网关位于整个集群的入口处，统一去作一些流控、鉴权等方面的工做：该场景的关注点在于：

控制/路由入口流量的能力
卸载请求
- 认证（好比要求全部入口流量都必需要进过认证）
- 加密（TLS终端及传输加密）
- 重试及超时

saas service中的真实用例：

用例2：内部（南/北）路由

一般来讲，企业内部的系统架构会比较复杂，会有多集群或者多租户，好比一个kubernetes的集群和一个vm的集群（多是openstack），那么在集群之间的流量就是内部的南/北流量，集群之间的流量交互能够经过ambassador完成。此场景的关注点在于：

控制/路由多租户流量的能力
卸载请求
- 匹配（基于headers）
- 重试及超时

saas service中的真实用例：

用例3：内部（东/西）路由

这个场景中Ambassador已经做为集群内部东西向流量的代理了，配合它本身的控制平面，有点service mesh的意思了。区别在于，Ambassador在这个集群里是处于一个中心节点的位置（一个或一组ambassador实例），属于server proxy的范畴，而不是service mesh里面的client proxy（sidecar）。这种架构其实和传统的esb更加的接近。此场景关注点：

控制/路由任意流量的能力（南北向+东西向）
卸载请求
- 服务发现
- 负载均衡
- 访问控制

你们能够看到，已经很是接近于service mesh的能力了（也许ambassador之后也会出一个service mesh产品？）

saas service的真实用例： service mesh的真实用例（与istio集成）：

用例4：流量镜像

此场景中能够把流量复制一份到其余服务中（影子流量），一般用于监控、测试等场景

测试代码、发布包的能力
利用真实的流量/负载
最小化重复资源

注意：上面所描述的几个典型场景其实不光可使用Ambassador，而是适用于各种使用api gateway或者proxy的场景。

配置

Ambassador不一样版本之间配置方式的变动以下图所示,configmap方式是早期使用方式，目前已经被废弃了，如今更推荐使用CRD方式。

加密的配置方式

认证的配置方式

路由的配置方式

跟踪的配置方式

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版，后期技术支持的便利性也是须要考虑的问题。

参考文献

www.getambassador.io
Using Ambassador to build Cloud-Native Applications - Steve Flanders, Omnition @ KubeCon 2019, Shanghai

做者：陆培尔

原文：www.servicemesher.com/blog/cloud-…

Service Mesh Meetup #6 广州站

时间：2019-08-11（星期日）上午 9:00 - 12:30
地点：广东省广州市天河区广电平云 B 塔 15F 中关村+硅谷
报名地址：www.huodongxing.com/event/55028…

活动详情

09:00-09:15 签到

09:15-10:00 《虎牙直播在微服务改造方面的实践》张波虎牙基础保障部中间件团队负责人

虎牙注册中心名字服务的改造实践及与 Istio 打通实现，帮助微服务平滑过渡到 Service Mesh。

10:00-10:50《Service Mesh 在蚂蚁金服的生产级安全实践》彭泽文蚂蚁金服高级开发工程师

介绍经过 Envoy SDS（Secret Discovery Service）实现 Sidecar 证书管理的落地方案；分享如何为可信身份服务构建敏感信息数据下发通道，以及 Service Mesh Sidecar 的 TLS 生产级落地实践。

10:50-11:35《基于 Kubernetes 的微服务实践》涂小刚慧择网运维经理

介绍如何跟据现有业务环境状况制定容器化总体解决方案，导入业务进入 K8S 平台，容器和原有业务环境互通。制订接入规范、配置中心对接 K8S 服务、网络互通方案、DNS 互通方案、jenkins-pipeline 流水线构建方案、日志采集方案、监控方案等。

11:35-12:20《Service Mesh发展趋势：棋到中盘路往何方》敖小剑蚂蚁金服高级技术专家

继续探讨 Service Mesh 发展趋势：深度分析 Istio 的重大革新 Mixer v2，Envoy 支持 Web Assembly 的意义所在，以及在 Mixer v2 出来以前的权宜之计; 深刻介绍 Google Traffic Director 对虚拟机模式的创新支持方式，以及最近围绕 SMI 发生的故事。

关于 Service Mesh

服务网格（Service Mesh）是致力于解决服务间通信的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh 一般是经过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一块儿来实现，而无需感知应用程序自己。

关于 Service Mesh Meetup

Service Mesh Meetup 是由蚂蚁金服发起的，由 ServiceMesher 社区主办的，围绕容器、Kubernetes、Service Mesh 及云原生话题，在全国各地循环举办的技术沙龙。

关于 ServiceMesher 社区

ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起，于 2018 年 4 月正式成立。社区网站：www.servicemesher.com

社区关注领域有：容器、微服务、Service Mesh、Serverless，拥抱开源和云原生，致力于推进 Service Mesh 在中国的蓬勃发展。

社区使命

传播 Service Mesh 技术，构建开源文化，增强行业交流，推进 Service Mesh 在企业中落地。

社区愿景

成为 Service Mesh 在中国的布道者和领航者。