问题描述
部署在AKS中的应用，连接Redis高频率出现timeout问题
问题解答
查看Redis状态，没有任何异常，服务没有更新，Service Load， CPU， Memory， Connect等指标均正常。在排除Redis端问题后，转向了AKS中。
开始调查AKS的网络状态。最终发现每次Redis客户端出现超时问题时，几乎都对应了AKS NAT Gateway的更新事件，而Redis服务端没有任何异常。因此，超时问题很可能是由于NAT Gateway更新事件导致TCP连接被重置。
NAT****更新原理: 在NAT Gateway的底层组件更新初期，被更新的内部实例将不会接受新的连接请求。在接下来的更新时间里，所有传入的数据包都将收到TCP RST（重置）消息作为响应。而后存量连接被清空，实例就会进入更新流程。此操作确保在更新过程中，客户端可以自动与其他未更新实例重新建立连接，从而尽量减少对业务的影响。
如何监控NAT****更新: 可以通过NAT Gateway的Datapath Availability的指标来监控NAT网关是否发生了更新。在更新期间NAT Gateway的Datapath Availability会略微下降至98%及以下， 这可以作为判断维护状态的一个参考 : Azure NAT 网关的指标和警报 - Azure NAT Gateway | Microsoft Learn
image.png
面对如此情况，可作如下调整：
- Redis设置较短的超时时间，这样可以更快地在客户端层面重新建立连接，同时，负面效果是提高了超时报错的几率。对于高操作频率的Redis，较短的超时时间依然是一个比较好的方案。
- 可以将AKS 所在的Linux系统中的net.ipv4.tcp_retries2参数修改得更小，使TCP底层连接更快地重连。https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-best-practices-connection#tcp-settings-for-linux-hosted-client-applications
- 可以尝试让Redis客户端建立更多连接数量，通过分散的出站连接，减少NAT Gateway实例更新对客户端连接的影响。
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
