我通过手动删除（通过GCP仪表板）来模拟可抢占实例的终止 . 我正在运行区域GKE集群（ us-west1 中每个可用区域中的一个VM） .
在 only one 的VM上选择删除后几秒钟，我开始通过负载均衡器接收502错误 . 负载均衡器的堆栈驱动程序日志将错误列为 failed_to_connect_to_backend .
监视后端服务的运行状况显示后端被终止从 HEALTHY 到 UNHEALTHY 然后消失，而其他两个后端仍然是 HEALTHY .
几秒钟后，请求再次开始成功 .
我很困惑为什么负载均衡器无法在流量下降时将流量引导到 Health 节点 - 或者这可能是一个kubernetes问题？负载均衡器是否可以正确地将流量路由到正常的实例，但该实例上的kubernetes NodePort 服务由于某种原因将请求代理回不正常的实例？
1 回答
好吧，我想说如果你从GCP控制台中杀死一个节点，你就可以从外面杀死它了 . 在kubelet实现这个事件之前需要一些时间 . 所以kube-proxy也不会立即更新服务 endpoints 和iptables .
在此之前，入口控制器将继续将数据包发送到入口规则指定的服务，以及不再存在的服务 .
这只是一种猜测 . 我可能错了 . 但是从GCP文档中，如果您使用的是可抢占的虚拟机，那么您的应用应该是容错的 .
[额外]
那么，让我们考虑两种一般情况 . 在第一个中，我们将发送
kubectl delete pod命令，而在第二个中，我们将突然终止一个节点 .与
kubectl delete pod ...你说api-server你要杀死一个pod . api-server将召唤kubelet杀死pod，它将在另一个节点上重新创建它（如果是这种情况） . kube-proxy将更新iptables，以便服务将请求转发到正确的pod .如果你杀死了节点，那就是首先意识到出现问题的kubelet，所以它会向api-server报告 . api-server将重新安排不同节点上的pod（总是） . 其余的都是一样的 .
我的观点是，api-server从一开始就知道没有数据包可以发送到pod，并且一旦kubelet意识到该节点不 Health 就会收到通知 .
怎么解决这个？你不能 . 实际上这应该是合乎逻辑的 . 您希望与可抢占的机器具有相同的性能，成本大约便宜5倍，然后是普通的VM？如果可以，那么每个人都将使用这些虚拟机 .
最后，如果您的应用程序具有容错能力，Google建议再次使用preemptible .