云原生入門級開發者認證學習筆記之服務網格之lstio技術

寫在前面

嗯，報了考試，整理課堂筆記記憶

學習的原因：

雖然考了CKA,了解了一些K8s相關的知識

但是對云原生整個體系一直都很模糊

希望對云原生有一個基本的認識

通過學習實現云原生相關入門

博文主要內容涉及：

服務網格概念

Istio初識

Istio流量規則配置簡介

istio常用的流量治理策略

流量監控介紹

理解不足小伙伴幫忙指正

傍晚時分，你坐在屋檐下，看著天慢慢地黑下去，心里寂寞而凄涼，感到自己的生命被剝奪了。當時我是個年輕人，但我害怕這樣生活下去，衰老下去。在我看來，這是比死亡更可怕的事。--------王小波

服務網格概念

Service Mesh是承載微服務架構理念的云原生技術形態

微服務源自服務化架構設計理念，與敏捷開發DevOps理念的結合：微—>小、快、獨

經過技術演進，隨著云計算發展到云原生階段，服務網格（service Mesh）則成為承載微服務理念的新一代技術形態。

Serverless將進一步釋放云計算的能力，將安全、可靠、可伸縮等需求交由基礎設施實現，使用戶僅需關注業務邏輯而無需關注具體部署和運行，極大地提高應用開發效率。同時這個方式促進了社會分工協作，云廠商可以進一步通過規模化、集約化實現計算成本大幅優化。

微服務技術演進：

優點：簡單使用依賴少

限制：代碼耦合,代碼重復高,運維復雜,開發要求高

優點：代碼重復少,治理邏輯代碼和業務代碼分開

限制：SDK語言綁定,代碼侵入,基于SDK開發學習門檻高,在用系統改造代價大,治理能力升級影響用戶業務

服務治理還是和自身業務跑在一塊，沒有做完全的解耦。當sdk需要升級的時候，但有些服務很久沒有編譯過了，是一個老代碼，sdk版本也老，要去編譯重新溯源，更新sdk邏輯的話比較困難。

隨著服務框架內功能的日益增多，復用不同編程語言開發的基礎功能就顯得十分困難，這也意味著微服務的開發人員將被迫綁定在某種特定語言之上，從而違背了微服務的敏捷迭代原則。(springcloud 相關組件)

服務治理能力歸一到服務網格

優點：獨立進程，用戶業務非侵入，語言無關，治理邏輯升級業務無感知。已有系統無需改造即可治理，可以漸進的微服務化限制，代理的性能和資源開銷

限制：代理的性能和資源開銷

Service Mesh（服務網格）是什么

Service Mesh又譯作服務網格，作為服務間通信的基礎設施層。Buoyant公司的CEO Willian Morgan在他的這篇文章 WHAT'S A Service Mesh？AND WHY DOI NEED ONE？中解釋了什么是Service Mesh，為什么云原生應用需要Service Mesh

服務網格（Service Mesh）是致力于解決服務間通訊的基礎設施層。它負責在現代云原生應用程序的復雜服務拓撲來可靠地傳遞請求。實際上，Service Mesh通常是通過一組輕量級網絡代理（Sidecar proxy），與應用程序代碼部署在一起來實現，但對應用程序透明。

服務網格作為單獨層的概念與云原生應用程序的興起息息相關。在云原生模型中，單個應用程序可能包含數百個服務；每個服務可能有數千個實例；并且這些實例中的每一個都可能處于不斷變化的狀態，因為它們是由像Kubernetes這樣的編排器動態調度的。這個世界中的服務通信非常復雜,管理網絡對于確保端到端的性能和可靠性至關重要。

服務網格是一種網絡模型，位于TCP/IP之上的抽象層。它假定底層L3/L4網絡存在并且能夠從點到點傳送字節。服務網格的明確目標是將服務通信從不可見的、隱含的基礎設施領域轉移到 生態系統的一流成員 的角色中——可以對其進行監視、管理和控制。

好奇服務網格是不是可以理解為 K8s 中 NetWorkProlicy資源對象的集合？

服務網格的特點

Service Mesh有如下幾個特點：

應用程序間通訊的中間層口

輕量級網絡代理

應用程序無感知

解耦應用程序的重試/超時、監控、追蹤和服務發現

Service Mesh明星項目

什么是可用的service mesh呢？現在比較知名的項目有：

