服務網格大戰，再見 Istio! - Fossas

為什麼要使用服務網格？

• 它提供微服務之間的流量監控，包括服務通訊地圖和它們之間發生的 http 狀態程式碼。
• 新增服務網格使您能夠新增 mTLS，或者換句話說，您的服務之間的加密 http 流量。

使用服務網格難嗎？
是的。如果您使用任何服務網格，您將很難學到一樣東西：

1. 服務網格現在只可靠地支援 http 流量

我有使用 Istio 和 Linkerd 的經驗，它們都聲稱支援許多協議。我發現這是非常不可靠的。Istio 對某些資料庫協議的支援在版本之間中斷。Linkerd 正在破壞 ampq 流量和https，或者經常丟擲奇怪的錯誤。我的印象是編寫透明的網路代理非常困難。在這一點上，我只信任具有 http 流量的服務網格，無論如何這就是我想要的，因為這是我的 Kubernetes 服務之間的流量。

2. 您的應用程式容器的網路呼叫在sidecar 代理沒有執行時會失敗

這個特別糟糕，也是我認為服務網格還沒有為每個人準備好的主要原因。您的應用程式容器可能在 sidecar 代理之前啟動，在這種情況下，它將無法完成 sidecar 代理配置為處理的網路請求。

有一個 Kubernetes 補丁來製作本機 sidecar（您可以將 pod 中的容器標記為必須首先啟動的 sidecar）。它本應在 1.20 中釋出，但現在已被推遲，以支援儘可能多的用例。
無論如何，有一些技巧可以解決這個問題，但這意味著成功實現服務網格對開發人員不再透明，因為他們需要進行一些程式碼或部署修改。

3. init 容器和 cronjobs 不能使用服務網格
為什麼？服務網格代理容器永遠不會退出。如果它永遠不會退出，那麼 init 容器和 cronjobs 永遠不會真正“完成”。在前者中，您的應用程式容器永遠不會啟動，而在後者中，您的 cronjob 將超時並被標記為失敗。
據說有一些解決方法，但我從未發現任何非常實用的建議。
  

我是否真的使用了服務網格？
我已經成功地在兩個條件下成功地在生產和暫存叢集中使用它們。我只有 sidecar 代理監控 http 流量，並且我將 mTLS 設為可選（因為如果 pod 不在網格上，它仍然可以與網格上的另一個 pod 通訊）。
我不在評論叢集上使用服務網格。在服務網格中獲取審查應用程式存在太多問題。
  

為什麼我解除安裝了 Istio？
簡而言之，操作複雜。學習 Istio 的時間和我第一次學習 Kubernetes 的時間一樣長。
配置 helm chart 以部署 Istio 需要花費數週的時間才能做到恰到好處（相比之下，我幾乎總是在一天內配置一個新的 helm chart）。
Istio 對 CRD 很重。我儘量避免 CRD，因為它們會造成供應商鎖定。他們的 CRD，如基本的閘道器、VirtualService 和 DestinationRule 也需要一段時間來理解，而且我閱讀他們的文件的次數比我想承認的要多。

Istio 使用起來很可怕。這是一個巨大的單點故障。
可能我遇到的最糟糕的情況是，開發人員將包含閘道器 TLS 秘密的 Kubernetes secret 命名為錯誤。每個閘道器都壞了，基本上整個叢集都癱瘓了。這是一個錯誤，如果 Istio 找不到secret ，它將無法配置並停止為所有內容提供服務。而且除錯起來非常困難。日誌中沒有任何內容表明出了什麼問題。Istio 完全中斷的其他領域很少，通常與它將配置傳遞給 Envoy 代理的方式有關。他們稱之為“打破玻璃配置”。
最後，也是最重要的一點，Istio 棄用了 Helm 部署以支援其istioctl命令列實用程式……然後他們將 Helm 部署帶回了更高版本。我不喜歡使用一堆不同的方法在我的叢集上部署 40 多種支援工具，所以當他們棄用 Helm 時我非常失望，我使用的所有其他工具都支援它。當我發現這是暫時的時，我更加沮喪。這意味著我將不得不關閉它並重新使用它以升級到最新的 Istio。
 

