时间戳

首页 > 解决方案 > 应用程序网关如何防止将请求发送到最近终止的 pod？

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

问题描述

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

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

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

标签： azurekubernetesazure-aksazure-application-gateway

解决方案

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

当 pod 收到要终止的命令时，它不会立即发生。在 kube-proxies 将更新 iptables 以停止将流量引导到 pod 之后。也可能有入口控制器或负载平衡器将连接直接转发到 pod（应用程序网关就是这种情况）。完全解决这个问题是不可能的，而增加 5-10 秒的延迟可以显着提升用户体验。

如果您需要终止或缩减您的应用程序，您应该考虑以下步骤：

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

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

  • preStop 钩子- 在容器终止之前立即调用此钩子。这对于应用程序的正常关闭非常有帮助。例如，在 preStop 挂钩中带有“sleep 5”命令的简单 sh 命令可以防止用户看到“连接被拒绝错误”。pod 收到终止的 API 请求后，需要一些时间来更新 iptables 并让应用程序网关知道该 pod 已停止服务。由于 preStop 钩子在 SIGTERM 信号之前执行，这将有助于解决这个问题。（示例可以在附加生命周期事件中找到）

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

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

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

推荐阅读