作者：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。（詳細請參考這篇文件和這篇文件）