iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 17
2
DevOps

Kubernetes and Istio 三十天系列 第 17

[Day17] 如何為Cluster選擇一個好的Gateway

前言

今天就將討論Cluster有哪些Gateway模式的選擇。

Kubernetes Ingress

Kubernetes Ingress

Kubernetes Ingress可以當作Cluster流量入口,但存在兩個問題:

Kubernetes Ingress Controller是獨立在Service Mesh(Istio)之外的,需要單獨采用Ingress rule進行配置,導致Kubernetes Cluster和Service Mesh存在兩套互相獨立的路由規則配置,導致後續維運跟管理都會有很高的複雜度。
Kubernetes Ingress的功能也比較弱,不能在入口處實現和Service Mesh類似的路由規則,也不具備Service Mesh Sidecar Proxy的其它功能,導致難以從整體上為系統實現藍綠部署、分散式Tracing等功能。

Istio Gateway

Istio Gateway

Ingress和Service Mesh配置不同,甚至有許多重疊的功能,因此Istio後來的版本都有內建Istio-Gateway,Istio-Gateway代替Kubernetes Ingress來當作Cluster入口。

Istio Gateway本身只能配置L4到L6的功能,例如Expose Port,TLS設置等;但Gateway可以綁定一個VirtualService,在VirtualService 中可以配置L7 Route Rule,這些L7 Route Rule可以根據服務版本對請求進行分流,故障注入,HTTP重定向,HTTP重寫等所有Servcie Mesh(Istio)支持的Route Rule。

Gateway和VirtualService用於表示Istio Ingress的配置模型,Istio Ingress則采用了和Sidecar相同的Envoy proxy。

通過該方式,Istio同時控制了入口和內部的sidecar代理。這些配置包括路由規則,策略檢查、Telementry收集以及其他服務管理功能。

API Gateway

API Gateway

采用Gateway和VirtualService實現的Istio Ingress Gateway提供了Kubernetes Cluster入口功能。但對於一個服務來說,Istio Ingress Gateway除了基礎功能之外,還有一些其他的需求,例如:

  • Authentication & Authorization for users / 3rd-party systems
  • Enforce SLAs for different users / 3rd-party systems
  • Data transformation / translation
  • API lifecycle management
  • Rate limiting
  • Billing
  • Other customized requirements ...

API Gateway有很大一部分需要根據不同的需求進行客製化,目前看來暫時不可能被納入Kubernetes Ingress或者Istio Gateway的標準中。因此為了滿足這些需求,湧現出了各類不同的Kubernetes Ingress Controller以及Istio Ingress Gateway實作,包括Ambassador,Kong, Traefik,Solo等。

這些API Gateway實現在提供基礎的Kubernetes Ingress能力的同時,提供了強大的API Gateway功能,但由於缺少統一的標準,這些擴展實現之間相互之間並不兼容。而且遺憾的是,目前這些Ingress controller都還沒有正式提供和Istio整合的能力,但是可以直接使用這些API Gateway達到超越Kubernetes Ingress Controller基本的功能。

API Gateway + Sidecar Proxy as the External Traffic Entrance for a Service Mesh

API Gateway + Sidecar Proxy

在目前難以找到一個同時具備API Gateway和Isito Ingress Gateway能力的API Gateway情況下,一個可行的方案是使用API Gateway和Sidecar Proxy一起為Service Mesh提供Kubernetes Cluster入口。

由於API Gateway已經具備L7 Gateway的功能,Service Mesh Ingress Gateway中的Sidecar只需要提供VirtualService的路由能力,並不需要提供Gateway的能力,因此采用Sidecar Proxy即可。Kubernetes Cluster入口處的Sidecar Proxy和Service Mesh內部Pod中的Sidecar Proxy的唯一一點差別是:該Sidecar只接管API Gateway向Service Mesh內部的流量,並不接管外部流向API Gateway的流量;而Pod中的Sidecar需要接管進入Pod所有流量。

采用API Gateway和Sidecar Proxy一起作為服務網格的流量入口,是目前Service Mesh API Gateway的一個不錯方案。

性能方面的考慮:從上圖可以看到,外部請求的處理流程在入口處增加了Sidecar Proxy,因此會帶來些許的性能損耗,但這些損耗是完全可以接受的。

對於請求延遲而言,在Service Mesh中,一個外部請求本來就要經過較多的處理,在Ingress Controller增加一個Proxy對整體的延遲,影響基本忽略不計,而且對於絕大多數Service來說,Forward的時間比例本來就很小,99%的耗時都在業務邏輯。如果整個系統對於增加Proxy會導致延遲,則建議重新考慮是否需要微服務架構和Service Mesh。

對於吞吐量而言,如果Kubernetes Cluster的API Gateway吞吐量存在瓶頸,則可以通過對API Gateway + Sidecar Proxy組成的Kubernets Ingress Controller進行水平擴展,來進行Load Balancer,以提高Kubernets Cluster的吞吐量。最好的方式就是針對API Gateway采用NodePort或LoadBalancer的方式提供,再添加External Load Balancer。

結語

今天比較著墨在外部請求如何能夠更有效的選擇,好的Gateway方式。

圖片來源

Service


上一篇
[Day16] 如何將Cluster內的服務對外Expose
下一篇
[Day18] Istio Example BookInfo
系列文
Kubernetes and Istio 三十天30

尚未有邦友留言

立即登入留言