GCE上的Kubernetes / Prevent Pod遭到驱逐,原因是“该节点的计算资源不足。”

Ben

对迄今为止尚未在文档中强调的方面进行痛苦的调查(至少从我搜索过的内容来看)

我的集群的kube-proxy被逐出了(有经验的用户也许可以考虑面临的问题)。搜索了很多,但是没有任何关于如何重新设置它们的线索。

在描述有关的Pod之前,有一个明确的原因:“该节点的计算资源不足。”

仍然没有在吊舱/部署和“物理”计算之间实现资源平衡的经验,如何“优先化”(或类似方法)以确保特定吊舱永远不会处于这种状态?

创建集群时使用的资源非常少,以便在保持低成本的同时动手操作并最终看到此类问题(gcloud container clusters create deemx --machine-type g1-small --enable-autoscaling --min-nodes=1 --max-nodes=5 --disk-size=30),使用g1-small是否禁止?

埃里克·图恩(Eric Tune)

如果您使用的是基于iptables的kube-proxy(当前的最佳实践),那么被杀死的kube-proxy不会立即导致您的网络连接失败,但是新服务和对端点的更新将停止工作。尽管如此,您的应用仍应继续运行,但降级速度慢。如果您正在使用用户空间kube-proxy,则可能要升级。

错误消息听起来像是由于机器上的内存压力引起的。

当存在内存压力时,Kubelet尝试按最低到最高QoS级别的顺序终止操作

如果您的kube-proxy窗格未使用保证资源,则可能需要更改它。

其他要看的东西:

  • 如果kube-proxy突然使用了更多的内存,则可以终止该内存。如果您创建了大量的Pod,服务或端点,则可能会导致它使用更多的内存。
  • 如果您在不受kubernetes控制的机器上启动了进程,则可能导致kubelet对终止内容做出错误的决定。避免这种情况。
  • 在g1-small这样的小型机器上,保留的节点资源数量可能不足,从而导致机器上的保证工作量过多-请参阅可分配容量与容量这可能需要调整。
  • 节点叔叔文档

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章

TOP 榜单

热门标签

归档