使用兩年之後,我爲什麼卸載了 Istio?

作者 | Eric Fossas

譯者 | 劉雅夢

策劃 | Tina

在生產中使用了 Istio 近兩年之後,我們要和它說再見了。

服務網絡大戰正在肆虐。現在我把票投給了 Linkerd。

服務網格提供了微服務之間的流量監控,包括服務通信的映射和在它們之間生成的 HTTP 狀態碼。通過添加服務網格,你可以在服務間添加 mTLS,或者換句話說,可以在服務間添加加密的 HTTP 通信。

在我看來,這兩個工具幾乎對所有人都很有用。許多服務網格都提供了諸如流量分割、重試、超時等高級功能。我很少相信這些功能是有用的,或者我認爲這不應該是由 Sidecar 代理來處理的功能。它們經常被錯誤地用來嘗試解決一個本該以其他方式解決的問題。

但另一方面服務網格很難。如果你要使用任何一種服務網格,都需要一個艱苦的過程才能學到一些知識:

我有使用 Istio 和 Linkerd 的經驗,它們都聲稱支持許多協議。我發現這很不可靠。Istio 對某些數據庫協議的支持在不同版本之間存在中斷。Linkerd 中斷了 ampq 通信。在這兩個平臺上使用 HTTPS 經常會拋出一些奇怪的錯誤。我的印象是,編寫一個透明的網絡代理是極其困難的。在這一點上,我只相信一個帶有 HTTP 通信的服務網格,無論如何,這是我想要的,因爲那是 Kubernetes 服務之間通信的流量。

這一點尤爲糟糕,這也是我認爲服務網格尚不適用於所有人的主要原因。應用程序容器可能會在 Sidecar 代理之前啓動,在這種情況下,它將無法完成需要由 Sidecar 代理來配置處理的網絡請求。

可以借用 Kubernetes 的故事來製作 Sidecar(你可以標記 Pod 中某個容器中爲自旋向上的 Sidecar)。它原本計劃在 1.20 版本中發佈,但現在爲了支持儘可能多的用例而推遲了。

無論如何,總有一些技巧可以解決這個問題,但這意味着成功實現一個服務網格對開發人員來說不再是透明的,因爲他們需要修改一些代碼或部署。

爲什麼呢?服務網格代理容器永遠不會退出。如果它永不退出,那麼初始化容器和 CronJob 就永遠不會真正 “完成”。對容器來說,你的應用程序容器將永遠不會啓動,對 CronJob 來說,你的 CronJob 將超時並被標記爲失敗。

可能有一些解決方法,但我從未發現有任何建議是非常實用的。

我已經成功地在生產和預發集羣中使用了服務網格,但有兩個限制條件,只讓 Sidecar 代理監控 HTTP 通信;將 mTLS 設置爲可選(如果某個 Pod 不在網格上,它仍然可以與網格上的另一個 Pod 通信)。

我不在審查集羣上使用服務網格。把審查應用程序放到服務網格中有太多的問題需要解決了。

1 爲什麼我卸載了 Istio?

簡而言之,因爲操作複雜。學習 Istio 的時間與我第一次學習 Kubernetes 的時候差不多長。

通過配 Helm 來部署 Istio 需要花費數週的時間(相比之下,我幾乎總能在一天之內完成一個新 Helm 的配置)。

Istio 重度依賴 CRD。我儘量避免使用 CRD,因爲它們會造成供應商鎖定。他們的 CRD,比如,必不可少的 Gateway、VirtualService、DestinationRule 都要花費一些時間來理解,而且我閱讀它們文檔的次數比我能接受的要多得多。

Istio 用起來很嚇人。我經歷過一個巨大的單點故障,當開發人員誤命名了包含 TLS 密鑰的 Kubernetes 密鑰時,每個網關都中斷了,整個集羣都垮了。這是一個 bug,如果 Istio 無法找到密鑰,它將無法配置並停止所有服務。這調試起來非常困難。日誌中沒有任何內容可以指出到底出了什麼問題。Istio 很少在其他方面完全失效,通常與它將配置傳遞給 Envoy 代理的方式有關。他們稱之爲 “碎玻璃配置”(“Break Glass Configuration”)。

最後,也是最重要的一點是,Istio 不推薦使用 Helm 部署,而是推薦使用他們的 istioctl 命令行實用程序…… 然而,他們在更高的版本中重新引入了 Helm 的部署。我不喜歡用一堆不同的方法在集羣上部署 40 多個支持工具,所以當他們棄用 Helm 時,我非常失望,我使用的其他工具都支持 Helm。當我發現這只是暫時的時候,我更加沮喪。這意味着我必須離開後再回來升級到最新的 Istio 版本。

