Node重新启动后，Kubernetes似乎不会更新内部IP表

Question

目前，我们正在使用GCP Kubernetes遇到问题，该问题将客户端请求转发到已分配了群集中其他POD的IPS的POD，以前 /以前 /获得。我们可以看到的方式是通过在Logs Explorer中使用以下查询：

resource.type="http_load_balancer"
httpRequest.requestMethod="GET"
httpRequest.status=404

摘要中的一个日志：

httpRequest: {
latency: "0.017669s"
referer: "https://asdf.com/"
remoteIp: "5.57.50.217"
requestMethod: "GET"
requestSize: "34"
requestUrl: "https://[asdf.com]/api/service2/[...]"
responseSize: "13"
serverIp: "10.19.160.16"
status: 404
userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
}

... requesturl属性属性指示了对负载平衡器的传入URL。

然后，我搜索IP 10.19.160.16以找出分配给IP的POD：

c:\>kubectl get pods -o wide | findstr 10.19.160.16
service1-675bfc4f97-slq6g    1/1   Terminated   0   40h     10.19.160.16   gke-namespace-te-namespace-te-153a9649-p2mg
service2-574d69cf69-c7knp    0/1   Error        0   3d16h   10.19.160.16   gke-namespace-te-namespace-te-153a9649-p2mg
service3-6db4c97784-428pq    1/1   Running      0   16h     10.19.160.16   gke-namespace-te-namespace-te-153a9649-p2mg

因此，基于requesturl该请求应已发送到Service2。取而代之的是，我们看到的是它已发送到Service3，因为它已经获得了Service2 曾经曾经拥有的IP，换句话说，群集似乎仍然认为Service2坚持IP 10.19 .160.16。效果是Service3返回状态代码404，因为它无法识别端点。

仅当我们使用kubectl delete pod ...命令中，我们以失败状态（例如错误或终止）手动删除POD时，此行为才会停止。

我们怀疑这种行为是自从我们将群集升级到v1.23以来就开始的，这要求我们从extensions/v1beta1 networking.k8s.io/v1如图所述。 https://cloud.google.com/kuberle.com/kubernetes-engengine/文档/折旧/apis-1-22 。

我们的测试环境是使用可预取的VM，尽管我们不是100％（但很接近）肯定的是，在节点被抢占后，Pods似乎以错误状态结束。

为什么群集仍然认为死舱仍然具有过去的IP？为什么删除失败的豆荚后出现问题？节点预先抢占后，不应该清理它们吗？

Answer 1

加里·辛格（Gari Singh）在评论中提供了答案。