需要添加什么？
- 介绍：我了解了KEP,但我只是一名热爱Kubernetes的忙碌工程师。我不确定我能否通过KEP流程领导我的功能请求。请将此视为我的初步联系，如果有任何事情可以让我的声音被听到并向社区提出我的想法。如果有足够的支持，我可以跟进或者有人可以领导它。*
我想提议对Kubernetes中的DaemonSet(DS)资源管理进行增强。DaemonSet作为一种宝贵的功能，确保集群中每个节点运行特定pod的副本。然而，我已经确定了一个功能可以显著改进的领域：基于节点类型的动态和可扩展资源分配。
当前限制：静态资源定义
目前，DaemonSet的资源分配逻辑相当静态。当为DaemonSet定义资源(如CPU和内存)时，它以“要么全部要么没有”的方式运作。这种方法没有充分利用多样化的节点环境潜力。
当前生态系统中的多样化节点环境
在当前云生态系统中，有各种各样的节点类型可供选择。这些从只有1个虚拟CPU的节点到像AWS这样的服务提供的488个CPU的节点不等。这种节点能力的多样性目前尚未在DaemonSet设计中得到考虑。
工作负载资源依赖于节点大小和Pod密度
DaemonSet的工作负载资源(特别是内存和CPU)通常取决于节点上运行的pod数量。更重要的是，它们还可以取决于节点本身的大小或容量。例如，具有更多CPU和内存的节点可以，也应该能够处理更密集的工作负载。
缺乏原生方法进行动态资源分配
到目前为止，Kubernetes没有提供原生方法来根据节点的大小或容量为DaemonSet定义资源。虽然可以将节点按大小分类，但这种解决方案很繁琐且静态。它需要大量的手动干预，并且不会随着集群的发展而动态调整。
现有的替代方案
我承认存在一些管理这一挑战的方法，例如将节点添加到不同的节点组，然后使用亲和性规则将具有不同资源要求的DaemonSet放置在一起。然而，这种方法相当繁琐且复杂。它需要大量的手动配置和持续调整，这会降低可用性和效率。这种方法并不真正满足Kubernetes环境中资源需求的动态性质。
建议：为DaemonSet动态/可扩展资源分配
我建议引入一种功能，允许DaemonSet根据节点类型或容量动态分配资源。该功能将分析节点的特征(如CPU和内存容量以及它可以容纳的最大pod数),并自动为在该节点上运行DaemonSet的pod定义分配的资源。
这种动态分配将确保更有效地利用集群资源，提高性能，并通过最大化每个节点容量的使用来可能降低成本。它还将显著减少Kubernetes管理员的管理负担，因为系统将自动适应节点景观的变化。
总之，将基于节点类型的动态和可扩展资源分配引入DaemonSet将是Kubernetes功能的显著改进。它将增强DaemonSet对多样化和不断发展的节点环境的适应性，导致更高效的资源使用和简化的集群管理。
9条答案
按热度按时间dfuffjeb1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题，他们将通过应用
triage/accepted标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted来添加triage/accepted标签。有关使用PR评论与我互动的说明，请查看here。如果您对我的行为有任何问题或建议，请针对kubernetes/test-infra仓库提出一个问题。
pxy2qtax2#
/sig node
w6mmgewl3#
/remove-sig node
/sig apps
lnvxswe24#
这个主题并不新鲜，但确实很难。我们已经讨论了一个
DaemonSetSet类型，它可以使用标签在N个DaemonSet配置之间进行选择。我们还讨论了如何将资源百分比用于申请节点的x%资源。这个设计非常不明确，但我想添加一些颜色。我现在不会去寻找重复的问题，但如果这不是一个重复的问题，我会感到很惊讶：)
n1bvdmb65#
这个主题并不新鲜，但却很难。我们已经讨论了一个
DaemonSetSet类型的方案，它可以使用标签在 N 个DaemonSet配置之间进行选择。我们还讨论了如何将资源百分比用于占用节点的 x% 。这个设计非常不明确，但我想补充一些颜色。我现在不会去寻找答案，但如果这不是一个重复的问题，我会感到很惊讶。我进行了一些搜索，并记得在论坛上看到过你的一个回答。不过，我还没有看到一个更正式的要求。
你建议我从 KEP 开始吗？我可以在我们公司内部创建一些优先级(时间),引导这个提议/改进成为一个真正的建议/改进。
8i9zcol26#
在投入完整的 KEP 之前，我会先进行一个 "pre-KEP",作为一个简单的 GoogleDoc 或者类似的东西来收集选项并获取关于权衡的反馈，无论是对于实现选项(例如内置 vs. CRD)还是整体模型(例如 DaemonSetSet 或百分比等)。
我怀疑这是 sig-apps 拥有的，所以也许在那里征求一些早期反馈。
我认为这是一种对如此重要提案最具迭代性的方法 :)
amrnrhlw7#
想要提出一些随机的想法，因为我们不仅在daemonsets上遇到了类似的问题，还在sidecars上遇到了类似的问题。我认为从根本上说，我们试图解决将容器的资源需求Map到某种用户可配置的选择器的问题。
VPA在一定程度上做到了这一点，它理解pod级别的每个容器的利用率。然而，它强制目标必须在整个daemonset/部署等上，这不是我们想要的。此外，我们希望VPA能够在pod启动时接管资源需求。
跟随VPA的脚步。如果我们可以引入一个与VPA类似的新CRD,或者从VPA接管对这个CRD的资源需求委托，让用户通过选择器和资源需求指定目标，这可能是理想的解决方案吗？
vql8enpb8#
Kubernetes项目目前缺乏足够的贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理：
lifecycle/stale应用后的90天内无活动，将应用lifecycle/stalelifecycle/stale应用后的30天内无活动，将应用lifecycle/rottenlifecycle/rotten应用后的30天内无活动，将关闭该问题您可以：
/remove-lifecycle stale标记此问题为新鲜/close关闭此问题请将反馈发送至sig-contributor-experience@kubernetes/community。
/lifecycle stale
unftdfkk9#
我们在将更多多样性引入我们的Node集群组成后，偶然发现了这个认识。我认为可以通过一些非传统的解决方法来复制DaemonSet资源并使用nodeSelectors或taints进行管理，但这会带来很大的负担。一些基本的扩展机制可以在这里提供高利润价值。