Istio 的通信 Sidecar 控制平面

Question

我目前正在研究 1.6 版本的服務網格 Istio。 數據平面（Envoy 代理）由控制平面配置。 特別是 Pilot（istiod 的一部分）負責將路由規則和配置傳播給 envoy。 我想知道通信是如何工作的？

1. 是否是單個 gRPC stream 在 sidecar 容器第一次啟動時打開並在 sidecar 整個生命周期內保持打開狀態。 如果網格發生變化，Pilot 使用此 ZF7B44CFFAFD5C52223D5498196C8A2E7BZ 通過 xDS api 通知特使有關變化？ 那么更新是基於推送策略的嗎？ 或者邊車是否在定義的時間間隔內拉取新配置？
2. 邊車容器中的 istio 代理（fromer Pilot 和 Citadel 代理）的作用是什么（尤其是以前的 Pilot 代理，我知道 Citadel 代理是 CSR 進程的）？ 它是否會拉取新配置，是否僅引導特使，但為什么它總是在運行，...？

提前致謝！

Answer 1

1. 對 istio envoy 工作原理的最佳解釋來自 envoy 文檔。 它實際上比看起來要復雜得多：

初始化

Envoy 在啟動時如何進行自我初始化很復雜。 本節從高層次上解釋了該過程是如何工作的。 以下所有事件發生在任何偵聽器開始偵聽和接受新連接之前。

• 在啟動期間， 集群管理器會進行多階段初始化，首先初始化靜態/DNS 集群，然后是預定義的EDS集群。 然后它初始化CDS （如果適用），在有限的時間段內等待一個響應（或失敗），並對 CDS 提供的集群進行相同的主/輔助初始化。

• 如果集群使用主動健康檢查，Envoy 也會進行一次主動健康檢查。

• 一旦集群管理器初始化完成， RDS和LDS就會初始化（如果適用）。 對於 LDS/RDS 請求，服務器會等待至少一個響應（或失敗）的有界時間段。 之后，它開始接受連接。

• 如果 LDS 本身返回一個需要 RDS 響應的偵聽器，Envoy 會進一步等待一段時間，直到收到 RDS 響應（或失敗）。 請注意，此過程發生在以后通過 LDS 添加的每個聽眾上，稱為聽眾預熱。

• 完成所有前面的步驟后，偵聽器開始接受新連接。 此流程確保在熱重啟期間，新進程完全能夠在舊進程耗盡之前接受和處理新連接。

初始化的一個關鍵設計原則是始終保證 Envoy 在initial_fetch_timeout內初始化，並盡最大努力在管理服務器可用性的情況下獲得完整的 xDS 配置集。

至於更新特使配置：

運行時配置

Envoy 支持“運行時”配置（也稱為“功能標志”和“決策者”）。 無需重新啟動 Envoy 或更改主配置即可更改影響操作的配置設置。 當前支持的實現使用文件系統文件樹。 Envoy 監視配置目錄中的符號鏈接交換，並在發生這種情況時重新加載樹。 這種類型的系統通常部署在大型分布式系統中。 其他實現方式並不難實現。 支持的運行時配置設置記錄在操作指南的相關部分中。 Envoy 將使用默認運行時值和“null”提供程序正確運行，因此不需要存在這樣的系統來運行 Envoy。

運行時配置。

有關特使代理如何工作的更多信息，請參見此處。

---

2. 根據 istio文檔：

合並的好處：引入 istiod

在確定微服務的許多共同優勢不適用於 Istio 控制平面后，我們決定將它們統一到一個二進制文件中： istiod （“d”代表daemon ）。

讓我們看看新包裝的好處：

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

• 配置變得更容易。 Istio 今天擁有的許多配置選項都是編排控制平面組件的方法，因此不再需要。 您也不再需要更改集群范圍的PodSecurityPolicy來部署 Istio。

• 使用虛擬機變得更容易。 要將工作負載添加到網格，您現在只需安裝一個代理和生成的證書。 該代理只連接回一個服務。

• 維護變得更容易。 安裝、升級和刪除 Istio 不再需要復雜的版本依賴和啟動順序。 例如：要升級，您只需在現有控制平面旁邊啟動一個新的 istiod 版本，對其進行金絲雀化，然后將所有流量轉移到它。

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

• 調試變得更容易。 更少的組件意味着更少的跨組件環境調試。

• 啟動時間減少。 組件不再需要彼此等待以定義的順序啟動。

• 資源使用率下降，響應能力提高。 組件之間的通信得到保證，並且不受 gRPC 大小限制。 可以安全地共享緩存，從而減少資源占用。

istiod 將 Pilot、Galley、Citadel 和 sidecar injector 之前執行的功能統一到一個二進制文件中。

一個單獨的組件 istio-agent 通過將配置和機密安全地傳遞給 Envoy 代理來幫助每個 Sidecar 連接到網格。 雖然代理，嚴格來說，仍然是控制平面的一部分，但它在每個 pod 的基礎上運行。 我們通過將曾經作為 DaemonSet 運行的每個節點的功能滾動到每個 pod 代理中來進一步簡化。

希望能幫助到你。