介紹 istiod：簡化控制平面

當微服務將服務對應到交付它們的不同團隊，或者當獨立部署和獨立擴展的價值大於編排成本時，微服務是一個很棒的模式。我們經常與在真實環境中運行 Istio 的客戶和團隊交談，他們告訴我們 Istio 控制平面並非如此。因此，在 Istio 1.5 中，我們更改了 Istio 的打包方式，將控制平面功能整合到一個名為 istiod 的單一二進位檔中。

Istio 控制平面的歷史

Istio 實作了一種在 Google 和 IBM 使用多年的模式，後來被稱為「服務網格」。透過將客戶端和伺服器程序與代理伺服器配對，它們充當應用程式感知的資料平面，而不僅僅是在主機之間移動數據包或在電線上傳輸脈衝。

這種模式幫助世界接受微服務：透過輕量級協定連接的細粒度、鬆散耦合的服務。像 HTTP 和 gRPC 這樣通用的跨平台和跨語言標準取代了專有傳輸，並且所需函式庫的廣泛存在，使不同的團隊能夠以最合理的語言編寫整個架構的不同部分。此外，每個服務都可以根據需要獨立擴展。為此類網路實施安全性、可觀察性和流量控制的願望推動了 Istio 的普及。

Istio 的控制平面本身就是一個現代的雲原生應用程式。因此，它從一開始就被構建為一組微服務。諸如服務發現 (Pilot)、配置 (Galley)、憑證生成 (Citadel) 和可擴展性 (Mixer) 之類的單獨 Istio 組件都被編寫並部署為單獨的微服務。這些組件需要安全地通信並具有可觀察性，這為 Istio 提供了「吃自己的狗食」（或者，用更法式的比喻來說，「喝自己的香檳」）的機會！

複雜性的代價

好的團隊會回顧他們的選擇，並且在事後諸葛的角度下重新審視它們。一般來說，當團隊採用微服務及其固有的複雜性時，他們會尋找其他領域的改進來證明權衡的合理性。讓我們透過這個角度來看看 Istio 控制平面。

• 微服務使您能夠以不同的語言編寫程式碼。 資料平面（Envoy 代理）是用 C++ 編寫的，並且這個邊界受益於 xDS API 中的明確分離。但是，所有 Istio 控制平面組件都是用 Go 編寫的。我們能夠為適當的工作選擇適當的語言：用於代理的高效能 C++，以及適用於其他所有內容的易於存取和快速開發的 Go。

• 微服務使您能夠允許不同的團隊單獨管理服務。 在絕大多數 Istio 安裝中，所有組件都由單個團隊或個人安裝和操作。Istio 內部完成的組件化是沿著構建它的開發團隊的邊界對齊的。如果 Istio 組件是由編寫它們的人員以託管服務的形式交付，這將是有道理的，但事實並非如此！為開發團隊簡化生活對數個數量級的更多使用者的可用性產生了巨大的影響。

• 微服務使您能夠解耦版本，並在不同的時間發布不同的組件。 控制平面的所有組件始終在同一時間以相同的版本發布。我們從未測試或支援執行不同版本的（例如）Citadel 和 Pilot。

• 微服務使您能夠獨立擴展組件。 在 Istio 1.5 中，控制平面的成本由一個單一功能主導：為程式化資料平面的 Envoy xDS API 提供服務。其他所有功能的成本都很低，這意味著將這些功能放在可單獨擴展的微服務中沒有太大價值。

• 微服務使您能夠維護安全邊界。 將應用程式分離為不同微服務的另一個好理由是它們具有不同的安全角色。多個 Istio 微服務（如 sidecar injector、Envoy bootstrap、Citadel 和 Pilot）持有幾乎相同的權限來變更代理配置。因此，利用任何這些服務都會造成幾乎相同的損害。當您部署 Istio 時，預設情況下，所有組件都會安裝到同一個 Kubernetes 命名空間中，提供有限的安全性隔離。

整合的好處：介紹 istiod

在確定微服務的許多常見好處不適用於 Istio 控制平面之後，我們決定將它們統一到一個單一的二進位檔中：istiod（「d」代表 daemon）。

讓我們看看新封裝的好處

• 安裝變得更容易。 需要較少的 Kubernetes 部署和相關配置，因此 Istio 的配置選項和標誌集顯著減少。在最簡單的情況下，您可以透過啟動單個 Pod 來啟動 Istio 控制平面，並啟用所有功能。

• 配置變得更容易。 Istio 現在的許多配置選項都是編排控制平面組件的方法，因此不再需要。您也不再需要變更叢集範圍的 PodSecurityPolicy 來部署 Istio。

• 使用虛擬機器變得更容易。 若要將工作負載新增至網格，您現在只需安裝一個代理和產生的憑證即可。該代理只會連回到單一服務。

• 維護變得更容易。 安裝、升級和移除 Istio 不再需要複雜的版本相依性和啟動順序。例如：若要升級，您只需要在現有控制平面旁邊啟動一個新的 istiod 版本，將其金絲雀發布，然後將所有流量轉移到該版本。

• 擴展性變得更容易。 現在只有一個組件需要擴展。

• 偵錯變得更容易。 較少的組件意味著較少的跨組件環境偵錯。

• 啟動時間縮短。 組件不再需要等待彼此以指定的順序啟動。

• 資源使用量減少，回應能力提高。 組件之間的通信得到保證，且不受 gRPC 大小限制的約束。快取可以安全地共用，從而減少資源佔用量。

istiod 將 Pilot、Galley、Citadel 和 sidecar injector 先前執行的功能整合到單一二進位檔中。

一個單獨的組件 istio-agent 有助於每個 sidecar 透過安全地將配置和密碼傳遞給 Envoy 代理來連接到網格。雖然嚴格來說，代理仍然是控制平面的一部分，但它是在每個 Pod 的基礎上執行的。我們進一步簡化了將以前作為 DaemonSet 執行的每個節點功能整合到每個 Pod 代理中的方法。

專家的額外資訊

在某些情況下，您可能仍然希望獨立運行 Istio 組件，或替換某些組件。

某些使用者可能希望在網格外部使用憑證授權單位 (CA)，我們有 關於如何執行此操作的文件。如果您使用不同的工具執行憑證佈建，我們可以改用該工具，而不是內建的 CA。

展望未來

istiod 的核心只是一種封裝和最佳化變更。它建立在與單獨組件相同的程式碼和 API 契約之上，並且仍然在我們全面的測試套件的涵蓋範圍內。這讓我們有信心將其設定為 Istio 1.5 中的預設值。該服務現在稱為 istiod - 您將看到一個 istio-pilot，因為升級過程完成了現有代理。

雖然轉向 istiod 看起來像是個很大的變更，並且對於管理和維護網格的人來說是一個巨大的改進，但它不會使使用 Istio 的日常生活有任何不同。istiod 不會變更任何用於配置網格的 API，因此您現有的流程將保持不變。

此變更是否暗示微服務對於所有工作負載和架構都是錯誤的？當然不是。它們是工具箱中的一個工具，並且當它們反映在您的組織現實中時，它們的效果最佳。相反，此變更顯示該專案願意根據使用者回饋進行變更，並持續關注為所有使用者簡化。微服務必須調整到適當的大小，我們相信我們已經找到了 Istio 的適當大小。