為何選擇 Istio？
Istio 在 2017 年推出時，率先提出了基於 Sidecar 的服務網格概念。該專案從一開始就包含了定義服務網格的功能，包括基於標準的相互 TLS 以實現零信任網路、智慧流量路由，以及透過指標、日誌和追蹤實現可觀察性。
自那時起，該專案推動了網格領域的進步，包括多叢集和多網路拓撲、透過 WebAssembly 實現擴展性、Kubernetes Gateway API 的開發，以及透過環境模式將網格基礎設施從應用程式開發人員手中移開。
以下是一些我們認為您應該使用 Istio 作為服務網格的原因。
簡單且強大
Kubernetes 有數百個功能和數十個 API，但您只需一個命令即可開始使用。我們構建 Istio 的方式也一樣。漸進式揭露意味著您可以使用一小組 API，並且只有在需要時才打開更強大的旋鈕。其他「簡單」的服務網格花了數年時間才趕上 Istio 第一天就擁有的功能集。
寧可擁有不需要的功能，也不要需要時卻沒有！
Envoy 代理
從一開始，Istio 就由 Envoy 代理提供支援，這是一個最初由 Lyft 構建的高效能服務代理。Istio 是第一個採用 Envoy 的專案，並且 Istio 團隊是第一個外部提交者。Envoy 後來成為 為 Google Cloud 提供支援的負載平衡器，以及幾乎所有其他服務網格平台的代理。
Istio 繼承了 Envoy 的所有強大功能和靈活性，包括使用 WebAssembly 的世界級擴展性，這是 由 Istio 團隊在 Envoy 中開發的。
社群
Istio 是一個真正的社群專案。在 2023 年，有 10 家公司各自為 Istio 做出了超過 1,000 次的貢獻，沒有任何一家公司超過 25%。（請在此處查看數字）。
沒有其他服務網格專案能像 Istio 一樣獲得業界如此廣泛的支援。
套件
我們為每個人提供穩定的二進位版本，每次發布都會提供，並承諾繼續這樣做。我們為最新版本和一些較早的版本發布免費且定期的安全性修補程式。我們的許多供應商將支援較舊的版本，但我們認為，要成為一個穩定的開放原始碼專案，不應強制要求與供應商合作才能確保安全。
考量的替代方案
一份好的設計文件包含一個關於所考慮但最終被拒絕的替代方案的部分。
為什麼不「使用 eBPF」？
我們確實這樣做 - 在適當的情況下！Istio 可以設定為使用 eBPF 將流量從 Pod 路由到代理。與使用 iptables 相比，這顯示出較小的效能提升。
為什麼不把它用於所有事情？沒有人這樣做，因為實際上沒有人能做到。
eBPF 是一個在 Linux 核心內部執行的虛擬機器。它的設計目的是用於保證在有限的運算範圍內完成的功能，以避免破壞核心行為的穩定性，例如執行簡單的 L3 流量路由或應用程式可觀察性的功能。它並非設計用於 Envoy 中常見的長時間執行或複雜的功能：這就是為什麼作業系統有 使用者空間！eBPF 維護者認為它最終可以擴展到支援執行像 Envoy 這樣複雜的程式，但這是一個科學專案，不太可能具有實際應用。
其他聲稱「使用 eBPF」的網格實際上使用每個節點的 Envoy 代理或其他使用者空間工具來實現其大部分功能。
為什麼不使用每個節點的代理？
Envoy 本質上不是多租戶的。因此，我們在共享實例中為多個不受約束的租戶混合 L7 流量的複雜處理規則時，存在嚴重的安全性與穩定性疑慮。由於 Kubernetes 預設可以將來自任何命名空間的 Pod 排程到任何節點上，因此節點並不是適當的租戶邊界。預算和成本歸屬也是主要問題，因為 L7 處理比 L4 花費更多。
在環境模式下，我們嚴格限制我們的 ztunnel 代理僅進行 L4 處理 - 就像 Linux 核心一樣。這大幅降低了漏洞暴露面，並允許我們安全地操作共享元件。然後將流量轉發到每個命名空間操作的 Envoy 代理，這樣就沒有 Envoy 代理是多租戶的。
我已經有 CNI 了。為什麼我還需要 Istio？
如今，某些 CNI 外掛程式開始提供類似服務網格的功能，作為建立在自身 CNI 實作之上的附加功能。例如，它們可以針對節點或 Pod 之間的流量實作自己的加密方案、工作負載身分，或透過將流量重新導向到 L7 代理來支援一定程度的傳輸層原則。這些服務網格附加元件是非標準的，因此只能在運送它們的 CNI 上運作。它們還提供不同的功能集。例如，建立在 Wireguard 之上的解決方案無法符合 FIPS 標準。
因此，Istio 實作了其零信任通道 (ztunnel) 元件，該元件使用經過驗證的業界標準加密協定，透明且有效率地提供此功能。 深入了解 ztunnel。
Istio 的設計目的是成為一個服務網格，它提供一致、高度安全、高效且符合標準的服務網格實作，提供 強大的 L7 原則集、與平台無關的工作負載身分，使用 業界驗證的 mTLS 協定 - 在任何環境中、使用任何 CNI，甚至是跨具有不同 CNI 的叢集。