Istio ：由Lyft、IBM與google聯合開發，Istio可以在不修改微服務源代碼的情況下，輕松為其加上如負載均衡、身份驗證等功能，它可以通過控制Envoy等代理服務來控制所有的流量。此外，Istio提供容錯、金絲雀部署、A/B測試、監控等功能，并且支持自定義的組件和集成。 Preview2版本上開始支持lstio，用戶可以直接在UI界面中啟動Istio并且可以為每個命名空間注入自動sidecar。Rancher內置了一個支持Kiali的儀表盤，簡化lstio的安裝和配置。這一切讓部署和管理Istio變得簡單而快速。

Linkerd ：2016年發布，是這些項目中最老的。Linkerd是從Twitter開發的library中分離出來的。在這一領域另一位重量型選手，Conduit，已經進入了Linkerd項目并構成了Linkerd 2.0的基礎。

Envoy ：由Lyft創建，為了能夠提供完整的service mesh功能，Envoy占據“數據平面”的部分，與其進行匹配。

HashiCorp Consul ：與Consul 1.2一起推出了一項名為Connect的功能，為HashiCorp的分布式系統添加了服務加密和基于身份的授權，可用于服務發現和配置。

服務網格與微服務框架流量治理對比

微服務框架是基于SDK來實現的一些服務治理，需要將微服務框架的SDK嵌入到業務代碼中去，從而造成侵入式開發，因此需要開發人員掌握微服務框架。而服務網格由sidecar注入的，就不需要修改業務代碼。

Istio初識

Istio 項目發展歷程：多個頭部云廠商參與，已經商業Ready

在Google、IBM、RedHat等開源巨頭成熟的項目運作與社區治理機制下快速發展：

Istio作為第二代Service Mesh技術，通過基于K8s標準擴展的控制面帶來了前所未有的靈活性及擴展能力，影響力遠超更早出現的Linkerd。

Istio背負巨大的使命，Google希望在繼Kubernetes成為容器編排的事實標準之后，打造另一殺手锏級別的技術，成為服務網格的事實標準·

Google與IBM大廠的加持，在資源及影響力層面遠非Buoyant可比擬的。

眾多廠商參與I5tio社區，共同推進繁榮。

從企業級可用的1.1版本之后，社區每隔3個月發布一個大版本。

成立Steering Commitee，社區的運作、治理更加透明。

Istio已日趨成為服務網格標準

Istio是一個提供連接、保護、控制以及觀測功能的開放平臺，通過提供完整的非侵入式的微服務治理解決方案，能夠很好的解決云原生服務的管理、網絡連接以及安全管理等服務網絡治理問題。

連接：智能控制服務之間的流量和APl調用，進行一系列測試，并通過藍綠部署逐步升級。

保護：通過托管身份驗證、授權和服務之間通信加密自動保護服務。

控制：應用策略并確保其執行，使得資源在消費者之間公平分配。

觀測：對服務進行多樣化、自動化的追蹤、監控以及日志記錄。

對于云原生應用，采用Kubernetes構建微服務部署和集群管理能力，采用Istio構建服務治理能力，將逐漸成為應用微服務轉型的標準配置。

Kubernetes在容器編排領域已經成為無可爭辯的事實標準；微服務化的服務與容器在輕量、敏捷、快速部署運維等特征上匹配，這類服務在容器中的運行也正日益流行；

隨著Istio的成熟和服務網格技術的流行，使用Istio 進行服務治理的實踐也越來越多，正成為服務治理的趨勢；而Istio與Kubernetes的天然融合且基于Kubernetes構建，也補齊了Kubernetes的治理能力，提供了端到端的服務運行治理治理平臺。這都使得Istio、微服務、容器及Kubernetes形成一個完美的閉環。云原生應用采用Kubernetes構建應用編排能力，采用Istio構建服務治理能力，將逐漸成為企業技術轉型的標準配置。

Istio整體架構

Istio采用service mesh（服務網格）設計，邏輯上分為數據平面和控制平面。

數據平面以sidecar方式配置代理（基于envoy實現）來管理數據通信。

控制平面負責管理和配置來控制數據平面和控制平面本身組件。

Istio 的控制平面本身就是一個現代的云原生應用程序。因此，它從一開始就是作為一組微服務構建的。

Pilot基本架構

概念：Pilot將各類平臺的特異性服務發現機制抽象化并合成為符合istio sidecar的標準格式，用來提供服務發現，流量管理功能。

