<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      Kubernetes 的核心是 API 框架而非容器

        時間回到 2013 年。當一條簡單的 docker run postgre 命令就能運行起 Postgre 這樣復雜的傳統服務時,開發者在震驚之余猶如受到天啟;以 Docker 為代表的實用容器技術的橫空出世,也預示著一扇通往敏捷基礎設施的大門即將打開。此后,一切都在往好的方向迅速發展:

        越來越多的開發者開始采用容器作為一種標準構建和運行方式。

        業界也意識到,很容易將這種封裝方式引入計算集群,通過 Kubernetes 或 Mesos 這樣的編排器來調度計算任務 —— 自此,容器便成為這些調度器最重要的 Workload 類型。

        但本文將要說明,容器并非 Kubernetes 最重要、最有價值的地方,Kubernetes 也并非僅僅是一個更廣泛意義上的 Workload 調度器 —— 高效地調度不同類型的 Workload 只是 Kubernetes 提供的一種重要價值,但并不是它成功的原因。

        API 才是核心

        “等等 —— Kubernetes 只是一堆 API?”

        “不好意思,一直都是!”

        Kubernetes 的成功和價值在于,提供了一種標準的編程接口(API),可以用來編寫和使用軟件定義的基礎設施服務(本文所說的“基礎設施”,范圍要大于 IaaS):

        Specification + Implementation 構成一個完整的 API 框架 —— 用于設計、實現和使用各種類型和規模的基礎設施服務;

        這些 API 都基于相同的核心結構和語義:typed resources watched and reconciled by controllers (資源按類型劃分,控制器監聽相應類型的資源,并將其實際 status 校準到 spec 里期望的狀態)。

        為了進一步解釋這一點,考慮下 Kubernetes 出現之前的場景。

        Kubernetes 之前:各自造輪子,封裝廠商 API 差異

        Kubernetes 之前,基礎設施基本上是各種不同 API、格式和語義的“云”服務組成的大雜燴:

        云廠商只提供了計算實例、塊存儲、虛擬網絡和對象存儲等基礎構建模塊,開發者需要像拼圖一樣將它們拼出一個相對完整的基礎設施方案;

        對于其他云廠商,重復過程 1,因為各家的 API、結構和語義并不相同,甚至差異很大。

        雖然 Terraform 等工具的出現,提供了一種跨廠商的通用格式,但原始的結構和語義仍然是五花八門的,—— 針對 AWS 編寫的 Terraform descriptor 是無法用到 Azure 的。

        Kubernetes 面世:標準化、跨廠商的 API、結構和語義

        現在再來看 Kubernetes 從一開始就提供的東西:描述各種資源需求的標準 API。例如:

        描述 Pod、Container 等計算需求的 API;

        描述 Service、Ingress 等虛擬網絡功能的 API;

        描述 Volumes 之類的持久存儲的 API;

        甚至還包括 Service Account 之類的服務身份的 API 等等。

        這些 API 是跨公有云/私有云和各家云廠商的,各云廠商會將 Kubernetes 結構和語義對接到它們各自的原生 API。因此我們可以說,Kubernetes 提供了一種管理軟件定義基礎設施(也就是云)的標準接口?;蛘哒f,Kubernetes 是一個針對云服務(Cloud Services)的標準 API 框架。

        Kubernetes API 擴展:CRD

        提供一套跨廠商的標準結構和語義來聲明核心基礎設施(Pod/Service/Volume/ServiceAccount/……), 是 Kubernetes 成功的基礎。在此基礎上,它又通過 CRD(Custom Resource Definition), 將這個結構擴展到任何/所有基礎設施資源。

        CRD 在 1.7 引入,允許云廠商和開發者自己的服務復用 Kubernetes 的 spec/impl 編程框架。

        有了 CRD,用戶不僅能聲明 Kubernetes API 預定義的計算、存儲、網絡服務,還能聲明數據庫、task runner、消息總線、數字證書……任何云廠商能想到的東西!

        Operator Framework 以及 SIG API Machinery 等項目的出現,提供了方便地創建和管理這些 CRD 的工具,最小化用戶工作量,最大程度實現標準化。

        例如,Crossplane 之類的項目,將廠商資源 RDS 數據庫、SQS queue 資源映射到 Kubernetes API,就像核心 Kubernetes controller 一樣用自己的 controller 來管理網卡、磁盤等自定義資源。Google、RedHat 等 Kubernetes 發行商也在它們的基礎 Kubernetes 發行版中包含越來越多的自定義資源類型。

        小結

        我們說 Kubernetes 的核心是其 API 框架,但并不是說這套 API 框架就是完美的。事實上,后一點并不(非常)重要,因為 Kubernetes 模型已經成為一個事實標準:開發者理解它、大量工具主動與它對接、主流廠商也都已經原生支持它。用戶認可度、互操作性 經常比其他方面更能決定一個產品能否成功。

        隨著 Kubernetes 資源模型越來越廣泛的傳播,現在已經能夠 用一組 Kubernetes 資源來描述一整個軟件定義計算環境。就像用 docker run 可以啟動單個程序一樣,用 kubectl apply -f 就能部署和運行一個分布式應用, 而無需關心是在私有云還是公有云以及具體哪家云廠商上,Kubernetes 的 API 框架已經屏蔽了這些細節。

        因此,Kubernetes 并不是關于容器的,而是關于 API。

      0
      相關文章
        漂亮的苏酥全文阅读