Istio控制平面故障後會發生什麼？

做者：Jonh Wendell 
譯者：李守超 
校對：楊傳勝 
原文： www.servicemesher.com/blog/istio-…

你們好！我在Istio上作了一些實驗，禁用控制平面的組件，並觀察應用和服務網格會發生什麼。下面是個人筆記。

Pilot

Pilot負責Istio的流量控制特性，同時將Sidecar更新至最新的網格配置。

Pilot啓動之後，監聽端口15010（gRPC）和8080（HTTP）。

當應用的Sidecar（Envoy，Istio-Proxy）啓動之後，它將會鏈接pilot.istio-system:15010，獲取初始配置，並保持長鏈接。

Pilot會監聽Kubernetes資源，只要檢測到網格發生變化，就會將最新的配置經過gRPC鏈接推送到Sidecar上。

• 當Pilot中止之後，Pilot和Sidecar之間的gRPC鏈接被關閉，同時Sidecar會一直嘗試重連。

• 網絡流量不會受到Pilot中止的影響，由於全部的配置被推送過來之後，就會存儲在Sidecar的內存中。

• 網格中新的變動信息（例如新的Pod、規則、服務等等）不會繼續到達Sidecar，由於Pilot再也不監聽這些變化並轉發。

• 當Pilot從新上線之後，Sidecar就會從新創建鏈接（一直嘗試重連）並獲取到最新的網格配置。

Mixer Policy

Policy執行網絡策略。

Mixer在啓動時讀取配置，並監聽Kubernetes的資源變化。一旦檢測到新的配置，Mixer就會將其加載至內存中。

Sidecar在每次請求服務應用時，檢查（發起鏈接）Mixer Policy Pod。

當Mixer Policy Pod中止之後，全部到服務的請求會失敗，並收到 「503 UNAVAILABLE:no healthy upstream」 的錯誤——由於全部 sidecar 沒法鏈接到這些Pod。

在Istio 1.1版本中新增了[global]配置（policyCheckfailOpen），容許「失敗打開」策略，也即當Mixer Policy Pod沒法響應時，全部的請求會成功，而不是報 503 錯誤。默認狀況下該配置設置爲false，也即「失敗關閉」。

當Mixer中止後，咱們在網格中執行的操做（例如新增規則、更新配置等等）都不會對應用產生影響，直到Mixer從新啓動。

Mixer Telemetry

Telemetry爲Istio插件提供遙測信息。

Sidecar何時調用Telemetry Pod取決於兩個因素：批量完成100次請求和請求時間超過1秒鐘（默認配置），這兩個條件只要有一個先知足就會執行該操做，這是爲了不對Telemetry Pod形成過於頻繁的調用。

當Telemetry Pod中止之後，Sidecar記錄一次失敗信息（在Pod標準錯誤輸出裏），並丟棄遙測信息。請求不會受到影響，正如Policy Pod中止時同樣。當Telemetry Pod從新啓動之後，就會繼續從Sidecar收到遙測信息。

其它信息

值得注意的是，Istio容許自定義控制平面的組件。例如，若是不須要Policy，你能夠徹底禁用Mixer Policy。Istio 1.1對這種模塊化的特性支持的更好。更多信息，能夠參考這篇文檔。

固然，Pilot、Mixer Policy和Mixer Telemetry在高可用部署場景工做的也很好，能夠同時運行多副本。實際上，默認配置經過 HorizontalPodAutoscaler 容許啓動1到5個Pod。（詳細請參考這篇文檔和這篇文檔）