Pilot在方框圖中，主要包含三個部分：平臺適配層，xds生成器以及xds服務器。

原生支持Kubernetes，List-Watch Service、Endpoint，Pod，Node，etc XDS服務器向下對所有的數據面Sidecar提供,XDS配置中間內核層負責生成xDS配置，每一種xDS對應有一種生成器，XDS Generator可以實現lstio Al與Envoy API之間的轉換。

Pilot是Istio進行流量治理的核心組件，其架構與Istio的設計理念是一致的。Pilot支持從Kubernetes、Consul等多種平臺獲取服務發現功能。

Citadel基本架構

概念：通過內置身份和憑證管理來實現服務間和最終用戶的身份驗證。

支持的安全功能：流量加密、身份認證、授權鑒權

我們在istio中，service與service的數據，默認是經過mtls加密之后再兩邊的envoy之間進行通訊，這樣的好處是在零信任網絡下打造微服務網絡的安全，這個是非常重要的。

交互拆分：

Citadel是服務網格的安全組件與NodeAgent一起為工作負載提供證書的簽發、輪換。

Citadel處理來自NodeAgent的CSR請求Citadel內部簽發證書主要有兩種形式：

本身作為證書簽發機構（CA）自己簽發

作為RA代理證書簽名請求（CSR）請求

Galley基本架構

Galley負責配置管理相關的工作：

Admission Webhook提供配置校驗

MCP Sink提供配置的攝取

Galley負責配置校驗以及配置攝取，創建Istio api的時候，k8s server會將請求發送給galley，galley會對istio api進行校驗，從而判斷是否允許創建。

Istio 應用場景

灰度發布：版本升級平滑過渡的一種方式，金絲雀發布、藍綠發布等；

流量治理：負載均衡、連接池管理、熔斷、故障注入等；

訪問可視化：監控數據采集、運行指標分析、應用拓撲和調用鏈展示等；

業務場景：電商應用、政企業務、視頻業務等。

藍綠發布提供了一種零宕機的部署方式。不停老版本，部署新版本進行測試，確認OK，將流量切到新版本，然后老版本同時也升級到新版本。始終有兩個版本同時在線，有問題可以快速切換。

在部署應用的過程中，應用始終在線。并且新版本上線過程中，不會修改老版本的任何內容，在部署期間老版本狀態不受影響·只要老版本的資源不被刪除，可以在任何時間回滾到老版本。

·

金絲雀發布也叫灰度發布

在生產環境上引一部分實際流量對一個新版本進行測試，測試新版本的性能和表現，在保證系統整體穩定運行的前提下，盡早發現新版本在實際環境上的問題。

通過在線上運行的服務中，新加入少量的新版本的服務，然后從這少量的新版本中快速獲得反饋，根據反饋決定最后的交付形態。

基于權重的灰度發布: 可根據需要靈活動態的調整不同服務版本的流量比例

基于內容的灰度發布:可根據請求的內容控制其流向的服務版本（Cookie，Header，OS，Browser）

Istio流量規則配置簡介

Istio 流量管理資源配置初識

VirtualService 在 Istio 服務網格中定義路由規則，控制流量路由到服務上的各種行為。

DestinationRule 是 VirtualService 路由生效后，配置應用與請求的策略集。

Gateway 為 HTTP/TCP 流量配置負載均衡器，最常見的是在網格邊緣的操作，以啟用應用程序的入口流量。

為了在網格中導流，Istio 需要知道所有的 endpoint 在哪和屬于哪個服務。為了定位到service registry(服務注冊中心)，Istio 會連接到一個服務發現系統。例如，如果在Kubernetes 集群上安裝了 Istio，那么它將自動檢測該集群中的服務和 endpoint。

Gateway概述

Gateway為HTTP/TCP流量配置了一個負載均衡，用于啟用一個服務的入口流量。和Kubernetes Ingress不同，Istio Gateway只配置四層到六層的功能（例如開放端口或者TLS配置）。綁定一個VirtualService到Gateway上，用戶就可以使用標準的Istio規則來控制進入的HTTP和TCP流量。

L7層的路由能力需要與VirtualService綁定。(路由規則匹配)

Gateway描述了一個在網格邊緣運行的負載均衡器，接收傳入或傳出的HTTP/TCP連接。該規范描述了一組應該暴露的端口、要使用的協議類型、負載均衡器的SNI配置等。

VirtualService概述

