GCE 上的 Kubernetes / 防止 pod 因“节点计算资源不足”而被驱逐。

Question

对文档中没有强调的方面进行了痛苦的调查（至少从我用谷歌搜索的内容来看）

我的集群的 kube-proxy 被驱逐（+-有经验的用户可能会考虑面临的问题）。搜索了很多，但没有关于如何重新启动它们的线索。

直到描述相关的 pod 给出了明确的原因：“该节点的计算资源不足。”

在 Pod/部署和“物理”计算之间的资源平衡方面仍然没有经验，如何“确定优先级”（或类似方法）以确保特定 Pod 永远不会处于这种状态？

集群是用相当低的资源创建的，以便在保持低成本并最终见证此类问题的同时让我们动手（gcloud container clusters create deemx --machine-type g1-small --enable-autoscaling --min-nodes=1 --max-nodes=5 --disk-size=30），使用 g1-small 是否禁止？

Answer 1

如果您使用的是基于 iptables 的 kube-proxy（当前最佳实践），那么 kube-proxy 被终止不应立即导致您的网络连接失败，但新服务和端点更新将停止工作。尽管如此，您的应用程序应该可以继续工作，但会缓慢降级。 如果您使用的是用户空间 kube-proxy，则可能需要升级。

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

当存在内存压力时，Kubelet 会尝试按照从低到高的顺序终止事物 QoS level。

如果您的 kube-proxy pod 没有使用 Guaranteed 资源，那么您可能需要更改它。

其他看点：

• 如果 kube-proxy 突然使用了更多内存，它可能会被终止。如果您创建了大量的 pod、服务或端点，这可能会导致它使用更多内存。
• 如果您在机器上启动了不受 kubernetes 控制的进程，这可能会导致 kubelet 做出关于终止什么的错误决定。避免这种情况。
• 可能在像 g1-small 这样的小型机器上，保留的节点资源量不足，以至于机器上放置了太多有保证的工作 -- 参见allocatable vs capacity。这可能需要调整。
• Node oom documentation