服務網格仍然很難 - cncf

banq發表於2020-11-08

服務網格比一兩年前更加成熟,但是,對於使用者來說仍然很難。服務網格有兩種技術角色,平臺所有者和服務所有者。平臺所有者(也稱為網格管理員)擁有服務平臺,並定義了服務所有者採用服務網格的總體策略和實現。服務所有者在網格中擁有一項或多項服務。
對於平臺所有者而言,使用服務網格變得更加容易,因為專案正在實施簡化網路配置,安全策略配置以及整個網格視覺化的方法。例如,在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)的部落格很好地描述這些問題,解釋了複雜性,三者中的任何一個可能出問題以及如何修復這些問題。

 

相關文章