Istio 2020 的目標是更快的速度，更簡單的用法
作者 ISTIO TEAM | 2020年3月3日 | 閱讀大約需要 2 分鐘
Istio 解決了人們在運行微服務時遇到的實際問題。甚至早期的預發行版本就已經可以幫助用戶診斷其體系架構中的延遲，提高服務的可靠性以及透明地保護防火牆後的流量。
去年，Istio 項目成長巨大。經過 9 個月的醞釀，在 2019 年第一季度發行 1.1 之前，我們設定了一個季度發佈節奏的目標。我們知道，持續且可預測地交付非常重要。我們計劃連續三個季度發佈三個版本，並且我們為實現了這一目標感到自豪。
過去一年，我們改進了構建和測試基礎架構，從而提高了質量並簡化了發佈週期。我們將用戶體驗提高了一倍，添加了許多命令使網格的操作和調試變得更加簡單。我們還看到為 Istio 做出貢獻的開發人員和公司數量急劇增長，最終，我們成為了 GitHub 增長最快的十大項目中排名第 4 名！
2020 年，Istio 有宏偉的目標，並且我們正在努力中。與此同時，我們堅信良好的基礎設施應該“無聊”。在生產中使用 Istio 應該是無縫的體驗；性能不應該成為問題，升級應該是非事件性的，複雜的任務應自動化。隨著我們對更強大的可擴展性的投入，我們認為 Istio 在專注於現在成就的同時，可以加快服務網格領域的創新步伐。以下是我們在 2020 年主要工作的詳情。
更快、更簡單
從第一天起，Istio 就通過 Mixer 組件提供了可擴展性支持。Mixer 是一個平臺，允許使用自定義適配器充當數據平面與策略及遙測後端之間的中介。Mixer 必定會增加請求的開銷，因為它必須擴展到進程之外。因此，我們正在向一種可以直接在代理中進行擴展的模型轉變。
Istio 的認證和授權策略已經涵蓋了 Mixer 用於策略執行的大多數用例，這些策略使您可以直接在代理中控制 workload 到 workload 以及終端用戶到 workload 的授權。常見的監控用例也已經轉移到代理中，我們引入了代理內支持，以便將遙測發送到 Prometheus 和 Stackdriver。
我們的基準測試表明，新的遙測模型可顯著減少延遲，並可提供行業領先的性能，同時降低 50％ 的延遲和 CPU 消耗。
新的 Istio 可擴展性模型
新的 Mixer 模型使用 Envoy 中的擴展來提供更多功能。Istio 社區正在領導 Envoy 的 WebAssembly（Wasm）運行時的實現，Wasm 讓我們可以使用超過 20 種的語言來開發模塊化、沙盒化的擴展。可以在代理繼續提供流量的同時動態加載、重載擴展。Wasm 擴展程序還可以通過 Mixer 無法做到的方式來擴展平臺。它們可以充當自定義協議處理程序，並在通過 Envoy 時轉換有效負載，簡而言之，它們可以執行與 Envoy 中內置的模塊相同的操作。
我們正在與 Envoy 社區一起研究發現和分發這些擴展的方法。我們希望使 WebAssembly 擴展像容器一樣易於安裝和運行。我們的許多合作伙伴已經編寫了 Mixer 適配器，並與我們一起將其移植到 Wasm。如何編寫自己的擴展並進行自定義集成？我們正在開發相關的指南和代碼實驗室。
更換擴展模型後，我們還可以刪除數十個 CRD。與 Istio 集成的每個軟件都不再需要唯一 CRD。
通過 preview 配置文件安裝 Istio 1.5 不會再安裝 Mixer。安全起見，如果您是從以前的版本升級，或通過 default 配置文件安裝，我們仍會保留 Mixer。當使用 Prometheus 或 Stackdriver 進行度量時，建議您嘗試新模式並查看性能提高了多少。
如果有需要，您可以保持安裝並啟用 Mixer。最終，Mixer 將成為 Istio 單獨的發行組件，成為 istio-ecosystem 的一部分。
減少移動部分
我們還將簡化其餘控制平面的 deployment。為此，我們將幾個控制平面組件合併為一個組件：Istiod。該二進制文件包括 Pilot、Citadel、Galley 和 Sidecar 注入器的功能。這種方法從許多方面改善了 Istio 的安裝和管理，降低了安裝和配置的複雜性、維護工作量以及問題診斷時間，同時提高了響應速度。 關於 Istiod 的更多內容請查看 Christian Posta 的這篇博客。
我們將 Istiod 作為 1.5 中所有配置文件的默認配置。
為了減少每個節點的佔用空間，我們放棄了用於分發證書的節點代理，並將其功能遷移至已經在每個 Pod 中運行的 istio-agent 中。從圖片來看，我們正在從這裡：
Istio 目前的架構
老架構
遷移到這裡：
Istio 1.5 新架構
Istio 2020 年的架構
2020 年，我們將繼續專注於普及，實現默認 零配置 的目標，該默認設置不需要您更改應用程序的任何配置即可使用 Istio 的大多數功能。
改進生命週期管理
為了改進 Istio 的生命週期管理，我們使用了基於 operator 的安裝方式。這裡介紹 Istio Operator CRD 的兩種安裝模式：
- 人為觸發：使用 istioctl 將設置應用至集群。
- 機器觸發：使用一個控制器，實時觀察 CRD 的改動並使其生效。
在 2020 年，升級 Istio 也將變得更加容易。我們將添加對 Istio 控制平面新版本的”金絲雀”支持，這使您可以同時運行現有版本的和新版本，並將數據平面逐漸切換至新版本。
默認安全
Istio 已經為強大的服務安全性提供了基礎：可靠的 workload 身份、強大的訪問策略、全面的審核日誌記錄。我們正在為這些功能提供穩定的 API；許多 Alpha API 都將在 1.5 版中過渡為 Beta 版，我們希望到 2020 年底它們都將成為 v1 版本。要了解有關 API 狀態的更多信息，請參見我們的功能頁面。
默認情況下，網絡流量也變得更加安全。繼許多用戶可以在評估時啟用它之後，自動雙向 TLS 已成為 Istio 1.5 中的推薦做法。
此外，我們將讓 Istio 所需的權限更少，並簡化其依賴性，從而使 Istio 成為更強大的系統。在以前，您必須使用 Kubernetes Secrets 將證書安裝到 Envoy，這些證書作為文件掛載至每個代理中。而現在，通過密鑰發現服務（SDS） ，我們可以安全地分發這些證書，而不必擔心它們會被計算機上的其他 workload 攔截。該模式將成為 1.5 中的默認模式。
擺脫節點代理，不僅簡化了部署，而且消除了對整個集群範圍內 PodSecurityPolicy 的要求，從而進一步改善了集群的安全性。
其它功能
這是 Istio 在 2020 年一些值得期待的、令人興奮的事情：
- 與更多託管的 Kubernetes 環境集成，目前已有 15 個供應商提供了 Istio 服務網格，這些公司包括：Google、IBM、Red Hat、VMware、Alibaba 以及 Huawei。
- 更多的關注 istioctl 及其幫助診斷問題的能力。
- 將基於 VM 的 workload 更好地集成到網格中。
- 繼續努力使多群集和多網絡網格更易於配置、維護和運行。
- 與更多的服務發現系統集成，包括 Functions-as-a-Service。
- 實現新的 Kubernetes service API（目前正在開發中）。
- 增強存儲庫，以便開發追蹤功能。
- 讓沒有 Kubernetes 的 Istio 可以更輕鬆地運行！
從大海到天空，Istio 期待您的加入！
閱讀更多 老程序猿尉遲理 的文章
