需要添加什么？
我们是否可以获得一种技术，将有序的、可控的“完全集群关闭”和“受控启动”集成到Kubernetes中？
背景 - 关闭：
有时我们需要关闭数据中心，例如进行维护。如果我们有一个位于单个数据中心中的单一集群，并且在其上有一些工作负载，我们需要在能够排空并关闭给定的kubernetes集群中的所有工作负载(scale to replicas = 0)之前控制工作负载的关闭。
在此过程中，我们不希望删除整个集群，因为重新部署集群和工作负载将产生大量的流量和负载。
背景 - 启动：
当我们启动集群及其节点时，一旦集群中有特定数量的工作负载恢复活跃，工作负载需要重新调度(scale to replicas >0),理想情况下恢复到与“关闭前”相同的副本数量。因此，我们需要对“扩展”应该等待多长时间才能让工作负载开始以避免不平衡 - 并在启动/开机期间需要重新平衡。
我理解我们基本上永远不希望关闭整个集群，但有时/由于平台的物理维护或维护 - 它仍然可能需要...此外，物理迁移也需要这个。
想法是某种自动化/基于控制器的过程，它可以在关闭时将所有内容缩放到0,同时记住“关闭前”的规模 - 并在开机时将其恢复到以前的状态，但与等待一组工作负载和/或等待某种超时有关。
为什么需要这个？
物理维护需求 - 需要完全机架...完全数据中心断电的维护需求。
2条答案
按热度按时间pn9klfpd1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题，他们将通过应用
triage/accepted标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted来添加triage/accepted标签。有关使用PR评论与我互动的说明，请查看here。如果您对我的行为有任何问题或建议，请针对kubernetes-sigs/prow仓库提出一个问题。
z4bn682m2#
我明白我们基本上永远不希望关闭整个集群，但有时由于物理维护或平台维护，可能仍然需要这样做。此外，物理重新定位也需要这个功能。
是的，因为这与用户的需求相反 - 即他们不希望引入工作负载停机时间。
您请求的功能似乎不适合核心k8s,而且我认为从技术上也不可能实现。
相反，我建议您关闭此问题单，并开始关注像kOps、kubespray和cluster-api这样的项目，它们可能会接受这种编排式关闭的想法/功能请求。
/sig架构
(标记为sig-arch,因为这是记录为核心请求的问题)