服務網格仍然很難 - cncf

1.缺乏關於是否需要服務網格的明確指導

在使用者開始評估多個服務網格或深入研究特定的服務網格之前，他們需要有關服務網格是否可以提供幫助的指導。不幸的是，這不是一個簡單的是/否問題。有多個因素需要考慮：

• 您的工程組織中有多少人？
• 您有多少個微服務？
• 這些微服務使用什麼語言？
• 您是否有采用開源專案的經驗？
• 您在什麼平臺上執行服務？
• 服務網格需要什麼功能？
• 對於給定的服務網格專案，功能是否穩定？

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之內。

• 源容器到源Sidecar代理
• 源Sidecar代理到目標Sidecar代理
• 目標Sidecar代理到目標容器