使用Istio的服務網格架構
- Istio
- Docker
- Kubernete
1.簡介
在本教程中,我們將介紹服務網格體系結構的基礎知識,並了解它如何補充分佈式系統體系結構。
我們將主要關注Istio,它是服務網格的實現。在此過程中,我們將介紹Istio的核心架構,並了解如何在Kubernetes上從中受益。
2.什麼是服務網格?
在過去的幾十年中,我們已經看到了單片應用程序如何開始分解為較小的應用程序。它已經在雲原生計算和微服務架構中找到了空前的普及。此外,諸如Docker之類的容器化技術和諸如Kubernetes之類的編排系統僅在這方面有所幫助。
雖然在像Kubernetes這樣的分佈式系統上採用微服務架構有許多優勢,但它具有相當多的複雜性。由於分佈式服務必須相互通信,因此我們必須考慮發現,路由,重試和故障轉移。
還有其他一些問題,例如安全性和可觀察性,我們還必須注意以下問題:
現在,在每個服務中建立這些通信功能可能非常繁瑣,尤其是當服務範圍擴大且通信變得複雜時,更是如此。這正是服務網格可以為我們提供幫助的地方。基本上,服務網格消除了在分佈式軟件系統中管理所有服務到服務通信的責任。
服務網格能夠通過一組網絡代理來做到這一點。本質上,服務之間的請求是通過與服務一起運行但位於基礎結構層之外的代理路由的:
這些代理基本上為服務創建了一個網狀網絡-因此,名稱為服務網狀!通過這些代理,服務網格能夠控制服務到服務通信的各個方面。這樣,我們可以使用它來解決分佈式計算的八個謬誤,這是一組斷言,描述了我們經常對分佈式應用程序做出的錯誤假設。
3.服務網格的特徵
現在,讓我們了解服務網格可以為我們提供的一些功能。請注意,實際功能列表取決於服務網格的實現。但是,總的來說,我們應該在所有實現中都期望其中大多數功能。
我們可以將這些功能大致分為三類:流量管理,安全性和可觀察性。
3.1 流量管理
服務網格的基本特徵之一是流量管理。這包括動態服務發現和路由。它還啟用了一些有趣的用例,例如流量陰影和流量拆分。這些對於執行發布和A / B測試非常有用。
由於所有服務之間的通信都是由服務網格處理的,因此它還啟用了一些可靠性功能。例如,服務網格可以提供重試,超時,速率限制和斷路器。這些現成的故障恢復功能使通信更加可靠。
3.2 安全性方面
服務網格通常還處理服務到服務通信的安全性方面。這包括通過相互TLS(MTLS)強制進行流量加密,通過證書驗證提供身份驗證以及通過訪問策略確保授權。
服務網格中還可能存在一些有趣的安全用例。例如,我們可以實現網絡分段,從而允許某些服務進行通信而禁止其他服務。此外,服務網格可以為審核需求提供精確的歷史信息。
3.3可觀察性
強大的可觀察性是處理分佈式系統複雜性的基本要求。由於服務網格可以處理所有通信,因此正確放置了它可以提供可觀察性的功能。例如,它可以提供有關分佈式跟踪的信息。
服務網格可以生成許多指標,例如延遲,流量,錯誤和飽和度。此外,服務網格還可以生成訪問日誌,為每個請求提供完整記錄。這些對於理解單個服務以及整個系統的行為非常有用。
4.Istio簡介
Istio是最初由IBM,Google和Lyft開發的服務網格的開源實現。它可以透明地分層到分佈式應用程序上,並提供服務網格的所有優點,例如流量管理,安全性和可觀察性。
它旨在與各種部署配合使用,例如本地部署,雲託管,Kubernetes容器以及虛擬機上運行的服務程序。儘管Istio與平台無關,但它經常與Kubernetes平台上部署的微服務一起使用。
從根本上講,Istio的工作原理是將Envoy的擴展版作為代理作為副車部署到每個微服務中:
該代理網絡構成了Istio體系結構的數據平面。這些代理的配置和管理是從控制平面完成的:
控制平面基本上是服務網格的大腦。它在運行時為數據平面中的Envoy代理提供發現,配置和證書管理。
當然,只有在擁有大量相互通信的微服務時,我們才能實現Istio的優勢。在這裡,sidecar代理在專用的基礎架構層中形成一個複雜的服務網格:
Istio在與外部庫和平台集成方面非常靈活。例如,我們可以將Istio與外部日誌記錄平台,遙測或策略系統集成。
5.了解Istio組件
我們已經看到,Istio體系結構由數據平面和控制平面組成。此外,還有幾個使Istio起作用的核心組件。
在本節中,我們將詳細介紹這些核心組件。
5.1 數據平面
Istio的數據平面主要包括Envoy代理的擴展版本。 Envoy是一個開源邊緣和服務代理,可幫助將網絡問題與底層應用程序分離開來。應用程序僅在與localhost
發送和接收消息,而無需了解網絡拓撲。
Envoy的核心是在OSI模型的L3和L4層運行的網絡代理。它通過使用可插入網絡過濾器鏈來執行連接處理。此外,Envoy支持用於基於HTTP的流量的附加L7層過濾器。而且,Envoy對HTTP / 2和gRPC傳輸具有一流的支持。
Istio作為服務網格提供的許多功能實際上是由Envoy代理的基礎內置功能啟用的:
- 流量控制:Envoy通過HTTP,gRPC,WebSocket和TCP流量的豐富路由規則啟用細粒度的流量控制應用
- 網絡彈性:Envoy包括對自動重試,斷路和故障注入的開箱即用支持
- 安全性:Envoy還可以實施安全策略,並對基礎服務之間的通信應用訪問控制和速率限制
Envoy在Istio上表現出色的另一個原因之一是它的可擴展性。 Envoy提供了基於WebAssembly的可插拔擴展模型。這在定制策略執行和遙測生成中非常有用。此外,我們還可以使用基於Proxy-Wasm沙箱API的Istio擴展在Istio中擴展Envoy代理。
5.2 控制平面
如前所述,控制平面負責管理和配置數據平面中的Envoy代理。 istiod
在控制平面中對此負責的組件。在這裡, istiod
負責將高級路由規則和流量控制行為轉換為特定於Envoy的配置,並在運行時將其傳播到邊車。
如果我們回顧一下Istio控制平面的體系結構,將會注意到它曾經是一組相互協作的獨立組件。它包括諸如用於服務發現的Pilot,用於配置的Galley,用於證書生成的Citadel以及用於擴展性的Mixer之類的組件。由於復雜性,這些**單獨的組件被合併為一個稱為istiod
**的單個組件。
從istiod
,istiod仍使用與先前各個組件相同的代碼和API。例如,Pilot負責抽象特定於平台的服務發現機制,並將其合成為Sidecar可以使用的標準格式。因此,Istio可以支持針對多個環境(例如Kubernetes或虛擬機)的發現。
此外, istiod
還提供安全性,通過內置的身份和憑據管理實現強大的服務到服務和最終用戶身份驗證。此外,使用istiod
,我們可以基於服務身份來實施安全策略。過程istiod
還充當證書頒發機構(CA),並生成證書,以便在數據平面中相互TLS(MTLS)通信。
6.Istio的工作方式
我們已經了解了服務網格的典型特徵是什麼。此外,我們介紹了Istio體系結構及其核心組件的基礎。現在,是時候了解Istio如何通過其體系結構中的核心組件提供這些功能了。
我們將專注於我們之前經歷過的相同類別的功能。
6.1流量管理API
我們可以使用Istio流量管理API對服務網格中的流量進行精細控制。我們可以使用這些API將自己的流量配置添加到Istio。此外,我們可以使用Kubernetes自定義資源定義(CRD)定義API資源。幫助我們控制流量路由的關鍵API資源是虛擬服務和目標規則:
基本上,虛擬服務使我們可以配置如何將請求路由到Istio服務網格中的服務。因此,虛擬服務由一個或多個按順序評估的路由規則組成。評估虛擬服務的路由規則後,將應用目標規則。目標規則有助於我們控製到達目標的流量,例如,按版本對服務實例進行分組。
6.2 安全
Istio中的安全性始於為每個服務提供強身份。沿著每特使代理工作運行Istio代理istiod
自動密鑰和證書旋轉:
Istio提供兩種身份驗證類型:對等身份驗證和請求身份驗證。對等身份驗證用於服務到服務的身份驗證,其中Istio提供相互TLS作為全棧解決方案。請求身份驗證用於最終用戶身份驗證,其中Istio使用自定義身份驗證提供程序或OpenID Connect(OIDC)提供程序提供JSON Web令牌(JWT)驗證。
Istio還允許我們通過簡單地將授權策略應用於服務來實施對服務的訪問控制。授權策略對Envoy代理中的入站流量實施訪問控制。這樣,我們就可以在各種級別上應用訪問控制:網格,名稱空間和服務範圍。
6.3 可觀察性
Istio為網狀網絡內的所有服務通信生成詳細的遙測,例如度量,分佈式跟踪和訪問日誌。 Istio生成一組豐富的代理級指標,面向服務的指標和控制平面指標。
之前,Istio遙測體系結構將Mixer作為核心組件。但是從Telemetry v2開始,混音器提供的功能已替換為Envoy代理插件:
此外,Istio通過Envoy代理生成分佈式跟踪。 Istio支持許多跟踪後端,例如Zipkin , Jaeger , Lightstep和Datadog 。我們還可以控制跟踪速率的採樣率。此外,Istio還以一組可配置的格式生成服務流量的訪問日誌。
7.與Istio親身實踐
既然我們已經了解了足夠的背景知識,我們就可以看到Istio的實際應用。首先,我們將在Kubernetes集群中安裝Istio。此外,我們將使用一個簡單的基於微服務的應用程序來演示Istio在Kubernetes上的功能。
7.1 安裝
有多種安裝Istio的方法,但最簡單的方法是下載並解壓縮特定操作系統(例如Windows)的最新版本。提取的軟件包bin
目錄中istioctl
客戶端二進製文件。我們可以使用istioctl
**在目標Kubernetes集群上安裝Istio:**
istioctl install --set profile=demo -y
這會使用演示配置文件將Istio組件安裝在默認的Kubernetes集群上。我們還可以使用任何其他特定於供應商的配置文件來代替演示。
最後,當我們在此Kubernetes集群上部署任何應用程序時,我們需要指示Istio自動注入Envoy sidecar代理:
kubectl label namespace default istio-injection=enabled
我們在kubectl
的前提是,我們的機器上已經有像Minikube這樣的Kubernetes集群和Kubernetes CLI kubectl
7.2 在線下訂單應用程序
為了演示的目的,我們將想像一個非常簡單的在線下訂單應用程序。該應用程序包含三個微服務,它們相互交互以滿足最終用戶的訂購請求:
我們沒有討論這些微服務的細節,但是使用Spring Boot和REST API可以很簡單地創建它們。最重要的是,我們為這些微服務創建了一個Docker映像,以便我們可以將它們部署在Kubernetes上。
7.3 部署方式
在像Minikube這樣的Kubernetes集群上部署容器化的工作負載非常簡單。我們將使用Deployment
和Service
資源類型來聲明和訪問工作負載。通常,我們在YAML文件中定義它們:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: order-service
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
app: order-service
version: v1
spec:
containers:
- name: order-service
image: kchandrakant/order-service:v1
resources:
requests:
cpu: 0.1
memory: 200
---
apiVersion: v1
kind: Service
metadata:
name: order-service
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
selector:
app: order-service
order-service
Deployment
and Service
的非常簡單的定義。同樣,我們可以為inventory-service
和shipping-service
定義YAML文件。
kubectl
部署這些資源也非常簡單:
kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml
由於我們已經為默認名稱空間啟用了自動注入Envoy sidecar代理,因此一切都會由我們來處理。可替代地,我們可以使用kube-inject
的命令istioctl
手動注入特使跨鬥代理。
7.4 訪問應用程序
現在,Istio主要負責處理所有的網狀網絡流量。因此,默認情況下,不允許進出網格的任何流量。 Istio使用網關來管理來自網格的入站和出站流量。這樣,我們可以精確地控制進入或離開網格的流量。 Istio提供了一些預配置的網關代理部署: istio-ingressgateway
和istio-egressgateway
。
我們將為我們的應用程序創建一個網關和一個虛擬服務來實現此目的:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: booking-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: booking
spec:
hosts:
- "*"
gateways:
- booking-gateway
http:
- match:
- uri:
prefix: /api/v1/booking
route:
- destination:
host: booking-service
port:
number: 8080
在這裡,我們利用了Istio提供的默認入口控制器。此外,我們已經定義了一個虛擬服務,將我們的請求路由到booking-service
。
同樣,我們也可以為來自網格的出站流量定義出口網關。
8.Istio的常見用例
現在,我們已經看到瞭如何使用Istio在Kubernetes上部署一個簡單的應用程序。但是,我們仍然沒有利用Istio為我們啟用的任何有趣功能。在本節中,我們將介紹服務網格的一些常見用例,並了解如何使用Istio為我們的簡單應用程序實現它們。
8.1 請求路由
我們可能要以特定方式處理請求路由的原因有多個。例如,我們**可能會部署微shipping-service
**並希望僅將一小部分請求路由到新版本。
我們可以使用虛擬服務的路由規則來實現這一點:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: shipping-service
spec:
hosts:
- shipping-service
http:
- route:
- destination:
host: shipping-service
subset: v1
weight: 90
- destination:
host: shipping-service
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: shipping-service
spec:
host: shipping-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
路由規則還允許我們基於諸如標頭參數之類的屬性來定義匹配條件。此外,目的地字段指定與條件匹配的流量的實際目的地。
8.2 斷路
斷路器本質上是一種軟件設計模式,用於檢測故障並封裝防止故障進一步級聯的邏輯。這有助於創建有彈性的微服務應用程序,以限制故障和延遲尖峰的影響。
在Istio中,我們可以使用DestinationRule
trafficPolicy
配置在調用諸如清單服務之類inventory-service
時應用斷路:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: inventory-service
spec:
host: inventory-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
maxRequestsPerConnection: 1
outlierDetection:
consecutive5xxErrors: 1
interval: 1s
baseEjectionTime: 3m
maxEjectionPercent: 100
在這裡,我們將DestinationRule
maxConnections
為1, httpMaxPendingRequests
為1, maxRequestsPerConnection
為1。這實際上意味著,如果我們將並發請求數超過1,斷路器將開始捕獲一些請求。
8.3 啟用相互TLS
相互身份驗證是指雙方在諸如TLS之類的身份驗證協議中彼此同時進行身份驗證的情況。默認情況下,具有代理的服務之間的所有流量在Istio中都使用相互TLS。但是,沒有代理的服務仍繼續以純文本格式接收流量。
雖然Istio將具有代理的服務之間的所有流量自動升級為相互TLS,但這些服務仍可以接收純文本流量。我們可以選擇使用PeerAuthentication
策略在整個網格範圍內實施雙向TLS:
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
我們還提供了對每個名稱空間或服務而不是在網格範圍內強制實施雙向TLS的選項。但是, PeerAuthentication
服務的PeerAuthentication策略優先於名稱空間範圍的策略。
8.4 使用JWT進行訪問控制
JSON Web令牌(JWT)是用於創建數據的標準,該數據的有效載荷包含聲明許多聲明的JSON 。為了在身份提供者和服務提供者之間傳遞經過身份驗證的用戶的身份和標准或自定義聲明,這一點已被廣泛接受。
我們可以在Istio中啟用授權策略,以允許訪問基於JWT的booking-service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt
namespace: default
spec:
selector:
matchLabels:
app: booking-service
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["[email protected]/[email protected]"]
在這裡, AuthorizationPolicy
強制所有請求具有有效的JWT,並將requestPrincipal
設置為特定值。 Istio通過組合聲明JWT的iss
和sub
requestPrincipal
9.事後思考
因此,到目前為止,我們已經看到像Istio這樣的服務網格如何使我們的生活更輕鬆地處理諸如微服務之類的分佈式體系結構中的許多常見問題。但是儘管如此, Istio還是一個複雜的系統,會增加最終部署的複雜性。與其他所有技術一樣,Istio並非靈丹妙藥,必須謹慎使用。
9.1 我們應該始終使用服務網格嗎?
儘管我們已經看到了使用服務網格的足夠理由,但讓我們列舉一些可能促使我們不使用它的原因:
- 服務網格處理所有服務到服務的通信,而部署和操作服務網格需要支付額外的費用。對於較簡單的應用程序,這可能是不合理的
- 由於我們已經習慣於處理一些此類問題,例如應用程序代碼中的電路中斷,因此可能導致服務網格中的重複處理
- 越來越依賴於諸如服務網格之類的外部系統可能會損害應用程序的可移植性,尤其是因為沒有針對服務網格的行業標準
- 由於服務網格通常通過攔截通過代理的網格流量來工作,因此它可能會給請求增加不希望的延遲
- 服務網格增加了許多其他組件和配置,需要精確處理。這需要專業知識,並增加了學習曲線
- 最後,我們可能最終將操作邏輯(應在服務網格中存在)與業務邏輯(不應在服務網格中)混合在一起
因此,正如我們所看到的,服務網格的故事不僅僅涉及好處,但這並不意味著它們不是真實的。對我們來說,重要的是要仔細評估我們的需求和應用程序的複雜性,然後權衡服務網格的好處和它們所增加的複雜性。
9.2 Istio的替代品有哪些?
儘管Istio非常受歡迎,並得到了業內一些領導者的支持,但它當然不是唯一的選擇。儘管我們在這裡無法進行全面的比較,但讓我們看一下Linkerd和Consul這兩個選項。
Linkerd是已為Kubernetes平台創建的開源服務網格。它也很受歡迎,目前在CNCF中具有孵化項目的地位。它的工作原理類似於Istio等任何其他服務網格。它還利用TCP代理來處理網格流量。 Linkerd使用用Rust編寫的微型代理,稱為Linkerd代理。
總體而言,Linkerd並不比Istio複雜,因為它僅支持Kubernetes。但是,除此之外,Linkerd中可用的功能列表與Istio中可用的功能非常相似。 Linkerd的核心架構也與Istio極為相似。基本上,Linkerd包含三個主要組件:用戶界面,數據平面和控制平面。
Consul是HashiCorp的服務網格的開源實現。它的好處是可以與HashiCorp的其他基礎架構管理產品套件很好地集成,以提供更廣泛的功能。 Consul中的數據平面可以靈活地支持代理以及本機集成模型。它帶有內置代理,但也可以與Envoy一起使用。
除了Kubernetes,Consul還可以與Nomad等其他平台一起使用。 Consul通過在每個節點上運行Consul代理以執行運行狀況檢查來工作。這些代理與一台或多台存儲和復制數據的Consul服務器通信。儘管它提供了Istio等服務網格的所有標準功能,但它是部署和管理的更複雜的系統。
10.結論
總而言之,在本教程中,我們介紹了服務網格模式的基本概念以及它提供給我們的功能。特別是,我們詳細介紹了Istio。這涵蓋了Istio的核心體系結構及其基本組件。此外,我們詳細介紹了一些常見用例的安裝和使用Istio的細節。