azure - 应用程序网关如何防止请求发送到最近终止的 Pod？

Question

我目前正在 Azure 中研究和试验 Kubernetes。我正在使用 AKS 和应用程序网关入口。据我了解，当 Pod 添加到服务时，端点会更新，入口 Controller 会不断轮询此信息。随着新端点的添加，AG 也会更新。当它们被删除时，AG 也会更新。

添加 pod 时，在 pod 收到请求之前将其添加到 AG 时，会有一个小的延迟。但是，当 Pod 被删除时，更新延迟是否会导致请求被转发到不再存在的 Pod？

如果不是，AG/K8S如何保证这一点？在这种情况下，最终客户端可能会遇到什么行为？

Answer 1

Azure 应用程序网关入口是用于 kubernetes 部署的入口 Controller ，它允许您使用 native Azure 应用程序网关将应用程序公开到 Internet。其目的是将流量直接路由到 Pod。与此同时，有关 pod 可用性、调度和一般管理的所有问题都在 kubernetes 本身上。

当 Pod 收到终止命令时，它不会立即发生。之后 kube-proxies 将更新 iptables 以停止将流量引导至 pod。此外，可能还有入口 Controller 或负载均衡器将连接直接转发到 Pod(应用程序网关就是这种情况)。这个问题不可能完全解决，但增加5-10秒的延迟可以显着改善用户体验。

如果您需要终止或缩小应用程序规模，您应考虑以下步骤:

• 等待几秒钟，然后停止接受连接
• 不在请求过程中关闭所有保持事件的连接
• 等待所有事件请求完成
• 完全关闭应用程序

以下是准确的 kubernetes 机制，可以帮助您解决问题:

• preStop Hook - 在容器终止之前立即调用此 Hook 。这对于应用程序的正常关闭非常有帮助。例如，在 preStop Hook 中使用简单的 sh 命令和“sleep 5”命令可以防止用户看到“连接被拒绝错误”。 Pod 收到要终止的 API 请求后，需要一些时间来更新 iptables 并让应用程序网关知道该 Pod 已停止服务。由于 preStop 钩子(Hook)是在 SIGTERM 信号之前执行的，因此它将有助于解决此问题。(示例可以在 attach lifecycle event 中找到)

• 就绪探针 - 这种类型的探针始终在容器上运行，并定义 pod 是否准备好接受和服务请求。当容器的就绪探针返回成功时，这意味着容器可以处理请求并将其添加到端点。如果就绪性探测失败，Pod 将无法处理请求，并且将从端点对象中删除。当应用程序需要一些时间来加载时，它非常适合新创建的 Pod；如果应用程序需要一些时间来处理，它也适用于已经运行的 Pod。在从端点删除之前，就绪性探测应该失败几次。可以使用 failureTreshold 字段将此数量降低到仅一次失败，但它仍然需要检测一次失败的检查。(有关如何设置的更多信息可以在 configure liveness readiness startup probes 中找到)

• 启动探测 - 对于某些在首次初始化时需要额外时间的应用程序，正确设置就绪探测参数并且不影响应用程序的快速响应可能很棘手。使用 failureThreshold * periodSeconds 字段将提供这种灵 active 。

• terminationGracePeriod - 如果应用程序需要超过默认 30 秒的延迟才能正常关闭(例如，这对于有状态应用程序很重要)，也可以考虑