Istio API 的演進

Istio API 背後的設計原則以及這些 API 如何演進。

2019 年 8 月 5 日 | 作者：Louis Ryan - Google，Sandeep Parikh - Google

Istio 的主要目標之一始終是，並且將繼續是，使團隊能夠開發最適合其特定組織和工作負載的抽象概念。Istio 為服務間網路提供強大且功能強大的建構模組。自Istio 0.1以來，Istio 團隊一直在向生產用戶學習他們如何將自己的架構、工作負載和約束對應到 Istio 的功能，並且我們一直在改進 Istio 的 API，使其更適合您。

Istio API 的演進

Istio 演進的下一步是集中我們的焦點，並與 Istio 用戶的角色保持一致。安全管理員應該能夠與一個 API 互動，該 API 在 Istio 網格內以邏輯方式分組並簡化安全操作；服務營運商和流量管理操作也是如此。

更進一步來說，有機會為每個角色的初級、中級和高級用例提供改進的體驗。有許多常見的用例可以使用明顯的預設設定和更好的定義初始體驗來解決，而無需進行任何配置。對於中級用例，Istio 團隊希望利用環境中的上下文提示，並為您提供更簡單的配置體驗。最後，對於高級場景，我們的目標是使簡單的事情變得容易，困難的事情變得可能。

然而，為了提供這類以角色為中心的抽象概念，它們底層的 API 必須能夠描述 Istio 的所有功能。從歷史上看，Istio 的 API 設計方法遵循與其他基礎架構 API 類似的路徑。Istio 遵循以下設計原則

  1. Istio API 應力求
    • 正確表示它們所對應的基礎資源
    • 不應隱藏任何基礎資源的有用功能
  2. Istio API 也應該是可組合的，以便終端用戶可以以對他們自身需求有意義的方式組合基礎架構 API。
  3. Istio API 應該是靈活的：在一個組織內，應該可以對基礎資源進行不同的表示，並呈現對每個團隊都有意義的資源。

在接下來的幾個版本中，我們將分享我們在加強 Istio API 與 Istio 用戶角色之間一致性的進展。

可組合性和抽象概念

Istio 和 Kubernetes 通常會一起使用，但 Istio 不僅僅是 Kubernetes 的附加元件，它和 Kubernetes 一樣是一個平台。Istio 旨在提供基礎架構，並在強大的服務網格中呈現您需要的功能。例如，有些平台即服務產品使用 Kubernetes 作為其基礎，並以 Kubernetes 的可組合性為基礎，為應用程式開發人員提供一組 API。

必須配置才能部署應用程式的物件數量是 Kubernetes 可組合性的具體範例。據我們統計，至少需要配置 10 個物件：Namespace、Service、Ingress、Deployment、HorizontalPodAutoscaler、Secret、ConfigMap、RBAC、PodDisruptionBudget 和 NetworkPolicy。

這聽起來很複雜，但並非每個人都需要與這些概念互動。有些是不同團隊（例如叢集、網路或安全管理團隊）的責任，而且許多都提供了合理的預設值。雲端原生平台和部署工具的一個巨大優勢在於，它們可以透過接收少量資訊並為您配置這些物件來隱藏這種複雜性。

在網路領域中，Google Cloud HTTP(S) 負載平衡器 (GCLB) 中也可以找到可組合性的另一個範例。若要正確使用 GCLB 的執行個體，需要建立和配置六個不同的基礎架構物件。這種設計是我們 20 年操作分散式系統經驗的結果，而且每個物件與其他物件分離的原因。但是當您透過 Google Cloud 主控台建立執行個體時，步驟會簡化。我們會提供更常見的終端用戶/角色特定配置，您可以稍後配置較不常見的設定。最終，基礎架構 API 的目標是在不犧牲功能的情況下提供最大的靈活性。

Knative 是一個用於建置、執行和操作無伺服器工作負載的平台，它提供了一個很棒的以角色為中心的高階 API 實例。Knative Serving 是 Knative 的一個元件，它以 Kubernetes 和 Istio 為基礎來支援部署和提供無伺服器應用程式和功能，它為應用程式開發人員提供了一種針對管理服務的路由和修訂版本的特定工作流程。由於這種特定的方法，Knative Serving 透過簡化的Routes 物件，公開了 Istio 網路 API 的子集，這些子集與應用程式開發人員最相關，該物件支援修訂版本和流量路由，並抽象化了 Istio 的VirtualService 和 DestinationRule 資源。

隨著 Istio 的成熟，我們也看到生產用戶在 Istio 的基礎架構 API 之上開發特定於工作負載和組織的抽象概念。

AutoTrader UK 有一個我們最喜歡的在 Istio 上建置自訂平台的範例。在與 Google Kubernetes Podcast 的訪談中，Russel Warman 和 Karl Stoney 描述了他們基於 Kubernetes 的交付平台，其中包含使用 Prometheus 和 Grafana 的成本儀表板。他們只需付出最少的努力，即可新增配置選項來確定開發人員希望在網路上配置什麼，現在它管理著實現該目標所需的 Istio 物件。在企業和雲端原生公司中，還有無數的其他平台正在建置中：有些旨在取代公司特定的自訂腳本網路，而有些則旨在成為通用的公共工具。隨著越來越多的公司開始公開談論他們的工具，我們將在本部落格上分享他們的故事。

接下來會是什麼

我們正在為即將發布的版本努力改進的幾個方面包括

哦，如果因為某些原因您是根據它安裝的 CRD 清單來判斷工具箱，那麼在 Istio 1.2 中，我們將數量從 54 個減少到 23 個。為什麼？事實證明，如果您有很多功能，則需要一種方法來配置所有這些功能。透過我們對安裝程式所做的改進，您現在可以使用與您的配接器搭配使用的設定來安裝 Istio。

所有服務網格，以及延伸的 Istio，都旨在自動化複雜的基礎架構操作，例如網路和安全性。這意味著其 API 中始終會存在複雜性，但 Istio 將始終致力於解決營運商的需求，同時繼續改進 API 以提供強大的建構模組，並透過以角色為中心的抽象概念來優先考慮靈活性。

我們迫不及待想邀請您加入我們的社群，看看您接下來會使用 Istio 建置什麼！

分享這篇文章