本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

介紹資源管理工作組

作者：Jeremy Eder (Red Hat) |

我們為什麼在這裡？

Kubernetes 已發展到支援多樣化且日益複雜的應用程式類別。我們可以部署和擴充套件基於微服務的現代雲原生 Web 應用程式、批處理作業以及具有持久儲存需求的狀態有狀態應用程式。

然而，Kubernetes 仍有機會改進；例如，執行需要專用硬體或在考慮硬體拓撲時效能明顯更好的工作負載的能力。這些衝突可能使應用程式類別（特別是在成熟的垂直領域）難以採用 Kubernetes。

我們在此看到了前所未有的機會，如果錯失，代價將是巨大的。Kubernetes 生態系統必須透過有意義地滿足尚未服務的的需求，為下一代系統架構創造一條可消費的前進道路。資源管理工作組與其他 SIGs 一道，必須展示客戶希望看到的願景，同時使解決方案能夠在一個完全整合、精心規劃的端到端堆疊中良好執行。
 
當某個特定挑戰需要跨 SIG 協作時，就會建立 Kubernetes 工作組。例如，資源管理工作組主要與 sig-node 和 sig-scheduling 合作，以推動 Kubernetes 中對額外資源管理功能的支援。我們確保經常諮詢來自不同 SIGs 的關鍵貢獻者，因為工作組無意代表任何 SIG 做出系統級決策。
 
其中一個例子和關鍵優勢是工作組與 sig-node 的關係。我們能夠確保在考慮功能設計之前完成幾個版本的節點可靠性工作（在 1.6 中完成）。這些設計是使用案例驅動的：研究各種工作負載的技術要求，然後根據對最大橫截面的可衡量影響進行排序。

目標工作負載和用例

工作組的關鍵設計原則之一是使用者體驗必須保持簡潔和可移植，同時仍能展現業務和應用程式所需的基礎設施能力。
 
雖然不代表任何承諾，但我們希望 Kubernetes 最終能夠最佳化執行金融服務工作負載、機器學習/訓練、網格排程器、MapReduce、動畫工作負載等。作為一個用例驅動的團隊，我們考慮潛在的應用程式整合，這也可以促進一個互補的獨立軟體供應商生態系統在 Kubernetes 之上蓬勃發展。

venn-kubernetes.png

為什麼這樣做？

Kubernetes 很好地涵蓋了通用 Web 託管功能，那麼為什麼還要費力擴充套件 Kubernetes 的工作負載覆蓋範圍呢？事實是，目前 Kubernetes 優雅地涵蓋的工作負載只佔全球計算使用量的一小部分。我們有一個巨大的機會，可以安全、有條不紊地擴充套件可以在 Kubernetes 上最佳化執行的工作負載集。

迄今為止，在擴充套件工作負載覆蓋範圍方面已取得顯著進展：

  • 有狀態應用程式，例如 Zookeeper、etcd、MySQL、Cassandra、ElasticSearch
  • 作業，例如處理當日日誌或任何其他批處理的定時事件
  • 透過 Alpha GPU 支援加速機器學習和計算密集型工作負載。總的來說，參與 Kubernetes 工作的人員正從客戶那裡聽到我們需要走得更遠。在 2014 年容器獲得了巨大的普及之後，業界圍繞著更現代的、基於容器的資料中心級工作負載編排器展開了討論，因為人們都在規劃他們的下一個架構。

因此，我們開始倡導擴大 Kubernetes 的工作負載範圍，從整體概念到具體功能。我們的目標是把控制權和選擇權交給使用者，幫助他們自信地走向他們選擇的任何基礎設施策略。在這種倡導中，我們很快發現了一大批志同道合的公司，他們對拓寬 Kubernetes 可以編排的工作負載型別感興趣。因此，工作組應運而生。

資源管理工作組的誕生