2 當初我爲什麼會選擇 Istio ?

當 Kubernetes 剛出現時,它還有其他 3 個主要競爭對手:Mesos、 Nomad 和 Swarm。很快,Kubernetes 就贏得這場戰爭。

我從未遇到過使用 Mesos 的人,這可能是因爲它沒有得到大公司的支持,儘管我聽說過 Mesos 對容器編排有着巨大的影響。

我見過的唯一使用 Swarm 的人,是因爲 Swarm 比 Kubernetes“更簡單”才使用的。我知道這不會長久的。它的 “簡單” 實際上是缺乏功能。如果你只使用 Kubernetes 特性中的一小部分,Kubernetes 也很簡單。

Nomad 現在還很活躍,如果你需要將流程直接編排到服務器上,那麼這就是你的選擇。如果你只需要容器編排,我強烈推薦你使用 Kubernetes。

不管怎樣,當 Istio 問世時,情況看起來非常熟悉。唯一的競爭對手是 Linkerd(我想在我的心目中這是一個 Swarm 類型的競爭對手),而 Istio 就像 Kubernetes 一樣,是谷歌的 “孩子”。所以我選擇了 Istio。

然後,服務網絡大戰開始了。首先出現的是 AWS 的 AppMesh,然後是 Traefik 的 Maesh,再然後是 Azure 的 Open Service Mesh(這可能是對 Istio 不加入 CNCF 爭議的一種諷刺),以及 Nginx 的服務網格。還有一些其他的,大多數都是使用 Envoy 代理來創建他們的服務網格,如 Kuma 和 Consul Connect。

這看來根本沒有明顯的贏家。

3 現在該用什麼?

在比較了所有的服務網格之後,我最終選擇了 Linkerd,也就是最初的那個。其他的要麼想偷偷進入供應商鎖定,要麼只是沒有按照我想要的方式工作(比如 Maesh,它向節點添加是代理而不是 Pod)。

我喜歡 Linkerd 的原因在於:

它支持使用 Helm 進行部署(實際上,我在所有部署中都使用了 Helm 的修改版本,並且我使用了一些自定義的代碼來避免外部手動配置)。它相當簡單。你只需要一個 CRD,Helm 圖也很易學。它們的儀表盤很順滑。Istio 使用 Grafana/Promethus 和 Kiali。Linkerd 也支持 Grafana/Prometheus,但它還有一個專用的定製儀表盤,很易於使用。它們用 Rust (v2)編寫了自己的代理。起初我對此感到很困惑,因爲 Envoy 如此受歡迎,但後來我意識到 Linkerd 可以快速發展。Envoy 現在是一個龐然大物,必須對許多供應商保持中立,但是 Linkerd 可以對自己的代理做任何想做的事情,從而使開發速度更快。而且,它是用 Rust 寫的!很酷,對吧?它們加入了 CNCF。而 Isito 沒有… Linkerd 第一步做對了。Istio 試圖嘗試一系列不同的部署,你必須管理它們,但現在它們已經轉移到單一部署上了。Linkerd 是第一個這樣做的。它確實有其他部署,但都不是 “核心” 的。它們增加特性後,你只需要關注核心部署就可以讓你的服務網格工作了。

Linkerd 有什麼不足之處嗎? 其實只有一件小事。我想這更像是一種營銷手段。他們聲稱這是一個服務網絡,你可以在 5 分鐘內安裝並使用它,一切都能準備好。但是,正如上文所述,服務網格並不是簡單地準備就緒就行了。Linkerd 也存在每個服務網格都有的問題:缺少原生 Sidecar 和不可靠的非 HTTP 協議處理。

4 小結

也許有一天,你使用哪個服務網格只是一個小問題,就像很多人甚至不知道他們在 Kubernetes 上使用的是什麼覆蓋網絡一樣。每個服務網格都在採用 SMI(服務網格接口),因此從長遠來看,我認爲服務網格將會成爲 Kubernetes 中的原生資源,而採用開放標準就是朝這個方向邁出的第一步。

Istio 尚未加入 CNCF,儘管 Chris DiBona 在 Kubernetes Podcast 上做了解釋,但我還是不太喜歡這個舉動。Linkerd 加入了 CNCF。如果它能保持一貫的簡潔,短時間內,我不打算在離開它。一旦 Kubernetes 獲得了某種原生的 Sidecar 解決方案,我會非常高興。

延伸閱讀:

https://medium.com/polymatic-systems/service-mesh-wars-goodbye-istio-b047d9e533c7

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/9x4XgAYGnNUd_pV8M6Zv8g