服務網格仍然很難 - cncf
服務網格比一兩年前更加成熟,但是,對於使用者來說仍然很難。服務網格有兩種技術角色,平臺所有者和服務所有者。平臺所有者(也稱為網格管理員)擁有服務平臺,並定義了服務所有者採用服務網格的總體策略和實現。服務所有者在網格中擁有一項或多項服務。
對於平臺所有者而言,使用服務網格變得更加容易,因為專案正在實施簡化網路配置,安全策略配置以及整個網格視覺化的方法。例如,在Istio中,平臺所有者可以在他們喜歡的任何範圍內設定Istio身份驗證策略或授權策略。平臺所有者可以在主機/埠/ TLS相關設定上配置入口閘道器,同時將目標服務的實際路由行為和流量策略委託給服務所有者。實施經過良好測試和常見方案的服務所有者可以從Istio的可用性改進中受益,從而輕鬆地將其微服務載入到網格中。
而服務所有者卻遇到陡峭的學習曲線。
我認為服務網格仍然很困難,原因如下:
1.缺乏關於是否需要服務網格的明確指導
在使用者開始評估多個服務網格或深入研究特定的服務網格之前,他們需要有關服務網格是否可以提供幫助的指導。不幸的是,這不是一個簡單的是/否問題。有多個因素需要考慮:
- 您的工程組織中有多少人?
- 您有多少個微服務?
- 這些微服務使用什麼語言?
- 您是否有采用開源專案的經驗?
- 您在什麼平臺上執行服務?
- 服務網格需要什麼功能?
- 對於給定的服務網格專案,功能是否穩定?
對於各種服務網格專案,答案變得不同,這增加了複雜性。即使在Istio內部,我們也採用微服務來充分利用Istio 1.5之前的早期版本中的網格,但是決定將多個Istio控制平面元件轉變為整體應用程式以降低運維複雜性。例如,執行一個整體服務而不是四個或五個微服務更為有意義。
2.注入邊車後,您的服務可能會立即中斷
上一個感恩節,我試圖使用最新的Zookeeper舵圖幫助使用者在網格中執行Zookeeper服務。Zookeeper作為Kubernetes StatefulSet執行。一旦我嘗試將特使邊車代理注入每個Zookeeper pod,Zookeeperpod將無法執行並繼續重新啟動,因為它們無法建立領導者並在成員之間進行交流。
預設情況下,Zookeeper監聽Pod IP地址以進行伺服器之間的通訊。但是,Istio和其他服務網格要求將本地主機(127.0.0.1)作為偵聽的地址,這使Zookeeper伺服器無法相互通訊。
與上游社群合作,我們為Zookeeper,Casssandra,Elasticsearch,Redis和Apache NiFi新增了配置解決方法。我確信還有其他與邊車不相容的應用程式。
3.您的服務在啟動或停止時可能會有異常行為
Kubernetes缺乏宣告容器依賴關係的標準方法。有一個Sidecar Kubernetes增強建議(KEP),但是Kubernetes版本中尚未實現,並且要花一些時間才能穩定該功能。同時,服務所有者可能會在啟動或停止時觀察到意外行為。
為了幫助解決此問題,Istio為平臺所有者實施了全域性配置選項,以將應用程式啟動延遲到Sidecar準備就緒為止。Istio很快將允許服務所有者在pod級別進行配置。
4.可以為您的服務進行零配置,但不能零程式碼更改
服務網格專案的主要目標之一是為服務所有者提供零配置。像Istio這樣的一些專案已經新增了智慧協議檢測功能,以幫助檢測協議並簡化網格的入門體驗,但是,我們仍然建議使用者在生產中明確宣告協議。透過在Kubernetes中新增appProtocol設定,服務所有者現在可以使用標準方法為在較新的Kubernetes版本(例如1.19)中執行的Kubernetes服務配置應用程式協議。
為了充分利用服務網格的功能,不幸的是不可能零程式碼更改。
- 為了使服務所有者和平臺所有者正確觀察服務跟蹤,在服務之間傳播跟蹤標頭至關重要。
- 為避免混淆和意外行為,至關重要的是重新檢查服務程式碼中的重試和超時,以檢視是否應進行調整並瞭解其行為與與sidecar代理配置的重試和超時的關係。
- 為了讓Sidecar代理檢查從應用程式容器傳送的流量並智慧地利用內容來做出決策,例如基於請求的路由或基於標頭的授權,對於服務所有者而言,確保從源服務傳送純流量至關重要目標服務並信任sidecar代理安全地升級連線。
5.服務所有者需要了解客戶端和服務端配置的細微差別
在使用服務網格之前,我不知道有太多與超時和從Envoy代理重試有關的配置。大多數使用者都熟悉請求超時,空閒超時和重試次數,但是存在許多細微差別和複雜性:
- 當涉及到空閒超時時,HTTP協議下有一個 idle_timeout,它適用於HTTP連線管理器和上游群集HTTP連線。有一個stream_idle_timeout一個流與存在沒有上游或下游活性甚至路線idle_timeout可重寫stream_idle_timeout。
- 自動重試也很複雜。重試不僅是重試次數,而且是允許的最大重試次數,這可能不是實際的重試次數。重試的實際次數取決於重試條件,路由請求超時s和重試之間的間隔,這些間隔必須落在總體請求超時和重試預算s之內。
在非服務網格世界中,源容器和目標容器之間只有1個連線池,但是在服務網格世界中,有3個連線池:
- 源容器到源Sidecar代理
- 源Sidecar代理到目標Sidecar代理
- 目標Sidecar代理到目標容器
這些連線池中的每一個都有其自己的單獨配置。卡爾·斯通尼(Karl Stoney)的部落格很好地描述這些問題,解釋了複雜性,三者中的任何一個可能出問題以及如何修復這些問題。
相關文章
- 頂級三種服務網格比較 - cncf
- 重磅 | 騰訊雲服務網格開源專案 Aeraki Mesh 加入 CNCF 雲原生全景圖
- Aeraki Mesh正式成為CNCF沙箱專案,騰訊雲攜夥伴加速服務網格成熟商用
- 服務網格 Service Mesh
- 服務網格(Envoy+Istio)
- 微服務是否真的需要服務網格?微服務
- 服務網格重蹈ESB的覆轍?為什麼需要SMI服務網格介面? - samnewman
- 服務網格:微服務進入2.0時代微服務
- Istio 1.2服務網格釋出
- 避免使用服務網格的原因? - Reddit
- 服務網格service mesh 之 Linkerd
- ServiceMesh:服務網格有哪些應用?
- 分散式微服務為什麼很難?分散式微服務
- 服務網格定義企業上雲新路徑! | Forrester X 螞蟻集團 釋出服務網格白皮書REST
- 服務網格將更安全:VMware收購Mesh7改變服務網格的遊戲規則遊戲
- 企業服務匯流排ESB已死! 服務網格上位
- SerCe的部落格:您不需要任何服務網格
- 服務網格大戰,再見 Istio! - Fossas
- 使用Istio服務網格實現流量映象
- 服務網格istio概念應知應會
- 談談我對服務網格的理解
- 服務網格|如何使用 Amesh 配置外掛
- 服務網格新成員:亞馬遜釋出App Mesh應用網格亞馬遜APP
- 建立微服務很容易,但是有幾點很難 - James Hickey微服務
- Envoy服務網格如何減輕級聯故障?
- 為什麼要使用服務網格Service Mesh?
- 服務網格 ASM 8 月產品動態ASM
- 看看服務網格可以做的所有事情
- 愛奇藝在服務網格方向的落地實踐
- 初識 Istio - 服務網格管理工具
- 蘋果網際網路服務轉型艱難:去年新推服務幾無收入蘋果
- Java後端分散式系統的服務路由:智慧DNS與服務網格Java後端分散式路由DNS
- 部落格的服務端服務端
- 服務網格的存在意義 -kelseyhightower
- hystrix對比服務網格istio的destinationrule
- Dapr 不是服務網格,只是我長的和他很像
- 服務網格GCP (GKE, Istio, MSA) 搖滾組合GC
- 服務網格大事:Istio釋出1.0版本