我們已經(jīng)看到，Istio體系結(jié)構(gòu)由數(shù)據(jù)平面和控制平面組成。此外，還有幾個(gè)使Istio起作用的核心組件。在本節(jié)中，我們將詳細(xì)介紹這些核心組件。Istio的數(shù)據(jù)平面主要包括Envoy代理的擴(kuò)展版本。Envoy是一個(gè)開源邊緣和服務(wù)代理，可幫助將網(wǎng)絡(luò)問題與底層應(yīng)用程序分離開來。應(yīng)用程序僅向localhost發(fā)送消息或從localhost接收消息，而無需了解網(wǎng)絡(luò)拓?fù)洹?/section>Envoy的核心是在OSI模型的L3和L4層運(yùn)行的網(wǎng)絡(luò)代理。它通過使用可插入網(wǎng)絡(luò)過濾器鏈來執(zhí)行連接處理。此外，Envoy支持用于基于HTTP的流量的附加L7層過濾器。而且，Envoy對(duì)HTTP/2和gRPC傳輸具有一流的支持。Istio作為服務(wù)網(wǎng)格提供的許多功能實(shí)際上是由Envoy代理的基礎(chǔ)內(nèi)置功能啟用的：流量控制：Envoy通過HTTP，gRPC，WebSocket和TCP流量的豐富路由規(guī)則啟用細(xì)粒度的流量控制應(yīng)用
網(wǎng)絡(luò)彈性：Envoy包括對(duì)自動(dòng)重試，斷路和故障注入的開箱即用支持
安全性：Envoy還可以實(shí)施安全策略，并對(duì)基礎(chǔ)服務(wù)之間的通信應(yīng)用訪問控制和速率限制
Envoy在Istio上表現(xiàn)出色的另一個(gè)原因之一是它的可擴(kuò)展性。Envoy提供了基于WebAssembly的可插拔擴(kuò)展模型。這在定制策略執(zhí)行和遙測(cè)生成中非常有用。此外，我們還可以使用基于Proxy-Wasm沙箱API的Istio擴(kuò)展在Istio中擴(kuò)展Envoy代理。如上所述，控制平面負(fù)責(zé)管理和配置數(shù)據(jù)平面中的Envoy代理。在Istio架構(gòu)中，控制面核心組件是istiod，Istiod負(fù)責(zé)將高級(jí)路由規(guī)則和流量控制行為轉(zhuǎn)換為特定于Envoy的配置，并在運(yùn)行時(shí)將其傳播到Sidercar。如果我們回顧一下Istio控制平面的架構(gòu)，將會(huì)注意到它曾經(jīng)是一組相互協(xié)作的獨(dú)立組件。它包括諸如用于服務(wù)發(fā)現(xiàn)的Pilot，用于配置的Galley，用于證書生成的Citadel以及用于可擴(kuò)展性的Mixer之類的組件。由于復(fù)雜性，這些單獨(dú)的組件被合并為一個(gè)稱為istiod的單個(gè)組件。從根本上來說，istiod仍使用與先前各個(gè)組件相同的代碼和API。例如，Pilot負(fù)責(zé)抽象特定于平臺(tái)的服務(wù)發(fā)現(xiàn)機(jī)制，并將其合成為Sidecar可以使用的標(biāo)準(zhǔn)格式。因此，Istio可以支持針對(duì)多個(gè)環(huán)境（例如Kubernetes或虛擬機(jī)）的發(fā)現(xiàn)。此外，istiod還提供安全性，通過內(nèi)置的身份和憑據(jù)管理實(shí)現(xiàn)強(qiáng)大的服務(wù)到服務(wù)和最終用戶身份驗(yàn)證。此外，借助istiod，我們可以基于服務(wù)身份來實(shí)施安全策略。該過程也充當(dāng)證書頒發(fā)機(jī)構(gòu)（CA）并生成證書，以促進(jìn)數(shù)據(jù)平面中的相互TLS（MTLS）通信。
我們已經(jīng)了解了服務(wù)網(wǎng)格的典型特征是什么。此外，我們介紹了Istio架構(gòu)及其核心組件的基礎(chǔ)?，F(xiàn)在，是時(shí)候了解Istio如何通過其架構(gòu)中的核心組件提供這些功能了。我們將專注于我們之前經(jīng)歷過的相同類別的功能。我們可以使用Istio流量管理API對(duì)服務(wù)網(wǎng)格中的流量進(jìn)行精細(xì)控制。我們可以使用這些API將自己的流量配置添加到Istio。此外，我們可以使用Kubernetes自定義資源定義（CRD）定義API資源。幫助我們控制流量路由的關(guān)鍵API資源是虛擬服務(wù)和目標(biāo)規(guī)則：基本上，虛擬服務(wù)使我們可以配置如何將請(qǐng)求路由到Istio服務(wù)網(wǎng)格中的服務(wù)。因此，虛擬服務(wù)由一個(gè)或多個(gè)按順序評(píng)估的路由規(guī)則組成。評(píng)估虛擬服務(wù)的路由規(guī)則后，將應(yīng)用目標(biāo)規(guī)則。目標(biāo)規(guī)則有助于我們控制到達(dá)目標(biāo)的流量，例如，按版本對(duì)服務(wù)實(shí)例進(jìn)行分組。Istio為每個(gè)服務(wù)提供身份。與每個(gè)Envoy代理一起運(yùn)行的Istio代理與istiod一起使用以自動(dòng)進(jìn)行密鑰和證書輪換：Istio提供兩種身份驗(yàn)證——對(duì)等身份驗(yàn)證和請(qǐng)求身份驗(yàn)證。對(duì)等身份驗(yàn)證用于服務(wù)到服務(wù)的身份驗(yàn)證，其中Istio提供雙向TLS作為全棧解決方案。請(qǐng)求身份驗(yàn)證用于最終用戶身份驗(yàn)證，其中Istio使用自定義身份驗(yàn)證提供程序或OpenID Connect（OIDC）提供程序提供JSON Web令牌（JWT）驗(yàn)證。Istio還允許我們通過簡(jiǎn)單地將授權(quán)策略應(yīng)用于服務(wù)來實(shí)施對(duì)服務(wù)的訪問控制。授權(quán)策略對(duì)Envoy代理中的入站流量實(shí)施訪問控制。這樣，我們就可以在各種級(jí)別上應(yīng)用訪問控制：網(wǎng)格，命名空間和服務(wù)范圍。Istio為網(wǎng)格網(wǎng)絡(luò)內(nèi)的所有服務(wù)通信生成詳細(xì)的遙測(cè)，例如度量，分布式跟蹤和訪問日志。Istio生成一組豐富的代理級(jí)指標(biāo)，面向服務(wù)的指標(biāo)和控制平面指標(biāo)。之前，Istio遙測(cè)體系結(jié)構(gòu)將Mixer作為核心組件。但是從Telemetry v2開始，混音器提供的功能已替換為Envoy代理插件：此外，Istio通過Envoy代理生成分布式跟蹤。Istio支持許多跟蹤后端，例如Zipkin，Jaeger，Lightstep和Datadog。我們還可以控制跟蹤速率的采樣率。此外，Istio還以一組可配置的格式生成服務(wù)流量的訪問日志。
-? ? ?Istio?實(shí)戰(zhàn)? ? -
上面我們已經(jīng)講述了Istio原理和架構(gòu)，接下來我們開始實(shí)戰(zhàn)部分。首先，我們將在Kubernetes集群中安裝Istio。此外，我們將使用一個(gè)簡(jiǎn)單的基于微服務(wù)的應(yīng)用程序來演示Istio在Kubernetes上的功能。有多種安裝Istio的方法，但最簡(jiǎn)單的方法是下載并解壓縮特定操作系統(tǒng)（例如Windows）的最新版本。提取的軟件包在bin目錄中包含istioctl客戶端二進(jìn)制文件。我們可以使用istioctl在目標(biāo)Kubernetes集群上安裝Istio：istioctl?install?--set?profile=demo?-y
這會(huì)使用演示配置文件將Istio組件安裝在默認(rèn)的Kubernetes集群上。我們還可以使用任何其他特定于供應(yīng)商的配置文件來代替演示。最后，當(dāng)我們?cè)诖薑ubernetes集群上部署任何應(yīng)用程序時(shí)，我們需要指示Istio自動(dòng)注入Envoy sidecar代理：kubectl?label?namespace?default?istio-injection=enabled
我們?cè)谶@里使用kubectl的前提是，我們的機(jī)器上已經(jīng)有像Minikube這樣的Kubernetes集群和Kubernetes CLI kubectl。為了演示，我們將想象一個(gè)非常簡(jiǎn)單的在線下訂單應(yīng)用程序。該應(yīng)用程序包含三個(gè)微服務(wù)，它們相互交互以滿足最終用戶的訂購請(qǐng)求：我們沒有討論這些微服務(wù)的細(xì)節(jié)，但是使用Spring Boot和REST API可以很簡(jiǎn)單地創(chuàng)建它們。最重要的是，我們?yōu)檫@些微服務(wù)創(chuàng)建了一個(gè)Docker鏡像，以便我們可以將它們部署在Kubernetes上。在像Minikube這樣的Kubernetes集群上部署容器化的工作負(fù)載非常簡(jiǎn)單。我們將使用Deployment和Service資源類型來聲明和訪問工作負(fù)載。通常，我們?cè)赮AML文件中定義它們：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
對(duì)于訂單服務(wù)的“部署和服務(wù)”，這是一個(gè)非常簡(jiǎn)單的定義。同樣，我們可以為庫存服務(wù)和運(yùn)輸服務(wù)定義YAML文件。使用kubectl部署這些資源也非常簡(jiǎn)單：kubectl?apply?-f?booking-service.yaml?-f?inventory-service.yaml?-f?shipping-service.yaml
由于我們已經(jīng)為默認(rèn)命名空間啟用了自動(dòng)注入Envoy sidecar代理，因此一切都會(huì)由istiod來處理?；蛘?，我們可以使用istioctl的kube-inject命令手動(dòng)注入Envoy sidecar代理。現(xiàn)在，Istio主要負(fù)責(zé)處理所有的網(wǎng)狀網(wǎng)絡(luò)流量。因此，默認(rèn)情況下，不允許進(jìn)出網(wǎng)格的任何流量。Istio使用網(wǎng)關(guān)來管理來自網(wǎng)格的入站和出站流量。這樣，我們可以精確地控制進(jìn)入或離開網(wǎng)格的流量。Istio提供了一些預(yù)配置的網(wǎng)關(guān)代理部署：istio-ingressgateway和istio-egressgateway。我們將為我們的應(yīng)用程序創(chuàng)建一個(gè)網(wǎng)關(guān)和一個(gè)虛擬服務(wù)來實(shí)現(xiàn)此目的：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提供的默認(rèn)入口控制器。此外，我們已經(jīng)定義了一個(gè)虛擬服務(wù)，將我們的請(qǐng)求路由到預(yù)訂服務(wù)。同樣，我們也可以為來自網(wǎng)格的出站流量定義出口網(wǎng)關(guān)。
現(xiàn)在，我們已經(jīng)看到了如何使用Istio在Kubernetes上部署一個(gè)簡(jiǎn)單的應(yīng)用程序。但是，我們?nèi)匀粵]有利用Istio為我們啟用的任何有趣功能。在本節(jié)中，我們將介紹服務(wù)網(wǎng)格的一些常見用例，并了解如何使用Istio為我們的簡(jiǎn)單應(yīng)用程序?qū)崿F(xiàn)它們。我們可能要以特定方式處理請(qǐng)求路由的原因有多個(gè)。例如，我們可能會(huì)部署微服務(wù)的多個(gè)版本，例如運(yùn)輸服務(wù)，并希望僅將一小部分請(qǐng)求路由到新版本。我們可以使用虛擬服務(wù)的路由規(guī)則來實(shí)現(xiàn)這一點(diǎn)：apiVersion:?networking.istio.io/v1alpha3
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
路由規(guī)則還允許我們基于諸如header參數(shù)之類的屬性來定義匹配條件。此外，目的地字段指定與條件匹配的流量的實(shí)際目的地。熔斷器基本上是一種軟件設(shè)計(jì)模式，用于檢測(cè)故障并封裝防止故障進(jìn)一步級(jí)聯(lián)的邏輯。這有助于創(chuàng)建有彈性的微服務(wù)應(yīng)用程序，以限制故障和延遲尖峰的影響。在Istio中，我們可以使用DestinationRule中的trafficPolicy配置在調(diào)用諸如清單服務(wù)之類的服務(wù)時(shí)應(yīng)用熔斷：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。這實(shí)際上意味著，如果我們將并發(fā)請(qǐng)求數(shù)超過1，熔斷器將開始trap一些請(qǐng)求。雙向身份驗(yàn)證是指雙方在諸如TLS之類的身份驗(yàn)證協(xié)議中同時(shí)相互進(jìn)行身份驗(yàn)證的情況。默認(rèn)情況下，具有代理的服務(wù)之間的所有流量在Istio中都使用相互TLS。但是，沒有代理的服務(wù)仍繼續(xù)以純文本格式接收流量。雖然Istio將具有代理的服務(wù)之間的所有流量自動(dòng)升級(jí)為雙向TLS，但這些服務(wù)仍可以接收純文本流量。我們可以選擇使用PeerAuthentication策略在整個(gè)網(wǎng)格范圍內(nèi)實(shí)施雙向TLS：apiVersion:?"security.istio.io/v1beta1"
kind:?"PeerAuthentication"
metadata:
??name:?"default"
??namespace:?"istio-system"
spec:
??mtls:
????mode:?STRICT
我們還提供了對(duì)每個(gè)命名空間或服務(wù)而不是在網(wǎng)格范圍內(nèi)強(qiáng)制實(shí)施雙向TLS的選項(xiàng)。但是，特定于服務(wù)的PeerAuthentication策略優(yōu)先于命名空間范圍的策略。JSON Web令牌（JWT）是用于創(chuàng)建數(shù)據(jù)的標(biāo)準(zhǔn)，該數(shù)據(jù)的有效載荷中包含聲明許多聲明的JSON。為了在身份提供者和服務(wù)提供者之間傳遞經(jīng)過身份驗(yàn)證的用戶的身份和標(biāo)準(zhǔn)或自定義聲明，這一點(diǎn)已被廣泛接受。我們可以在Istio中啟用授權(quán)策略，以允許訪問基于JWT的預(yù)訂服務(wù)之類的服務(wù)：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強(qiáng)制所有請(qǐng)求具有有效的JWT，并將requestPrincipal設(shè)置為特定值。Istio通過組合聲明JWT的iss和sub來創(chuàng)建requestPrincipal屬性。
因此，到目前為止，我們已經(jīng)看到像Istio這樣的服務(wù)網(wǎng)格如何使我們更輕松地處理諸如微服務(wù)之類的分布式架構(gòu)中的許多常見問題。但是盡管如此，Istio還是一個(gè)復(fù)雜的系統(tǒng)，會(huì)增加最終部署的復(fù)雜性。與其他所有技術(shù)一樣，Istio并非靈丹妙藥，必須謹(jǐn)慎使用。我們應(yīng)該始終使用服務(wù)網(wǎng)格嗎？盡管我們已經(jīng)看到了使用服務(wù)網(wǎng)格的足夠理由，但下面列舉了一些可能促使我們不使用它的原因：服務(wù)網(wǎng)格處理所有服務(wù)到服務(wù)的通信，而部署和操作服務(wù)網(wǎng)格則需要支付額外的費(fèi)用。對(duì)于較簡(jiǎn)單的應(yīng)用程序，這可能是不合理的
由于我們已經(jīng)習(xí)慣于處理一些此類問題，例如應(yīng)用程序代碼中的熔斷，因此可能導(dǎo)致服務(wù)網(wǎng)格中的重復(fù)處理
越來越依賴于諸如服務(wù)網(wǎng)格之類的外部系統(tǒng)可能會(huì)損害應(yīng)用程序的可移植性，尤其是因?yàn)闆]有針對(duì)服務(wù)網(wǎng)格的行業(yè)標(biāo)準(zhǔn)
由于服務(wù)網(wǎng)格通常通過攔截通過代理的網(wǎng)格流量來工作，因此它可能會(huì)給請(qǐng)求增加不希望的延遲
服務(wù)網(wǎng)格增加了許多其他組件和配置，需要精確處理。這需要專業(yè)知識(shí)，并增加了學(xué)習(xí)曲線
最后，我們可能最終將操作邏輯（應(yīng)在服務(wù)網(wǎng)格中存在）與業(yè)務(wù)邏輯（不應(yīng)在服務(wù)網(wǎng)格中）混合在一起
因此，正如我們所看到的，服務(wù)網(wǎng)格的故事不僅僅涉及好處，但這并不意味著它們不是真的。對(duì)我們來說，重要的是要仔細(xì)評(píng)估我們的需求和應(yīng)用程序的復(fù)雜性，然后權(quán)衡服務(wù)網(wǎng)格的好處和它們所增加的復(fù)雜性。盡管Istio非常受歡迎，并得到了業(yè)內(nèi)一些領(lǐng)導(dǎo)者的支持，但它當(dāng)然不是唯一的選擇。盡管我們?cè)谶@里無法進(jìn)行全面的比較，但讓我們看一下Linkerd和Consul這兩個(gè)選項(xiàng)。Linkerd是已為Kubernetes平臺(tái)創(chuàng)建的開源服務(wù)網(wǎng)格。它也很受歡迎，目前在CNCF中具有孵化項(xiàng)目的地位。它的工作原理類似于Istio等任何其他服務(wù)網(wǎng)格。它還利用TCP代理來處理網(wǎng)格流量。Linkerd使用用Rust編寫的微型代理，稱為L(zhǎng)inkerd代理。總體而言，Linkerd并不比Istio復(fù)雜，因?yàn)樗鼉H支持Kubernetes。但是，除此之外，Linkerd中可用的功能列表與Istio中可用的功能非常相似。Linkerd的核心架構(gòu)也非常類似于Istio?；旧希琇inkerd包含三個(gè)主要組件：用戶界面，數(shù)據(jù)平面和控制平面。Consul是HashiCorp的服務(wù)網(wǎng)格的開源實(shí)現(xiàn)。它的好處是可以與HashiCorp的其他基礎(chǔ)架構(gòu)管理產(chǎn)品套件很好地集成，以提供更廣泛的功能。Consul中的數(shù)據(jù)平面可以靈活地支持代理以及本機(jī)集成模型。它帶有內(nèi)置代理，但也可以與Envoy一起使用。除了Kubernetes，Consul還可以與Nomad等其他平臺(tái)一起使用。Consul通過在每個(gè)節(jié)點(diǎn)上運(yùn)行Consul代理以執(zhí)行運(yùn)行狀況檢查來工作。這些代理與一臺(tái)或多臺(tái)存儲(chǔ)和復(fù)制數(shù)據(jù)的Consul服務(wù)器通信。盡管它提供了服務(wù)網(wǎng)格（如Istio）的所有標(biāo)準(zhǔn)功能，但它是部署和管理的更復(fù)雜的系統(tǒng)。
總而言之，在本教程中，我們介紹了服務(wù)網(wǎng)格模式的基本概念以及它提供給我們的功能。特別是，我們?cè)敿?xì)介紹了Istio。這涵蓋了Istio的核心架構(gòu)及其基本組件。此外，我們?cè)敿?xì)介紹了一些常見用例的安裝和使用Istio的細(xì)節(jié)。
作者：唐建法
來源：Mongoing中文社區(qū)
