本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

介绍资源管理工作组

作者：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
  • 作业，例如处理当天日志的定时事件或任何其他批处理
  • 通过 Alpha GPU 支持实现的机器学习和计算密集型工作负载加速 总的来说，Kubernetes 的工作人员从他们的客户那里听到，我们需要进一步努力。在 2014 年容器大受欢迎之后，行业言论围绕着一个更现代的、基于容器的、数据中心级的工作负载编排器展开，因为人们希望计划他们的下一个架构。

因此，我们开始提倡增加 Kubernetes 覆盖的工作负载范围，从总体概念到具体功能。我们的目标是将控制权和选择权掌握在用户手中，帮助他们充满信心地朝着他们选择的任何基础设施策略前进。在这种倡导中，我们很快找到了一大群志同道合的公司，他们有兴趣扩大 Kubernetes 可以编排的工作负载类型。因此，工作组应运而生。

资源管理工作组的起源

在 Kubernetes 开发者峰会 2016 期间，在 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 和扩展 讨论清楚地表明，各种工作负载的需求之间存在巨大的重叠，我们应该消除重复的需求，并进行通用规划。

工作负载特征

最初目标用例集具有以下一个或多个特征

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

初始范围

在最近面对面会议之前的几个月中，我们讨论了如何以保留可移植性和简洁用户体验的方式安全地抽象资源，同时仍满足应用程序的要求。工作组制定了一个多版本 路线图，其中包括 4 个短期到中期目标，这些目标在目标工作负载之间有很大的重叠

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

    • 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 开发者峰会上讨论这些主题以及更多内容。请参加我们的会议之一（欢迎用户、客户、软件和硬件供应商）并为工作组做出贡献！