在 2016 年 Kubernetes 開發者峰會（在 CloudNativeCon | KubeCon Seattle 之後）期間進行了廣泛的開發/功能討論後，我們決定正式成立我們這個鬆散的組織。2017 年 1 月，Kubernetes 資源管理工作組成立。該小組（由 Red Hat 的 Derek Carr 和 Google 的 Vishnu Kannan 領導）最初被定位為一項臨時倡議，主要為 sig-node 和 sig-scheduling 提供指導。然而，由於工作組內部目標的交叉性以及快速發現的路線圖的深度，資源管理工作組在最初幾個月內成為了一個獨立的實體。

最近，Google 的 Brian Grant (@bgrant0607) 在他的 Twitter 動態上釋出了以下圖片。這張圖片有助於解釋每個 SIG 的作用，並展示了資源管理工作組在整個專案組織中的位置。

C_bDdiWUAAAcB2y.jpg{.big-img}

為了幫助啟動這項工作，資源管理工作組於 2017 年 5 月舉行了首次面對面啟動會議。感謝 Google 承辦！

20170502_100834.jpg

來自 Intel、NVIDIA、Google、IBM、Red Hat 和 Microsoft（以及其他公司）的人員參加了會議。
您可以在此處閱讀那次為期 3 天的會議的成果。

資源管理工作組的章程中列出的、旨在增加 Kubernetes 工作負載覆蓋範圍的優先功能列表包括：

  • 支援效能敏感型工作負載（獨佔核心、CPU 繫結策略、NUMA）
  • 整合新的硬體裝置（GPU、FPGA、Infiniband 等）
  • 改進資源隔離（本地儲存、大頁、快取等）
  • 提高服務質量 (效能 SLO)
  • 效能基準測試
  • 與上述功能相關的 API 和擴充套件。討論清楚地表明，各種工作負載的需求之間存在巨大的重疊，我們應該消除重複需求，並進行通用化處理。

工作負載特徵

最初目標的一組用例具有以下一個或多個特徵：

  • 確定性效能（解決長尾延遲）
  • 單個節點內以及共享控制平面的節點組內的隔離
  • 對高階硬體和/或軟體能力的要求
  • 可預測、可重現的放置：應用程式需要圍繞放置提供細粒度保證。資源管理工作組正在主導這些工作負載功能的設計和開發。我們的目標是為這些場景提供最佳實踐和模式。

初始範圍

在最近面對面會議之前的幾個月裡，我們討論瞭如何安全地抽象資源，以保持可移植性和簡潔的使用者體驗，同時仍能滿足應用程式需求。工作組最終制定了一個多版本路線圖，其中包括四個短期到中期目標，這些目標在目標工作負載之間有很大的重疊：

  • 裝置管理器（外掛）提案

    • Kubernetes 應提供對 NIC、GPU、FPGA、Infiniband 等硬體裝置的訪問。

  • CPU管理器

    • Kubernetes 應該提供一種方式，讓使用者透過 Guaranteed QoS 層請求靜態 CPU 分配。此階段不支援 NUMA。

  • Kubernetes 中的 HugePages 支援

    • Kubernetes 應該提供一種方式，讓使用者可以使用任意大小的巨頁。

  • 資源類別提案

    • Kubernetes 應該為 CPU 和記憶體以外的裝置實現一個抽象層（類似於 StorageClasses），允許使用者以可移植的方式使用資源。例如，Pod 如何請求具有最小記憶體量的 GPU？

參與和總結

我們的章程檔案包含一個聯絡我們部分，其中包含指向我們的郵件列表、Slack 頻道和 Zoom 會議的連結。以前會議的錄音已上傳到 Youtube。我們計劃在奧斯汀舉行的 CloudNativeCon | KubeCon 2017 Kubernetes 開發者峰會上討論這些主題以及更多內容。歡迎您參加我們的會議（使用者、客戶、軟體和硬體供應商都歡迎），併為工作組做出貢獻！