溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關Istio流量管理的示例分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
本頁面概述了Istio中流量管理的工作原理，包括流量管理原則的優點。我們假定你已經閱讀了什么是Istio？ 并熟悉Istio的高層架構。 您可以在本節的其他指南中找到有關流量管理功能的更多信息。
Istio中流量管理的核心組件是Pilot，它管理和配置部署在Istio服務網格中的所有Envoy代理實例。它允許你指定要使用哪些規則在Envoy代理之間路由流量，并配置故障恢復功能，例如超時，重試和斷路器。 它還維護網格中所有服務的規范模型，并使用它來讓Envoys 通過其服務發現了解網格中的其他實例。
每個Envoy實例根據從Pilot獲取的信息和其負載平衡池中其他實例的定期運行狀況檢查獲取的信息來維護負載平衡信息，從而使其能夠在遵循其指定的路由規則的情況下智能分配目標實例之間的流量。
使用Istio的流量管理模型基本上將交通流量和基礎設施擴展分離，讓運維通過Pilot為流量配置規則，而不是哪些特定的Pod/VM應該接收流量 - Pilot和智能Envoy代理負責監督其余流量。因此，例如，你可以通過Pilot指定您希望特定服務的5％流量轉換為金絲雀版本，而不用考慮金絲雀版本的大小，或根據請求內容將流量發送到特定版本。
將流量從基礎架構中分離出來，使Istio能夠提供各種流量管理功能，而且這些功能與應用代碼分離。除了A/B測試，滾動部署和金絲雀發布之外，它還使用超時、重試和斷路器處理故障恢復，以及故障注入，以測試跨服務的故障恢復策略的兼容性。 這些功能都是通過在服務網格中部署的Envoy sidecars/proxy 實現的。
Pilot負責整個Istio服務網格中部署的Envoy實例的生命周期。
如上圖所示，Pilot維護一個獨立于底層平臺的服務網格，所有的服務都通過Envoy 加入服務風格中。Pilot中的Platform Adapter 負責適當地填充此規范模型。 例如，Pilot中的Kubernetes適配器實現必要的controllers，以觀察Kubernetes API server以更改pod注冊信息、ingress 資源和存儲流量管理規則的第三方資源。 這些數據被翻譯成規范的表示。Envoy的配置是基于規范表（canonical representation）示生成的。
Pilot公開了用于 服務發現 的API，可動態更新負載平衡池和路由表。這些API將Envoy與平臺特定的細微差別分離開來，簡化了設計并提高了跨平臺的可移植性。
運維可以通過Pilot的規則API指定高級流量管理規則。 這些規則被轉換成低級（low-level）配置并通過discovery API分發給Envoy實例。
描述如何在Istio服務網格中的服務之間路由請求。
如Pilot所述，服務網格中服務的規范表示是由Pilot維護的。服務的Istio模型與其在底層平臺（Kubernetes，Mesos，Cloud Foundry等）中的表現方式無關。平臺相關的適配器負責使用平臺中的元數據填充Istio內部模型。
Istio引入了服務版本的概念，該版本是按版本(v1, v2)或環境(staging, prod)細分服務實例的更細化的方式。 這些變體不一定是不同的API版本：它們可能是對同一服務的迭代更改，部署在不同的環境中（prod，staging，dev等）。 常用的場景包括A/B測試或金絲雀發布。 Istio的流量路由規則可以指服務版本，以提供對服務之間流量的額外控制。
如上圖所示，client不知道服務的不同版本。他們可以繼續使用服務的主機名/IP地址訪問服務。 Envoy sidecar/proxy 攔截并轉發client和服務之間的所有請求/響應。
Envoy 根據運運維人員使用Pilot指定的路由規則動態確定其實際服務版本。該模型使應用程序代碼能夠將其自身從其相關服務的演變中分離出來，同時還提供其他好處（請參Mixer）。 路由規則允許Envoy根據標準選擇版本，例如headers，與source/destination關聯的標簽，分配給每個版本的權重。
Istio還為流量提供相同服務版本的多個實例的負載平衡。 您可以在Discovery和Load-Balancing中找到更多關于此的信息。
Istio不提供DNS。 應用程序可以嘗試使用底層平臺中存在的DNS服務（kube-dns，mesos-dns等）來解析FQDN。
Istio假設進入和離開服務網格的所有流量都通過Envoy代理。通過在服務前面部署Envoy代理，運維人員可以進行A/B測試，金絲雀部署服務等，以用于面向用戶的服務。 同樣，運維人員可以通過sidecar Envoy將流量路由到外部Web服務（例如，訪問Maps API或視頻服務API），從而增加故障恢復功能，例如超時，重試，斷路器等，并獲取詳細信息 有關這些服務連接的度量標準。
本節介紹Istio如何負載均衡服務網格中服務實例間的流量。
服務注冊：Istio假設存在一個服務注冊中心，以跟蹤應用程序中服務的Pod/VM。它還假設新的服務實例會自動注冊到服務注冊中心，不健康的實例會被自動刪除。Kubernetes，Mesos等平臺已經為基于容器的應用程序提供了這樣的功能。 基于VM的應用程序存在過多的解決方案。
服務發現：Pilot 使用來自服務注冊中心的信息并提供與平臺無關的服務發現接口。Mesh中的Envoy實例執行服務發現并相應地動態更新其負載均衡池。
如上圖所示，網格中的服務使用其DNS名稱相互訪問。 綁定到服務的所有HTTP流量都會通過Envoy自動重新路由。 Envoy 在負載均衡池中的實例之間分配流量。 雖然Envoy支持多種復雜的負載均衡算法，但Istio目前允許三種負載均衡模式：輪詢，隨機和權重最小請求。
除了負載平衡之外，Envoy還會定期檢查負載均衡池中每個實例的健康狀況。Envoy遵循斷路器配置模式，根據健康檢查API調用的故障率將實例歸類為健康或不健康。 換句話說，當給定實例的狀況檢查失敗次數超過預先指定的閾值時，它將從負載均衡池中移除。類似地，當運行狀況檢查數超過預先指定的健康閾值時，實例將被添加回負載均衡池。 你可以在處理故障中找到有關Envoy故障處理功能的更多信息。
服務可以通過HTTP 503響應健康檢查來積極減輕負載。 在這種情況下，服務實例將立即從調用者的負載平衡池中移除。
Envoy提供了一套開箱即用的插拔式故障恢復功能，可以在應用程序中利用這些功能。功能包括：
超時
根據超時時間和重試次數、間隔等配置進行重試
并發連接數和對上游服務的請求限制
對負載均衡池的每個成員進行主動（定期）健康檢查
針對負載平衡池中針對每個實例應用的細粒度斷路器（被動健康檢查）
這些功能可以在運行時通過Istio的流量管理規則進行動態配置。
重試之間的抖動使重試對超負載的上游服務的影響最小，而超時設置可確保調用服務在可預測的時間范圍內獲得響應（成功/失敗）。
主動和被動健康檢查（上述4和5）的組合可最大限度地減少訪問負載均衡池中不健康實例的機會。與平臺級健康檢查（如Kubernetes或Mesos支持的那些）結合使用時，應用程序可以確保不健康的pods/容器/虛擬機可以快速服務網格中清除，從而最大限度地減少請求失敗并減少對延遲的影響。
這些功能一起使服務網格能夠容忍失敗的nodes ，并防止由于級聯不穩定而導致本地故障影響到其他nodes。
Istio的流量管理規則允許運維為每個服務/版本的故障恢復設置全局默認值。但是，服務的使用者也可以通過特殊的HTTP頭提供請求級覆蓋來覆蓋超時和重試默認值。 通過Envoy代理實現，頭文件分別是 x-envoy-upstream-rq-timeout-ms 和 x-envoy-max-retries。
Q: 在Istio中運行時，應用程序是否還能處理失敗？
可以。 Istio提高了網格中服務的可靠性和可用性。但是，應用程序需要處理失敗（錯誤）并采取適當的后備（fallback）操作。例如，當負載平衡池中的所有實例都失敗時，Envoy將返回HTTP 503.應用程序負責處理來自上游服務的HTTP 503錯誤。
Q: Envoy的故障恢復功能是否會中斷已使用容錯庫（例如Hystrix）的應用程序？
不會。Envoy 對應用是完全透明的。由Envoy返回的失敗響應與由進行調用的上游服務返回的失敗響應無法區分。
Q: 在同時使用應用程序級類庫和Envoy時如何處理失敗？
給同一個服務的兩個故障恢復策略（例如，兩個超時 - 一個設置在Envoy中，另一個設置在應用程序的庫中），當故障發生時，兩個限制中較強的將會被觸發。 例如，如果應用程序為服務的API調用設置5秒的超時，而操作員配置了10秒的超時，則應用程序的超時將首先啟動。 同樣，如果Envoy的斷路器在應用程序的斷路器之前觸發，API調用服務將從Envoy獲得503。
雖然Envoy sidecar/proxy為運行在Istio上的服務提供了大量故障恢復機制，但仍然有必要測試整個應用程序的端到端故障恢復能力。 錯誤配置的故障恢復策略（例如，跨服務調用的不兼容/限制性超時）可能導致應用程序中關鍵服務持續不可用，從而導致用戶體驗不佳。
Istio支持將指定協議的故障注入到網絡中，而不是殺死Pod，延遲或破壞TCP層的數據包。 我們的基本原理是，無論網絡級別失敗，應用層觀察到的失敗都是相同的，并且可以在應用層注入更有意義的失敗（例如，HTTP錯誤代碼）以增加應用程序的彈性。
運維人員可以配置故障注入到符合特定標準的請求中。運維可以進一步限制應該發生故障的請求的百分比。可以注入兩種類型的故障：延遲和中止。延遲是定時失敗，模仿網絡延遲增加或上游服務超負荷。中止是模仿上游服務故障的崩潰故障。 中止通常以HTTP錯誤代碼或TCP連接失敗的形式出現。
有關更多詳細信息，請參閱下一節Istio的流量管理規則。
Istio提供了一個簡單的配置模型來控制API調用和第4層流量如何在應用程序中的各種服務之間流動。配置模型允許運維配置服務級屬性，如斷路器，超時，重試，以及設置常見的持續部署任務，如金絲雀部署，A/B測試，基于百分比流量的分階段發布等。
例如，可以使用以下配置將reviews服務的傳入流量的100％發送到版本“v1”：
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1
該配置表示發送到reviews服務（在hosts 字段中指定）的流量應該路由到reviews服務實例的v1子集中。 路由subset 在相應的目標規則配置中指定定義的子集的名稱：
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2
subset 指定一個或多個標識版本實例的標簽。例如，在Istio的Kubernetes部署中，“version：v1”表示只有包含“version：v1”標簽的pod才會接收流量。
可以使用istioctl CLI配置規則，也可以使用kubectl命令在Kubernetes deployment 中配置規則，但只有istioctl 會驗證配置是否正確，我們建議使用istioctl 。 有關示例，請參閱配置請求路由任務。
Istio中有四種流量管理配置資源：VirtualService，DestinationRule，ServiceEntry和Gateway。 下面介紹使用這些資源的一些重要方面。詳細信息請參閱參考。
VirtualService定義了控制服務請求如何在Istio服務網格中路由的規則。例如，virtual service可以將請求路由到不同版本的服務，或者實際上可以將請求路由到完全不同的服務。 請求可以根據請求源和目標、HTTP路徑和header 字段以及與各個服務版本相關的權重進行路由。
路由規則對應于VirtualService配置中指定的一個或多個請求目標hosts。 這些hosts可能與實際的目標工作負載相同也可能不同，甚至可能沒有對應網格中的實際可路由服務。例如，要使用其內部網格名稱reviews 或通過hostbookinfo.com為請求評論服務定義路由規則，VirtualService可以有一個hosts字段，如下所示：
hosts: - reviews - bookinfo.com
hosts字段隱式或顯式指定一個或多個全限定域名（FQDN）。上面的短名稱reviews將隱式擴展為FQDN。 例如，在Kubernetes環境中，reviews完整的域名為來自VirtualSevice的集群和名稱空間（例如，reviews.default.svc.cluster.local）。
Rules 可以選擇性地限定為僅適用于匹配某些特定條件的請求，例如以下條件：
限制為特定調用者。 例如，Rules 可以指定ratings僅適用于來自reviews 服務（pods）的的調用。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: sourceLabels: app: reviews ...
sourceLabels 的值取決于service的實現。 例如，在Kubernetes中，它可能與相應Kubernetes 中pod選擇器中使用的標簽相同。
限制為特定版本的調用者。 例如，以下規則將之前示例限定為僅允許reviews 服務“v2”版本的調用。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 ...
根據HTTP headers選擇規則。 例如，以下規則僅適用于包含字符串“user = jason”的“cookie”頭的請求。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...
如果配置了多個header，則必須所有的header全部匹配才可以。
可以同時設置多個標準。 在這種情況下，根據嵌套情況，使用AND或OR語義。 如果多個條件嵌套在單個匹配子句中，則條件為ANDed。 例如，以下規則僅適用于請求的來源為“reviews:v2”且包含“user = jason”的“cookie”的情況。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...
相反，如果條件顯示在單獨的匹配條件中，則有一個匹配即可（OR語義）：
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...
每條路由規則標識一個或多個加權后端，以便在規則激活時進行調用。每個后端對應于目標服務的特定版本，其中版本可以使用標簽表示。如果多個已注冊實例有相同的標簽，則根據配置的負載平衡策略進行路由，默認為循環。
例如，以下規則將reviews 服務的25％流量路由到具有“v2”標簽的實例，剩余流量（即75％）路由到“v1”。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 75 - destination: host: reviews subset: v2 weight: 25
默認情況下，http請求的超時時間為15秒，但是這可以在路由規則中配置，如下所示：
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - route: - destination: host: ratings subset: v1 timeout: 10s
也可以在路由規則中配置http請求的重試次數。 在超時期限內，最大嘗試次數或盡可能多的嘗試次數可以設置如下：
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - route: - destination: host: ratings subset: v1 retries: attempts: 3 perTryTimeout: 2s
請注意，請求超時和重試也可以基于每個請求進行配置。
請參閱請求超時任務以了解超時控制的示例。
路由規則可以指定一個或多個故障注入（人為制造故障），同時將http請求轉發到規則的相應請求目標。 故障可以是延遲或中止。
以下示例將向微服務ratings “v1”版本的10％請求中引入5秒延遲。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: delay: percent: 10 fixedDelay: 5s route: - destination: host: ratings subset: v1
另一種類型的故障，中止，可用于模擬請求中斷故障。
以下示例會將ratings 服務“v1”版本10％請求的HTTP請求返回 400錯誤代碼。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: abort: percent: 10 httpStatus: 400 route: - destination: host: ratings subset: v1
有時延遲和中止故障一起使用。例如，以下規則將從reviews 服務“v2”到評ratings 服務“v1”的所有請求延遲5秒，然后中止10％：
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 fault: delay: fixedDelay: 5s abort: percent: 10 httpStatus: 400 route: - destination: host: ratings subset: v1
要查看故障注入的實際情況，請參閱故障注入任務。
當給定destination有多個規則時，它們按照它們在VirtualService中出現的順序進行評估，即列表中的第一個規則具有最高優先級。
為什么優先級重要？ 如果服務的路由規則純粹是基于權重的時候，就可以在單個規則中配置它。但是，當使用其他標準（例如，來自特定用戶的請求）來路由流量時，需要多個規則來配置路由。這里必須仔細考慮規則優先級，以確保以正確的順序執行規則。
通用路由規范的一種常見模式是提供一個或多個優先級更高的規則，以便通過source/headers來限定規則，然后提供一個沒有匹配條件的單個基于權重的規則，最后為所有其他情況提供流量的加權分配。
例如，以下VirtualService包含2個規則，這些規則一起指定包含名為“Foo”且值為“bar”的header的reviews服務的所有請求都將發送到“v2”實例。 所有其余的請求將被發送到“v1”。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: Foo: exact: bar route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1
請注意，這里配置中基于header的規則具有更高的優先級。如果它較低，這些規則將不會如預期的那樣工作，因為基于權重的規則（沒有特定的匹配標準）將首先被評估，然后將所有流量簡單地路由到“v1”，甚至包括匹配的“Foo “頭。一旦找到適用于傳入請求的規則，它將被執行并且規則評估過程將終止。 這就是為什么當存在多個規則時仔細考慮每個規則的優先級是非常重要的。
DestinationRule配置在虛擬服務路由發生后，應用于請求的一組策略。它們由服務所有者去配置定義，描述斷路器，負載平衡器設置，TLS設置等。
DestinationRule還定義相應目的地主機的可尋址子集（即，版本名）。 在將流量發送到特定版本的服務時，這些子集用于VirtualService路由規范。
以下DestinationRule 配置reviews 服務的策略和subsets ：
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN - name: v3 labels: version: v3
請注意，可以在單個DestinationRule配置中指定多個策略（例如，默認和v2）。
可以根據許多標準（例如連接和請求限制）設置簡單的斷路器。
例如，以下DestinationRule設置了與reviews 服務版本“v1”后端限制100個連接。
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 100
查看斷路器控制的斷路任務演示。
與路由規則類似，策略與特定host相關聯，但是如果它們配置了子集，則激活哪個取決于路由規則評估結果。
規則評估過程中的第一步評估與所請求的主機相對應的VirtualService中的路由規則（如果定義了），以確定當前請求將被路由到的目的地服務的subset （即，特定版本）。 接下來，評估與所選子集相對應的一組策略，以確定它們是否適用。
注意：要牢記算法的一個細微之處在于，只有在相應的子集被明確路由到時才會應用為特定子集定義的策略。 例如，考慮以下配置，作為為評論服務定義的唯一規則（即相應虛擬服務中沒有路由規則） 。
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 100
由于沒有為reviews 服務定義特定的路由規則，因此將應用默認的循環路由行為，有時可能會調用“v1”實例，如果“v1”是唯一正在運行的版本，甚至可能始終會調用“v1”實例。 不過，由于默認路由是在較低級別完成的，因此不會調用上述策略。 規則評估引擎將不知道最終目標，因此無法將子集策略與請求匹配。
你可以通過以下兩種方式之一修復上述示例。你可以將流量策略向上移動一個級別以適用于任何版本：
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: connectionPool: tcp: maxConnections: 100 subsets: - name: v1 labels: version: v1
或者更好的是，為服務定義合適的路由規則。 例如，您可以為“reviews:v1”添加簡單的路由規則。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1
雖然默認的Istio行為可以不設置任何規則就方便地將流量從任何源發送到目標服務的所有版本，但只要需要版本區分，就需要規則。 因此，最佳做法是從一開始就為每項服務設置默認規則。
ServiceEntry用于將其他條目添加到Istio內部維護的服務注冊表中。 它最常用于啟用Istio服務網格外服務的請求。 例如，以下ServiceEntry可用于允許對* .foo.com域名下托管的服務進行外部調用。
apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: foo-ext-svc spec: hosts: - *.foo.com ports: - number: 80 name: http protocol: HTTP - number: 443 name: https protocol: HTTPS
ServiceEntry的目標是使用hosts字段指定的，該字段可以是完全限定的域名或通配符域名。 它表示允許服務網格中的服務訪問的一個或多個服務的白名單中。
ServiceEntry不限于外部服務配置，它可以有兩種類型：網格內部或網格外部。 網格內部條目與所有其他內部服務一樣，但用于向網格顯式添加服務。 它們可用于添加服務，作為擴展服務網格以包含非托管基礎架構（例如，添加到基于Kubernetes的服務網格的VM）的一部分。 網格外部條目代表網格外部的服務。 對于他們來說，mTLS身份驗證被禁用，并且在客戶端執行策略實施，而不是在通常的服務器端執行內部服務請求。
只要服務條目使用匹配的hosts引用服務，服務條目就可以與虛擬服務和目標規則配合使用。 例如，可以將以下規則與上述ServiceEntry規則結合使用，以便在bar.foo.com上為外部服務的呼叫設置10秒超時。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bar-foo-ext-svc spec: hosts: - bar.foo.com http: - route: - destination: host: bar.foo.com timeout: 10s
規則重定向和轉發流量，定義重試，超時和故障注入策略都支持外部地址。 然而，加權（基于版本）路由是不可以的，因為沒有多個外部服務版本的概念。
查看出口任務 以獲取更多關于訪問外部服務的信息。
網關為HTTP/TCP流量配置負載均衡器，通常在服務網格的邊緣運行，以便為應用程序啟用入口流量。
與Kubernetes Ingress不同，Istio Gateway僅配置網絡中L4-L6層的功能（例如，要暴露的端口，TLS配置）。 然后，用戶可以使用標準的Istio規則來控制HTTP請求，以及通過綁定VirtualService來控制進入網關的TCP流量。
例如，以下網關配置負載均衡器，以允許主機bookinfo.com的外部https流量進入網格：
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: servers: - port: number: 443 name: https protocol: HTTPS hosts: - bookinfo.com tls: mode: SIMPLE serverCertificate: /tmp/tls.crt privateKey: /tmp/tls.key
要配置相應的路由，必須為同一個主機定義一個VirtualService，并使用配置中的gateways 字段綁定到網關：
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - bookinfo.com gateways: - bookinfo-gateway # <---- bind to gateway http: - match: - uri: prefix: /reviews route: ...
雖然主要用于管理入口流量，但也可以使用網關對純粹的內部或出口代理進行建模。無論內部或外部網絡，所有網關都可以用相同的方式進行配置和控制。
以上就是Istio流量管理的示例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
