構建雲原生微服務網關-篇一: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和負載均衡的能力。後端

注意這裏的幾個關鍵詞:Envoykubernetes原生微服務。如今市面上網關產品很多,不過Kubernetes原生的產品倒真的很少。傳統的網關產品通常是基於rest api或者yaml文件來進行配置(誰讓這些老大哥出來的早呢,他們火的時候k8還沒出來呢),而Ambassador徹底基於k8s標準的annotation或者CRD來進行各種配置,沒錯,很是的nativeapi

Ambassador架構

image.png瞭解istio的同窗,看到這張圖會有十分熟悉的感受,沒錯,Ambassador也是具備控制平面和數據平面的。數據平面天然是老夥計Envoy,Ambassador的控制平面負責監聽k8s中的Service資源的變化,並將配置下發Envoy,實際的流量轉發經過Envoy來完成。(感受就是一個輕量級的istio)安全

具體流程以下:bash

  1. 服務全部者在kubernetes manifests中定義配置(經過annotation或者CRD)。
  2. 當manifest應用到集羣時,kubernetes api會將更改通知Ambassador。
  3. Ambassador解析更改並將配置轉換爲一種中間語義。Envoy的配置由該IR生成。
  4. 新的配置經過基於gRPC的聚合發現服務(ADS)api傳遞給Envoy。
  5. 流量經過從新配置的Envoy,而不會斷開任何鏈接。

擴展性和可用性

Ambassador依靠Kubernetes實現擴展性、高可用性和持久性。全部Ambassador配置都直接存儲在Kubernetes中(etcd),沒有數據庫。Ambassador被打包成一個單獨的容器,其中包含控制平面和一個Ambassador代理實例。默認狀況下,Ambassador部署爲kubernetes deployment,能夠像其餘kubernetes deployment同樣進行擴展和管理。網絡

與其餘網關產品比較

目前主流的網關產品能夠分爲三類:架構

全部這些託管的和傳統的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:邊緣(南/北)路由

這個是平時最多見的使用場景,網關位於整個集羣的入口處,統一去作一些流控、鑑權等方面的工做: image.png該場景的關注點在於:

  • 控制/路由入口流量的能力
  • 卸載請求
    • 認證(好比要求全部入口流量都必需要進過認證)
    • 加密(TLS終端及傳輸加密)
    • 重試及超時

saas service中的真實用例: saas.png

用例2:內部(南/北)路由

一般來講,企業內部的系統架構會比較複雜,會有多集羣或者多租戶,好比一個kubernetes的集羣和一個vm的集羣(多是openstack),那麼在集羣之間的流量就是內部的南/北流量,集羣之間的流量交互能夠經過ambassador完成。 image.png此場景的關注點在於:

  • 控制/路由多租戶流量的能力
  • 卸載請求
    • 匹配(基於headers)
    • 重試及超時

saas service中的真實用例: image.png

用例3:內部(東/西)路由

這個場景中Ambassador已經做爲集羣內部東西向流量的代理了,配合它本身的控制平面,有點service mesh的意思了。區別在於,Ambassador在這個集羣裏是處於一箇中心節點的位置(一個或一組ambassador實例),屬於server proxy的範疇,而不是service mesh裏面的client proxy(sidecar)。這種架構其實和傳統的esb更加的接近。 image.png此場景關注點:

  • 控制/路由任意流量的能力(南北向+東西向)
  • 卸載請求
    • 服務發現
    • 負載均衡
    • 訪問控制

你們能夠看到,已經很是接近於service mesh的能力了(也許ambassador之後也會出一個service mesh產品?)

saas service的真實用例: image.pngservice mesh的真實用例(與istio集成): image.png

用例4:流量鏡像

此場景中能夠把流量複製一份到其餘服務中(影子流量),一般用於監控、測試等場景 image.png

  • 測試代碼、發佈包的能力
  • 利用真實的流量/負載
  • 最小化重複資源

注意:上面所描述的幾個典型場景其實不光可使用Ambassador,而是適用於各種使用api gateway或者proxy的場景。

配置

Ambassador不一樣版本之間配置方式的變動以下圖所示,configmap方式是早期使用方式,目前已經被廢棄了,如今更推薦使用CRD方式。 image.png

加密的配置方式

image.png

認證的配置方式

image.png

路由的配置方式

image.png

跟蹤的配置方式

image.png

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 filterrbacadvanced 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…

servicemesh 活動易拉寶-無_畫板 1.jpg

活動詳情

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 在中國的佈道者和領航者。

相關文章
相關標籤/搜索