迄今为止对文档突出显示的方面进行了痛苦的调查（至少从我用Google搜索过的内容）
我的群集的kube-proxy被驱逐（+经验丰富的用户可能会考虑面临的问题）。搜索了很多，但没有关于如何再次使用它们的线索。
在描述相关的pod之前有一个明确的理由：“节点的计算资源很少。”
在pods / deployments和“物理”计算之间的资源平衡方面仍然没有经验，如何确定（或类似的方法）以确保特定的pod永远不会在这种状态下结束？
集群创建时资源相当少，以便在保持低成本的同时亲自动手并最终目睹这些问题（gcloud container clusters create deemx --machine-type g1-small --enable-autoscaling --min-nodes=1 --max-nodes=5 --disk-size=30），使用g1-small是禁止的？
答案 0 :(得分：2)
如果您正在使用基于iptables的kube-proxy（当前的最佳实践），那么被杀死的kube-proxy不应该立即导致您的网络连接失败，但新服务和对端点的更新将停止工作。不过，您的应用仍应继续运行，但会慢慢降级。 如果您使用的是userspace kube-proxy，则可能需要升级。
错误消息听起来像是由于机器上的内存压力造成的。
当存在内存压力时，Kubelet会尝试按从最低到最高QoS level的顺序终止事件。
如果你的kube-proxy pod没有使用保证资源，那么你可能想要改变它。
其他要注意的事项：