GKE：502停止实例时

Question

我的Kubernetes进入GKE时遇到了麻烦。我通过手动删除（通过GCP仪表板）来模拟可抢占实例的终止。我正在运行区域GKE集群（us-west1中每个可用区域中的一个VM）。

在只有一个 VM上选择 delete 几秒钟后，我开始通过负载均衡器接收502错误。负载均衡器的堆栈驱动程序日志将错误列为failed_to_connect_to_backend。

监控后端服务的运行状况显示后端被终止从HEALTHY到UNHEALTHY然后消失，而其他两个后端仍为HEALTHY。

几秒钟后，请求再次开始成功。

我很困惑为什么负载均衡器无法在流量下降时将流量引导到健康节点 - 或者这可能是一个kubernetes问题？负载均衡器是否可以正确地将流量路由到正常的实例，但该实例上的kubernetes NodePort服务由于某种原因将请求代理回不正常的实例？

Answer 1

好吧，我想说如果你从GCP控制台中杀死一个节点，你就会从外面杀死它。在kubelet实现这个事件之前需要一些时间。所以kube-proxy也不会立即更新服务端点和iptables。

在此之前，入口控制器将继续向入口规则指定的服务以及不再存在的pod服务发送数据包。

这只是一种猜测。我可能错了。但是从GCP文档中，如果您使用的是可抢占的虚拟机，那么您的应用应该是容错的。

[EXTRA]

所以，让我们考虑两种一般情况。在第一个中，我们将发送kubectl delete pod命令，而在第二个中，我们将突然终止一个节点。

1. 与kubectl delete pod ...你说api-server你要杀死一个pod。 api-server将召唤kubelet杀死pod，它将在另一个节点上重新创建它（如果是这种情况）。 kube-proxy将更新iptables，以便服务将请求转发到正确的pod。
2. 如果你杀了节点，那就是首先意识到出错的kubelet，所以它会向api-server报告。 api-server将重新安排不同节点上的pod（总是）。其余的都一样。

我的观点是，api-server从一开始就知道没有数据包可以发送到pod，并且一旦kubelet意识到该节点不健康就会收到通知。

如何解决这个问题？你不能。实际上这应该是合乎逻辑的。您希望在可抢占的机器上获得相同的性能，成本大约便宜5倍，然后是普通的VM？如果可以的话，每个人都会使用这些虚拟机。

最后，如果您的应用程序具有容错能力，Google建议再次使用preemptible。