本文已超过一年。旧文章可能包含过时内容。请检查页面信息自发布以来是否已失效。

介绍资源管理工作组

作者：Jeremy Eder (Red Hat) |

我们为何在此？

Kubernetes 已演进到支持多样且日益复杂的应用类别。我们可以快速引入并扩展基于微服务、批处理作业以及具有持久存储需求的状态应用等现代云原生 Web 应用。

然而，Kubernetes 仍有改进空间；例如，支持需要专用硬件的工作负载，或在考虑硬件拓扑时性能显著提升的工作负载。这些冲突可能会使得某些应用类别（尤其是在成熟的垂直领域）难以采用 Kubernetes。

我们在此看到了前所未有的机会，如果错失，代价将很高。Kubernetes 生态系统必须通过有意义地满足尚未得到支持的工作负载的需求，创建一条通向下一代系统架构的可行之路。资源管理工作组与其他 SIG 一起，必须展示客户期望看到的愿景，同时确保解决方案在完全集成、精心规划的端到端堆栈中良好运行。
 
当某个特定挑战需要跨 SIG 协作时，就会创建 Kubernetes 工作组。例如，资源管理工作组主要与 sig-node 和 sig-scheduling 合作，推动 Kubernetes 中更多资源管理功能的支持。我们确保经常咨询来自不同 SIG 的关键贡献者，因为工作组不是为了代表任何 SIG 做出系统级决策。
 
一个例子和主要好处是工作组与 sig-node 的关系。 我们能够在考虑其上的功能设计之前，确保完成几个版本的节点可靠性工作（在 1.6 版本完成）。这些设计都是用例驱动的：研究各种工作负载的技术需求，然后根据对最大范围的影响进行排序。

目标工作负载和用例

工作组的关键设计原则之一是用户体验必须保持简洁和可移植性，同时仍然暴露业务和应用所需的基础设施能力。
 
虽然不代表任何承诺，但我们希望在未来某个时候，Kubernetes 能够最优地运行金融服务工作负载、机器学习/训练、网格调度器、map-reduce、动画工作负载等等。作为一个用例驱动的团队，我们考虑了潜在的应用集成，这也可以促进围绕 Kubernetes 形成一个繁荣的互补独立软件供应商生态系统。

venn-kubernetes.png

为何这样做？

Kubernetes 已经很好地涵盖了通用 Web 托管功能，那么为什么要费力扩展 Kubernetes 的工作负载覆盖范围呢？事实是，今天 Kubernetes 优雅地覆盖的工作负载仅占全球计算用量的一小部分。我们有一个巨大的机会，可以安全地、有条不紊地扩展可以在 Kubernetes 上最优运行的工作负载集合。

迄今为止，在扩展工作负载覆盖范围方面已取得显著进展

  • 有状态应用，例如 Zookeeper、etcd、MySQL、Cassandra、ElasticSearch
  • 作业（Jobs），例如定时处理日志或任何其他批处理
  • 机器学习和计算密集型工作负载加速（通过 Alpha GPU 支持）总的来说，参与 Kubernetes 工作的人员从客户那里听到，我们需要做得更多。继容器在 2014 年大受欢迎之后，行业讨论开始围绕更现代、基于容器的数据中心级工作负载编排器展开，人们也开始规划他们的下一代架构。

因此，我们开始倡导增加 Kubernetes 覆盖的工作负载范围，从整体概念到特定功能。我们的目标是将控制权和选择权交给用户，帮助他们满怀信心地走向他们选择的任何基础设施策略。在此倡导过程中，我们很快发现了一大批志同道合的公司，他们有兴趣拓宽 Kubernetes 可以编排的工作负载类型。于是，工作组应运而生。

资源管理工作组的起源

在 CloudNativeCon | KubeCon 西雅图 之后的 2016 年 Kubernetes 开发者峰会上进行广泛的开发/功能讨论后，我们决定将我们松散的组织正式化。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 等公司的人员参与了会议。 
您可以在此处阅读该三天会议的成果。

资源管理工作组的章程中列出了该工作组增加 Kubernetes 工作负载覆盖范围的优先功能列表，包括

  • 支持性能敏感型工作负载（独占核心、CPU 绑定策略、NUMA）
  • 集成新硬件设备（GPU、FPGA、Infiniband 等）
  • 改进资源隔离（本地存储、大页内存、缓存等）
  • 提高服务质量 (性能 SLO)
  • 性能基准测试
  • 与上述功能相关的 API 和扩展。讨论明确指出，各种工作负载的需求之间存在巨大重叠，我们应该去除重复的需求，并进行通用实现。

工作负载特性

最初锁定的用例集具有以下一个或多个特征

  • 确定性性能（解决长尾延迟）
  • 在单个节点内以及共享控制平面的节点组内的隔离
  • 对先进硬件和/或软件能力的要求
  • 可预测、可重现的放置：应用需要对放置有细粒度保证 资源管理工作组正在牵头这些工作负载需求的功能设计和开发。我们的目标是为这些场景提供最佳实践和模式。

初始范围

在我们最近面对面会议之前的几个月里，我们讨论了如何以一种既能保持可移植性和良好的用户体验，又能满足应用需求的方式安全地抽象资源。工作组制定了一个包含多个版本的路线图，其中包含 4 个短期到中期目标，这些目标与目标工作负载之间有很大的重叠。

  • 设备管理器（插件）提案

    • Kubernetes 应提供对 NIC、GPU、FPGA、Infiniband 等硬件设备的访问。

  • CPU Manager

    • Kubernetes 应提供一种方式，让用户通过 Guaranteed QoS 层请求静态 CPU 分配。此阶段不支持 NUMA。

  • Kubernetes 中的 HugePages 支持

    • Kubernetes 应提供一种方式，让用户可以使用任意大小的大页内存。

  • 资源类提案

    • Kubernetes 应为 CPU 和内存以外的设备实现一个抽象层（类似于 StorageClass），允许用户以可移植的方式使用资源。例如，一个 Pod 如何请求具有最小内存量的 GPU？

如何参与和总结

我们的章程文档包含一个联系我们部分，其中包含指向我们的邮件列表、Slack 频道和 Zoom 会议的链接。之前会议的录像已上传到 Youtube。我们计划在奥斯汀举行的 CloudNativeCon | KubeCon 2017 年 Kubernetes 开发者峰会上讨论这些话题以及更多内容。欢迎大家参加我们的会议（用户、客户、软硬件供应商都欢迎）并为工作组做出贡献！