我當初為什麼選擇 Istio？
Kubernetes 剛出現時，還有其他 3 個主要競爭對手：Mesos、Nomad 和 Swarm。Kubernetes 將贏得這場戰爭，這一點相對較快變得顯而易見。
我從未見過任何使用 Mesos 的人，這可能是沒有得到大公司支援的不幸結果，儘管我聽說它們對容器編排產生了巨大影響。
我見過的唯一使用 Swarm 的人使用它，因為它比 Kubernetes 更“簡單”。我知道這不會持續下去。它的“簡單”實際上是缺乏功能。如果您只使用 Kubernetes 的一小部分功能，那麼 Kubernetes 也同樣簡單。
Nomad 今天實際上還很活躍，如果您需要將流程直接編排到伺服器上，那麼這就是您的選擇。如果您只需要容器編排，我強烈推薦 Kubernetes。
不管怎樣，當 Istio 出來時，情況看起來很熟悉。唯一的競爭對手是 Linkerd（我想我認為它與我心目中的 Swarm 型別的競爭對手有關），而 Istio 就像 Kubernetes 一樣是 Google 的寶貝。所以，我選擇了 Istio。
然後服務網格大戰開始了。首先是 AWS 的 AppMesh，然後是 Traefik 的 Maesh，然後是 Azure 的開放服務網格（可能被命名為 Istio 沒有加入 CNCF 的爭議）和 Nginx 的服務網格。還有其他幾個，大多數使用 Envoy 代理來建立他們的服務網格，例如 Kuma 和 Consul Connect。
看起來根本沒有明顯的贏家。
 

我現在用什麼？
在比較了所有的服務網格之後，我最終選擇了最初的 Linkerd。其他人似乎要麼試圖避免供應商鎖定，要麼只是沒有按照我想要的方式工作（比如 Maesh，它向節點而不是 pod 新增了代理）。
我喜歡 Linkerd 的地方：

• 它支援使用 Helm 進行部署（實際上，我在所有部署中都使用了 Helm 的修改版本，並且我使用了一些自定義程式碼來避免外部手動配置）。
• 這相當簡單。只有一個您真正需要的 CRD，而且舵圖很容易學習。
• 他們的儀表板很光滑。Istio 使用 Grafana/Promethus 和 Kiali。Linkerd 也有 Grafana/Prometheus，但它也有一個易於使用的專用自定義儀表板。
• 他們用 Rust（在 v2 中）編寫了自己的代理。一開始我很糾結，因為 Envoy 很受歡迎，但後來我意識到 Linkerd 可以快速移動。Envoy 現在是一個巨大的野獸，必須對許多供應商保持中立，但 Linkerd 可以對自己的代理做任何他們想做的事情，從而使開發速度更快。另外，它是用 Rust 編寫的！這很酷，對吧？
• 他們組成了CNCF聯盟。Istio 沒有加入……
• Linkerd 首先做對了。Istio 試圖擁有一堆您必須管理的不同部署，現在已轉移到單個部署。Linkerd 是首先這樣做的。他們確實有其他部署，但不是“核心”。它們新增了功能，因此您只需擔心服務網格正常工作的一項關鍵部署。 

我不喜歡 Linkerd 的什麼地方？
真的只是一件小事。我想這更像是一種營銷方式。他們聲稱是一個服務網格，您可以在 5 分鐘內安裝和使用，隨時可用。但是正如您從我上面寫的所有內容中看到的那樣，服務網格並沒有簡單地準備好。Linkerd 與每個服務網格都存在相同的問題，即缺乏本機 sidecar 和不可靠的非 http 協議處理。
 

總結
可能有一天，你使用哪種服務網格會成為一個小問題，因為很多人甚至不知道他們在 Kubernetes 中使用的是什麼服務網格。每個服務網格都採用 SMI（服務網格介面），因此從長遠來看，我認為服務網格將成為 Kubernetes 中的原生資源，採用開放標準是朝這個方向邁出的第一步。
Istio 沒有加入 CNCF，儘管 Chris DiBona 在 KubernetesPodcast 上做出瞭解釋，但我仍然不是這一舉動的忠實粉絲。
Linkerd 在 CNCF 中。如果他們保持簡單，我不打算很快離開他們。
一旦 Kubernetes 推出某種原生 sidecar 解決方案，我會很高興。