Kubernetes吊舱在内存不足的情况下传输

我试图找到一种优雅的方法来解决以下情况

我们有一个ASW Kubernetes集群，每个集群有6个16G RAM节点， 集群具有不同的POD，其资源需求在1G到6G的最小请求内存之间

有一种情况是，由于内存不足，导致pod挂起。 当我们需要升级一些具有不同内存需求的pod时，就会发生这种情况。具有6G的pod处于挂起状态，因为没有节点具有6G可用

我期望Kubernetes在节点之间重新排列POD，以便在特定节点上释放6G，而不是在两个diff notes上保持5G空闲（总共10G），并返回内存不足

有没有办法指导库伯内特夫妇更好地初始化内存并自动处理

我在考虑吊舱的优先权。内存请求越少，优先级越低。想知道基于此设置，Kubernetes是否能够在部署较大的pod后重新启动不太重要的（较小的）pod，从而在节点之间重新排列它们

---

默认情况下，Kubernetes调度程序不会杀死任何容器来容纳较新的容器。这是因为如果它这样做，运行的容器可能会被迫在其他节点上重新调度，这是不可取的。Kubernetes将尊重集群的当前状态，并努力保持稳定的环境

---

对于这个问题，您可以做的是，当您部署6G RAM应用程序时，您可以部署它，然后删除1G RAM请求POD，这样Kubernetes调度程序可以首先在可用节点上部署更大的应用程序，然后将其他POD部署到其他节点。这也是Kubernetes scheduler的默认操作，总是尝试先放置较大的工件，这样也可以将较小的工件放置得更好。

没有银弹解决方案，但您可以使用和执行一些组合操作。这还取决于您的工作负载优先级

如果有6个节点，则可以有如下内容：

名称状态角色年龄版本标签
节点1就绪4m26s v1.16.0节点=节点1，类型=重型
节点2就绪3m58s v1.16.0节点=节点2，类型=重型
节点3就绪3m17s v1.16.0节点=节点3，类型=重型
节点4就绪2m43s v1.16.0节点=节点4，类型=灯光
节点5就绪3m17s v1.16.0节点=节点5，类型=灯
节点6就绪2m43s v1.16.0节点=节点6，类型=灯

然后在您的6G Pod规范中，它将根据具有PodAffinity的重Pod在节点1-node6上调度，在重节点上倾斜3

种类：吊舱
版本：v1
元数据：
姓名：mypod
标签：
工作量：繁重
规格：
地形预约束：
-maxSkew:3
拓扑基：类型
不满意时：不要安排
标签选择器：
火柴标签：
工作量：繁重
密切关系：
podAffinity：
所需DuringSchedulingIgnoredDuringExecution：
-标签选择器：
匹配表达式：
-关键：工作量
接线员：在
价值观：
-沉重的
拓扑基：类型
容器：
-姓名：myheavyapp
图片：myapp:最新
...

然后，您可以使用NodeAffinity仅在light节点上调度light 1G吊舱

种类：吊舱
版本：v1
元数据：
名称：mylightpod
标签：
工作量：轻
规格：
密切关系：
节点相关性：
所需DuringSchedulingIgnoredDuringExecution：
nodeSelectorTerms：
-匹配表达式：
-关键字：类型
接线员：在
价值观：
-轻的
...

这只是一个例子，您可以更改标签，并使其倾斜以适应您的任何用例

---

此外，为了防止停机，您可以配置一个

谢谢您的回复，这就是我到目前为止所做的，我只是想知道我是否可以使用纯Kubernetes解决方案，而不是编写脚本，重新启动最小的pod，考虑是否存在内存不足的情况。您可以重新实现Kubernetes调度程序，然后使用自定义调度程序，但这将是比您可能需要的更复杂的解决方案。谢谢Rico，让我试试，这似乎是我一直在寻找的，我发现没有标准的方法来管理这样的用例，但是建议的组合似乎是合理的。