VirtualService（VS）：虛擬服務是lstio重要的資源對象之一。能夠將流量路由到網格中的服務。支持基于權重、http header條件等優先級的路由，比Kuberentes service對于流量的管控更加的豐富，顆粒度更加精細。

VirtualService主要配置流量路由。VirtualService定義了一套當主機被尋址時應用的流量路由規則。每個路由規則定義了特定協議流量的匹配標準。如果流量被匹配，那么它將被發送到注冊表中定義的指定目標服務（或它的子集/版本）。(類于Ingress的路由匹配)

DestinationRule概述

常常與VS（VirtualService）配合使用，VS定義一些策略將流量路由到某些目標服務，而DestinationRule允許用戶針對目標服務配置一些負載均衡，異常檢測，連接池以及證書。

DestinationRule還定義了對應目標主機的可路由subset。VirtualService在向特定服務版本發送請求時會用到這些子集。

DestinationRule定義了在路由發生后適用于服務流量的策略。這些規則指定了負載均衡的配置、來自sidecar的連接池大小，以及用于檢測和驅逐負載均衡池中不健康主機的離群檢測設置。

Istio常用的流量治理策略

流量治理策略：

支持的負載均衡算法：

加權輪詢

最少請求

環形Hash

隨機

優先級負載均衡

Locality加權

負載均衡建立在現有網絡結構之上，它提供了一種有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。

默認情況下，lstio使用輪詢的負載均衡策略，實例池中的每個實例依次獲取請求。lstio同時支持如下的負載均衡模型，可以在DestinationRule中為流向某個特定服務或服務子集的流量指定這些模型。

熔斷，是創建彈性微服務應用程序的重要模式。熔斷能夠使應用程序具備應對來自故障、潛在峰值和其他未知網絡因素影響的能力。

故障注入可以用來識別系統最薄弱的環節，支持的類型：

HTTP請求響應延時注入

HTTP、gRPC錯誤碼注入

在配置了網絡，包括故障恢復策略之后，可以使用Istio的故障注入機制來為整個應用程序測試故障恢復能力。

故障注入是一種將錯誤引入系統以確保系統能夠承受并從錯誤條件中恢復的測試方法。使用故障注入特別有用，能確保故障恢復策略不至于不兼容或者太嚴格，這會導致關鍵服務不可用。

可以注入兩種故障，它們都使用VirtualService配置：

Delay：延遲是時間故障。它們模擬增加的網絡延遲或一個超載的上游服務。

Abort：終止是崩潰失敗。他們模仿上游服務的失敗。終止通常以HTTP錯誤碼或TCP連接失敗的形式出現。

Istio支持兩種限流方式：

1.中心集中式限流

2.本地限流

Istio支持失敗重試HTTPRetry，提高系統的Resilience。

重試設置指定如果初始調用失敗，Envoy代理嘗試連接服務的最大次數。

通過確保調用不會因為臨時過載的服務或網絡等問題而永久失敗，重試可以提高服務可用性和應用程序的性能。重試之間的間隔（25ms+）是可變的，并由lstio自動確定，從而防止被調用服務被請求淹沒。HTTP請求的默認重試行為是在返回錯誤之前重試兩次。

流量監控介紹

服務網格監控-Observability

Istio以非侵入的方式提供了以下遙測類型:

Metrics：應用流量粒度的監控統計,Istio根據監控的四個“黃金信號”（延遲、流量、錯誤和飽和度）生成一組服務指標。Istio 還提供了網格控制平面的詳細指標。還提供了基于這些指標構建的一組默認網格監控儀表板。

Distributed Traces：分布式追蹤,Istio為每個服務生成分布式跟蹤跨度，使操作員能夠詳細了解網格內的調用流和服務依賴關系。

分布式追蹤可以讓用戶對跨多個分布式服務網格的 1 個請求進行追蹤分析。這樣進而可以通過可視化的方式更加深入地了解請求的延遲，序列化和并行度。

Access Logs：訪問日志,當流量流入網格內的服務時，Istio可以生成每個請求的完整記錄，包括源和目標元數據。此信息使操作員能夠審核服務行為，直至單個工作負載實例級別。

Istio最簡單的日志類型是Envoy的訪問日志。Envoy代理打印訪問信息到標準輸出。Envoy容器的標準輸出能夠通過kubectl logs命令打印出來。

Istio Kubernetes 云原生 開發者

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。