在微服務架構中,API網關是一個十分重要的存在。一方面它爲外部的流量訪問提供了統一的入口,使得能夠方便的進行防火牆的策略實施;另外一方面,能夠在網關處進行流量控制、認證、受權、灰度發佈、日誌收集、性能分析等各類高級功能,使得業務功能與非業務功能有效解耦,給予了系統架構更大的靈活性。本系列文章嘗試分析目前主流的雲原生微服務網關,並比較它們各自的優劣。前端
其實kubernetes自己有一個ingress controller,基於Nginx或HAProxy等7層代理進行流量的轉發。不過ingress只能進行簡單的反向代理,不支持流控、灰度、認證、受權等網關必備的功能。因此通常意義認爲,ingress是一個7層http代理,而非api網關。本系列主要分析Ambassador、Traefik、Kong等具有微服務所需能力的網關產品。nginx
這裏引用官網的一段描述數據庫
Ambassador是一個基於Envoy proxy構建的,kubernetes原生的開源微服務網關。Ambassador在構建之初就致力於支持多個獨立的團隊,這些團隊須要爲最終用戶快速發佈、監控和更新服務。Ambassador還具備Kubernetes ingress和負載均衡的能力。後端
注意這裏的幾個關鍵詞:Envoy,kubernetes原生,微服務。如今市面上網關產品很多,不過Kubernetes原生的產品倒真的很少。傳統的網關產品通常是基於rest api或者yaml文件來進行配置(誰讓這些老大哥出來的早呢,他們火的時候k8還沒出來呢),而Ambassador徹底基於k8s標準的annotation或者CRD來進行各種配置,沒錯,很是的native。api
瞭解istio的同窗,看到這張圖會有十分熟悉的感受,沒錯,Ambassador也是具備控制平面和數據平面的。數據平面天然是老夥計Envoy,Ambassador的控制平面負責監聽k8s中的Service資源的變化,並將配置下發Envoy,實際的流量轉發經過Envoy來完成。(感受就是一個輕量級的istio)安全
具體流程以下:bash
Ambassador依靠Kubernetes實現擴展性、高可用性和持久性。全部Ambassador配置都直接存儲在Kubernetes中(etcd),沒有數據庫。Ambassador被打包成一個單獨的容器,其中包含控制平面和一個Ambassador代理實例。默認狀況下,Ambassador部署爲kubernetes deployment,能夠像其餘kubernetes deployment同樣進行擴展和管理。網絡
目前主流的網關產品能夠分爲三類:架構
全部這些託管的和傳統的API網關的問題是:app
通常來講,7層代理能夠用做API網關,但須要額外的定製開發來支持微服務用例。事實上,許多API網關都將API網關所需的附加功能打包在L7代理之上。Ambassador使用Envoy,而Kong使用Nginx。
Istio是一個基於Envoy的開源服務網格。 服務網格用於管理東/西流量,而API網關用於管理南/北流量。 通常來講,咱們發現南/北流量與東/西流量有很大不一樣(好比說,在南北流量中你沒法控制客戶端)。
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的幾個使用場景:
這個是平時最多見的使用場景,網關位於整個集羣的入口處,統一去作一些流控、鑑權等方面的工做: 該場景的關注點在於:
saas service中的真實用例:
一般來講,企業內部的系統架構會比較複雜,會有多集羣或者多租戶,好比一個kubernetes的集羣和一個vm的集羣(多是openstack),那麼在集羣之間的流量就是內部的南/北流量,集羣之間的流量交互能夠經過ambassador完成。 此場景的關注點在於:
saas service中的真實用例:
這個場景中Ambassador已經做爲集羣內部東西向流量的代理了,配合它本身的控制平面,有點service mesh的意思了。區別在於,Ambassador在這個集羣裏是處於一箇中心節點的位置(一個或一組ambassador實例),屬於server proxy的範疇,而不是service mesh裏面的client proxy(sidecar)。這種架構其實和傳統的esb更加的接近。 此場景關注點:
你們能夠看到,已經很是接近於service mesh的能力了(也許ambassador之後也會出一個service mesh產品?)
saas service的真實用例: service mesh的真實用例(與istio集成):
此場景中能夠把流量複製一份到其餘服務中(影子流量),一般用於監控、測試等場景
注意:上面所描述的幾個典型場景其實不光可使用Ambassador,而是適用於各種使用api gateway或者proxy的場景。
Ambassador不一樣版本之間配置方式的變動以下圖所示,configmap方式是早期使用方式,目前已經被廢棄了,如今更推薦使用CRD方式。
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.servicemesher.com/blog/cloud-…
時間:2019-08-11(星期日)上午 9:00 - 12:30
地點:廣東省廣州市天河區廣電平雲 B 塔 15F 中關村+硅谷
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 在中國的佈道者和領航者。