使用 externalTrafficPolicy: Local 在 GKE 上是否可以实现无中断滚动更新？

我有一个 GKE 集群 (1.12.10-gke.17)。

我正在运行nginx 入口控制器 https://github.com/kubernetes/ingress-nginx with type: LoadBalancer.

我已经设置了externalTrafficPolicy: Local to 保留源ip https://kubernetes.io/docs/tutorials/services/source-ip/#source-ip-for-services-with-type-loadbalancer.

除了滚动更新期间之外，一切都运行良好。我有maxSurge: 1 and maxUnavailable: 0.

我的问题是，在滚动更新期间，我开始收到请求超时。我怀疑 Google 负载均衡器仍在向 pod 所在的节点发送请求Terminating即使健康检查失败。当 pod 从 pod 更改时开始，这种情况会持续大约 30-60 秒Running to Terminating。一段时间后一切都会稳定下来，流量最终只会流向带有新 Pod 的新节点。

如果负载均衡器is停止向终止 pod 发送请求的速度很慢，是否有某种方法可以使这些滚动部署无中断？

我的理解是，在一个normalk8s服务，哪里externalTrafficPolicy这是不正常的，Google 负载均衡器只是将请求发送到所有节点，然后让 iptables 进行排序。当 pod 处于Terminatingiptables 更新很快，流量不再发送到该 Pod。在这种情况下externalTrafficPolicy is Local但是，如果接收请求的节点没有Runningpod，然后请求超时，这就是这里发生的情况。

如果这是正确的，那么我只看到两个选项

1. 停止向节点发送请求Terminating pod
2. 即使 pod 已关闭，仍继续服务请求Terminating

我觉得选项 1 很困难，因为它需要通知负载均衡器 pod 即将启动Terminating.

我在选项 2 上取得了一些进展，但到目前为止还没有发挥作用。我已成功通过添加一个来继续处理来自 pod 的请求preStop刚刚运行的生命周期钩子sleep 60，但我认为问题在于healthCheckNodePort报告localEndpoints: 0我怀疑有东西阻止了到达节点和到达 Pod 之间的请求。也许，iptables 没有路由localEndpoints: 0.

我还调整了Google负载均衡器健康检查，这与readinessProbe and livenessProbe，到可能的“最快”设置，例如1 秒间隔，1 个故障阈值，我已经验证了负载均衡器后端（又名 k8s 节点）确实很快就失败了运行状况检查，但仍然继续向终止 pod 发送请求。

有一个类似的讨论here https://stackoverflow.com/questions/58751354/testing-graceful-shutdown-on-an-http-server-during-a-kubernetes-rollout/58752566#58752566。虽然不完全相同，但它是一个相似的用例。

一切听起来都按预期进行。

• LoadBalancer将根据LoadBalancer健康检查将流量发送到任何健康的节点。 LoadBalancer 不知道各个 Pod。

• 一旦超过健康检查阈值，健康检查就会将节点标记为不健康，即每 x 秒发送一次 HC，超时延迟为 x，失败请求数为 x。这会导致 pod 进入终止状态和被标记为不健康状态之间存在延迟。

• 另请注意，一旦 pod 被标记为 notReady，该 pod 就会从服务端点中删除。如果节点上没有其他 Pod，流量将继续到达该节点（由于上面解释的 HC 行为），由于 externalTrafficPolicy（流量保留在发送的节点上），请求无法转发。

有几种方法可以解决这个问题。

1. 为了最大限度地缩短 pod 终止和节点被标记为不健康之间的时间间隔，您可以设置更积极的运行状况检查。这样做的问题是，过于敏感的 HC 可能会导致误报，通常会增加节点的开销（额外的健康检查请求），并且不会完全消除失败的请求。

2. 有足够的 Pod 运行，以便每个节点始终至少有 2 个 Pod。由于一旦 pod 进入 notReady 状态，服务就会将其从端点中删除，因此请求只会发送到正在运行的 pod。这里的缺点是，您要么会产生额外的开销（更多的 Pod），要么会出现更紧密的分组（更容易出现故障）。它也不会完全消除失败的请求，但它们会非常少。

3. 调整 HC 和容器以协同工作： 3a.将 HC 端点与您使用的正常路径分开。 3b.配置容器readinessProbe匹配容器提供流量的主路径（它将与 LB HC 路径不同） 3c.配置您的图像，以便当SIGTERM收到后，首先走的是HC路径。 3d.配置镜像以优雅地耗尽所有连接一次SIGTERM收到而不是立即关闭所有会话和连接。

这应该意味着正在进行的会话将正常终止，从而减少错误。 这还意味着节点将开始失败 HC 探测，即使它已准备好提供正常流量，这为节点被标记为不健康提供了时间，并且 LB 将在不再能够提供服务之前停止向其发送流量要求。

最后一个选项的问题有两个。首先，配置比较复杂。另一个问题是，这意味着您的 Pod 将需要更长的时间才能终止，因此滚动更新将需要更长的时间，任何其他依赖于优雅终止 Pod 的进程（例如耗尽节点）也会花费更长的时间。第二个问题还不错，除非您需要快速扭转局面。