Apache APISIX Kubernetes服务发现中Token过期问题分析与解决方案

问题背景

Apache APISIX作为一款高性能API网关，在Kubernetes环境中运行时，通常会使用Kubernetes服务发现功能来自动获取后端服务实例。然而，在实际生产环境中，我们发现当Kubernetes服务账户Token过期后，APISIX的服务发现功能会出现异常，导致无法获取最新的Pod信息，最终影响流量路由。

问题现象

当Kubernetes服务账户Token过期时，APISIX日志中会出现类似以下错误信息：

[lua] informer_factory.lua:295: list failed, kind: Endpoints, reason: Unauthorized, message : {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}

此时，APISIX会继续使用内存中缓存的旧Pod信息进行流量转发，而实际上这些Pod可能已经被更新或删除，导致请求失败。

根本原因分析

经过深入分析，我们发现问题的根源在于APISIX对Kubernetes服务账户Token的处理方式：

1. Token加载机制：APISIX在启动时使用单例模式加载服务账户Token文件，之后不再重新读取
2. Kubernetes Token轮换：Kubernetes默认会定期(约90天)轮换服务账户Token
3. 无刷新机制：APISIX缺乏Token自动刷新机制，导致Token过期后无法继续访问Kubernetes API

技术细节

Kubernetes服务账户Token存储在Pod内的/var/run/secrets/kubernetes.io/serviceaccount/token文件中。APISIX通过这个Token与Kubernetes API Server进行认证。当前实现中，Token只在APISIX启动时读取一次，之后即使文件内容发生变化也不会重新加载。

解决方案

要解决这个问题，我们需要在APISIX中实现Token自动刷新机制。以下是几种可行的解决方案：

方案一：定期重新加载Token文件

在APISIX的Kubernetes服务发现模块中增加定时器，定期(如每天)重新读取Token文件内容。当发现Token内容变化时，更新API客户端配置。

方案二：文件变更监听

利用文件系统事件监听机制，当Token文件内容发生变化时自动重新加载。这种方式响应更及时，但实现复杂度较高。

方案三：Token过期前主动刷新

通过解析Token的过期时间，在Token即将过期前主动触发重新加载操作。这需要能够解析JWT Token的内容。

实现建议

对于APISIX项目，推荐采用方案一结合方案三的实现方式：

1. 启动时记录Token文件的最后修改时间
2. 定期(如每小时)检查文件修改时间
3. 当发现文件被修改时，重新加载Token内容
4. 同时解析Token中的过期时间，在接近过期时增加检查频率

影响评估

该问题主要影响以下场景：

• 长期运行的APISIX实例(超过90天)
• 使用Kubernetes服务发现功能的部署
• 频繁进行Pod滚动更新的环境

最佳实践

在生产环境中使用APISIX的Kubernetes服务发现功能时，建议：

1. 定期重启APISIX Pod(如每60天)，强制重新加载Token
2. 监控APISIX日志中的401错误，及时发现Token过期问题
3. 考虑使用自定义服务账户并设置更长的Token有效期(需评估安全风险)

总结

Kubernetes服务账户Token过期导致的APISIX服务发现功能失效是一个典型的长周期运行问题。通过实现Token自动刷新机制，可以显著提高APISIX在Kubernetes环境中的稳定性和可靠性。这一改进对于需要长期稳定运行的生产环境尤为重要。