這篇文章主要為大家展示了“kubernetes中什么是Service Mesh”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“kubernetes中什么是Service Mesh”這篇文章吧。
一:什么是Service Mesh
1.可以將Service Mesh比作是程序或者微服務間的TCP/IP,負責服務之間的網絡調用,限流,熔斷和監控。對于編寫應用程序來說一般無須關心 TCP/IP 這一層(比如通過 HTTP 協議的 RESTful 應用),同樣使用 Service Mesh 也就無須關系服務之間的那些原來是通過應用程序或者其他框架實現的事情,比如 Spring Cloud、OSS,現在只要交給 Service Mesh 就可以了。
2.Service Mesh有如下幾個特點:
a. 應用程序間通信的中間層
b.輕量級的網絡代理
c.應用程序無感知
d.解耦應用程序的重試,超時,監控,追蹤和服務發現
3.Service Mesh的架構
Service mesh 作為 sidecar 運行,對應用程序來說是透明,所有應用程序間的流量都會通過它,所以對應用程序流量的控制都可以在 serivce mesh 中實現。
二:為何使用Service Mesh
1.Service mesh 并沒有給我們帶來新功能,它是用于解決其他工具已經解決過的問題,只不過這次是在 Cloud Native 的 kubernetes 環境下的實現。
2.在傳統的 MVC 三層 Web 應用程序架構下,服務之間的通訊并不復雜,在應用程序內部自己管理即可,但是在現今的復雜的大型網站情況下,單體應用被分解為眾多的微服務,服務之間的依賴和通訊十分復雜。
3.在 Cloud Native 架構下,容器的使用給予了異構應用程序的更多可行性,kubernetes 增強的應用的橫向擴容能力,用戶可以快速的編排出復雜環境、復雜依賴關系的應用程序,同時開發者又無須過分關心應用程序的監控、擴展性、服務發現和分布式追蹤這些繁瑣的事情而專注于程序開發,賦予開發者更多的創造性。
三:Service Mesh如何工作
Linkerd 為例講解 service mesh 如何工作:
1.Linkerd 將服務請求路由到目的地址,根據其中的參數判斷是到生產環境還是測試環境,是路由到本地環境還是公有云環境?所有的這些路由信息可以動態配置,可以是全局配置也可以為某些服務單獨配置。
2.當 Linkerd 確認了目的地址后,將流量發送到相應服務發現端點(在 kubernetes 中是 service),然后 service 會將服務轉發給后端的實例(Pod)。
3.Linkerd 根據它觀測到最近請求的延遲時間,選擇出所有應用程序的實例中響應最快的實例。
4.Linkerd 將請求發送給該實例,同時記錄響應類型和延遲數據。
5.如果該實例掛了、不響應了或者進程不工作了,Linkerd 將把請求發送到其他實例上重試。
6.如果該實例持續返回 error,Linkerd 會將該實例從負載均衡池中移除,稍后再周期性得重試。
7.如果請求的截止時間已過,Linkerd 主動失敗該請求,而不是再次嘗試添加負載。
8.Linkerd 以 metric 和分布式追蹤的形式捕獲上述行為的各個方面,這些追蹤信息將發送到集中 metric 系統。
四:Istio 與 Linkerd
當前的Service Mesh實現主要有兩大陣營,Linkerd和Istio。
<table letter-spacing:0.2px;background-color:#FFFFFF;">
Feature | Istio | Linkerd |
---|---|---|
部署架構 | Envoy/Sidecar | DaemonSets |
易用性 | 復雜 | 簡單 |
支持平臺 | kuberentes | kubernetes/mesos/Istio/local |
當前版本 | 0.3.0 | 1.3.3 |
是否已有生產部署 | 否 | 是 |
下圖是Istio和Linkerd架構的不同,Istio是使用Sidecar模式,將Envoy植入到Pod中,而Linkerd則是在每臺node上都以DaemonSet的方式運行。
以上是“kubernetes中什么是Service Mesh”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。