Service Mesh與Istio佈署簡介(上)

Service Mesh與Istio佈署簡介(上)

Service Mesh與Istio佈署簡介(上)

服務網格(Service Mesh)於2016年提出後,至2017年底短短一年多的時間,無論在開源社群或公司產品的表現上,可看出雲社群對該議題的重視,相關技術如Linkerd和Envoy均於2017年1月及9月陸續加入CNCF,諸如Google、IBM等大廠也與Lyft Envoy積極開發開源的Service Mesh Project:Istio。因此本篇後續將陸續介紹Service Mesh、Istio、如何佈署Istio於Kubernetes上、Istio範例測試,並總結Service Mesh與容器安全的關係,最後比較Istio與Linkerd。

Service Mesh

Service Mesh是在2016年9月29日隨著Linkerd所提出的一個新的技術名詞,旨在解決微服務架構/容器化服務所衍生出來的網路/安全問題。

試想以下3個情境:

  1. 當開發人員開發了一個容器化服務並佈署在K8S等容器編排工具上後,要如何確保各個Pod是連線到正確的Pod上呢?舉個例子來說,為了上線新的版本的服務,可能需要不同的佈署方式來將舊的版本轉移到新的版本上,例如透過金絲雀佈署,先將部份用戶的流量導到新版本的Pod上,確認沒問題後再將所有用戶轉移到新的版本,那麼服務供應商如何確保該連線無論在測試階段或上線後所有連線都是接到正確版本的Pod上?
  2. 承上,當上線後需要特定的Pod根據流量大小決定提供服務或中斷服務時,該如何達成?
  3. 開發人員在開發容器化服務時如何確保各個Pod/微服務可以發現該溝通的目的Pod/微服務?

在簡述上述4點的解決方法前,我們可以先討論過往傳統單體架構的服務在分散式架構下所會遇到的問題,因為整體微服務架構的演進過程就有如單體架構到分散式架構的情況。

如上圖1到上圖2,過往在分散式架構下,為了讓不同的電腦間可以溝通,從圖1到圖2開始有了網路,然而在程式的開發上,分散式架構下的程式溝通早期如下圖3所示,需要仰賴開發者於程式內的程式碼撰寫。

可預見的,當架構愈大時,開發者在開發成本上,可能最主要的心力並不在功能本身,而是在於撰寫正確連線的程式碼。因此在80年代出現了如圖4架構的TCP/IP,將網路的Flow Control隔離出來處理,讓開發者可以著重在程式的開發本身,極大化的減少開發時所需撰寫的連線問題的除錯。

至此我們可以先來探討上述第1個情境,該情境主要包含兩個問題點:

  1. Pods間如何連線
  2. 如何處理複雜的連線條件

關於第1點,在K8S上可透過不同的CNI Plugins如Calico、Canal、Flannel、Romana或Weave來達成類似TCP/IP的功能,但複雜的連線條件可能還是需要修改微服務的Source Code或定義的YAML檔來達成,而當需要頻繁的更改相關服務的連線條件時,將須花費許多時間在條件的修改上,且根據該服務整體的複雜度,在條件的修改上將越複雜同時也愈容易出錯,因此類似圖3所產生的狀況將在微服務架構下重現。

除了連線條件外,微服務架構下對網路的要求也更多,如第2個情境的熔斷機制(Circuit Breakers)和第3情境的服務發現(service discovery),一般的網路需求已不夠支援現階段對微服務架構的需求,許多對網路的Flow Control仰賴於開發人員對於連線條件的撰寫,難以適應複雜且動態的環境,因此如同過去TCP/IP所出現的情境,我們需要一個類似加強版的TCP/IP工具,幫我們解決更多在容器化服務上的網路問題,讓開發者可以專注在功能面上的開發,從而將各種網路的需求隔離出來,這便是Service Mesh的初衷。

Service Mesh不僅提供上述情境的需求,各種不同的Project有各自的特色,以Istio為例,其也提供了流量控管、Monitor Dashborad還有快速圖形化服務的架構拓樸圖等功能。

