应用程序网关如何防止将请求发送到最近终止的Pod？ [英] How does Application Gateway prevent requests being sent to recently terminated pods?
问题描述
我目前正在研究和试验Azure中的Kubernetes。我正在玩AKS和应用程序网关入口。据我所知，当将Pod添加到服务中时，端点会更新，入口控制器会不断轮询此信息。随着新端点的添加，AG也会更新。删除后，AG也会更新。
当添加Pod时，在AG接收请求之前将该Pod添加到AG时会有一个很小的延迟。但是，删除Pod时，更新延迟是否会导致将请求转发到不再存在的Pod？如果没有，AG/K8如何保证这一点？在这种情况下，终端客户端可能会经历什么行为？
推荐答案
Azure应用程序网关入口是您的Kubernetes部署的入口控制器，它允许您使用本机Azure应用程序网关向Internet公开您的应用程序。其目的是将流量直接路由到Pod。与此同时，所有关于吊舱可用性、日程安排和总体管理的问题都在Kubernetes自己身上。
当Pod收到要终止的命令时，它不会立即发生。就在Kube之后-代理将更新iptable以停止将流量定向到Pod。此外，可能有入口控制器或负载均衡器将连接直接转发到Pod(应用程序网关就是这种情况)。这个问题不可能完全解决，增加5-10秒的延迟可以显著提升用户体验。
如果您需要终止或缩减应用程序，则应考虑以下步骤：
- 等待几秒钟，然后停止接受连接
- 关闭所有不在请求中间的保活连接
- 等待所有活动请求完成
- 完全关闭应用程序
以下是帮助您解决问题的确切Kubernetes机制：
preStop挂钩-此挂钩在容器终止之前立即调用。这对于正常关闭应用程序非常有帮助。例如，在preStop挂钩中使用简单的sh命令和"；leep5"；命令可以防止用户看到"；连接被拒绝错误"；。实例收到要销毁的API请求后，需要一段时间来更新iptable，并让应用程序网关知道该实例已停止服务。由于preStop钩子是在SIGTERM信号之前执行的，因此有助于解决此问题。 (示例可在attach lifecycle event中找到)
就绪探测-此类探测始终在容器上运行，并定义Pod是否准备好接受和服务请求。当容器的就绪探测返回成功时，这意味着容器可以处理请求，并且它将被添加到端点。如果就绪探测失败，Pod将无法处理请求，并将从EndPoints对象中删除。当应用程序需要一些时间加载时，它可以很好地处理新创建的Pod；如果应用程序需要一些时间进行处理，它也可以很好地处理已经运行的Pod。 在从终端删除之前，就绪探测应该失败几次。可以使用
failureTreshold字段将该值降低到只有一次失败，但是它仍然需要检测一次失败的检查。 (有关如何设置的其他信息，请参阅configure liveness readiness startup probes)启动探测-对于某些在首次初始化时需要额外时间的应用程序，要在不影响应用程序快速响应的情况下正确设置就绪探测参数可能很棘手。 使用
failureThreshold * periodSeconds字段将提供这种灵活性。
如果应用程序需要超过默认30秒的延迟才能正常关闭(例如，这对于有状态应用程序很重要)，也可以考虑terminationGracePeriod-IS。
这篇关于应用程序网关如何防止将请求发送到最近终止的Pod？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