那麼Service Mesh如何達成?其基本架構如上圖5,以K8S的例子來說,每個Pod將被注入(Inject)一個類似反向代理的角色,所有Pod的流量一定要通過該代理,該代理又稱之為Sidecar,其主要功能在於協助Service Mesh’s Control Plane達成其他網路需求,如上述提到的流量管理、熔斷機制和服務發現等等,最終Service Mesh整體概觀將如下圖6所示,所有Pod間的連線均必須透過Sidecar連線,並由Sidecar獲取流量資訊交由Sevice Mesh的控制機制控管Pods間的連線。

參考資料:Pattern: Service Mesh

lstio

Istio希臘語有起航的意思,而Kubernetes有舵手的意思,可看出同樣都在Google支持下的兩個產品在未來應會有相輔相成的趨勢,而目前Istio主要支援的平台也是K8S,此外Istio未來也會支援其他更多的容器編排工具,因此在K8S的Service Mesh測試上,本篇先以Istio為主。

從前述Service Mesh的架構上可知,Service Mesh的重點主要在兩部份:

  1. Control Plane
  2. Sidecar

因此Istio在邏輯上也分成兩個部份,分別是控制面板(control plane)和數據面板(data plane),分別對應到上述第1和第2部份,其架構如下圖7:

從Istio架構可看出,對應到圖5,Sidecar的功能由Envoy達成,而Control Plane由Pilot、Mixer和Istio-Auth組成,介紹如下:

Envoy

作為Istio的底層,扮演Sidecar的角色,主要包含以下功能:

  1. Dynamic service discovery
  2. Load balancing
  3. TLS termination
  4. HTTP/2 & gRPC proxying
  5. Circuit breakers
  6. Health checks
  7. Staged rollouts with %-based traffic split
  8. Fault injection
  9. Rich metrics

Envoy和Service Pod佈署在同一個Pod內,因此可以取得經過流量的行為和各種屬性,如來源或目的IP、hostname、domain……等等,詳細可獲取哪些屬性可參考官方頁面。藉由取得的各項數據,將可透過Control Plane作其他如Routing Path或協助Envoy完成上述9項等功能。

Mixer

所有經由Envoy的流量和屬性均由Mixer接收,並根據服務供應商所自訂的Mixer Configuration定義去對Pods進行Access Control或執行策略等功能,如上圖8所示,其也支援多種Backends如GCP、AWS、Prometheus、Heapster……等等。

Pilot

Pilot主要藉由Expose Envoy API來控制Envoy instances的Life cycle,並透過Mixer所取得的資料及結合Mixer所訂定的Rules,將其轉換成Envoy可運作的型式,以達成幾個Envoy的功能,如下3點:

  1. Service discovery
  2. Traffic management
  3. Resiliency(timeouts, retries, circuit breakers, etc.

藉由Service registration來發現服務,轉換Mixer rules以使Envoy達成Traffic management的Intelligent routing,並藉由API控制Envoy instances的Life cycle以對Pods進行條件式的連線或操作。

此外,Pilot提供Platform adapter以讓各種不同平台可以透過Pilot操作或修改其上的Containers/Pods的相關資訊,如K8S上Pods的Registration information、Ingress resources……等等。

Istio-Auth

主要提供Service-to-Service和End-User的身份認証(Authentication)並提供安全的連線,為達上述目的,Istio-Auth主要須要3個Components:

  1.  Identity
  2. Key Management
  3. Communication Security

以圖10為例,其為一不同環境的Service-to-Service的TLS連線範例,有兩個Services,分別是K8S環境的fronend和實體或虛擬機環境的backend,其中frontend的service account是frontend-team,而backend的service account是backend-team。

為建立雙向的TLS連線,首先第1件要做的事是Identity。Istio-Auth透過service account來辨認要TLS連線的service,接著Istio-Auth透過Istio CA的Key Management發送keys/certs至K8S的container上,而沒有Key和Certification的VM/bare-metal則需在該節點上佈署Node Agent,以產生Key和CSR,並將CSR發送到Istio CA簽發憑證,至此雙邊皆有憑證後便可產生雙向的TLS連線。

參考資料:Istio.io

圖片參考資料:Pattern: Service Mesh

延伸閱讀:Service Mesh與Istio佈署簡介(中)Service Mesh與Istio佈署簡介(下)

撰文: 呂威廷 迎棧科技工程師