Wakapi部署中Nginx反向代理导致登录失效的解决方案

问题背景

在Kubernetes环境中部署Wakapi时，通过Nginx Ingress Controller暴露服务后，用户遇到了一个典型的会话保持问题：虽然前端页面可以正常访问，但登录功能无法正常工作。具体表现为用户提交登录表单后，系统返回302重定向到首页，但实际并未建立有效会话，导致后续访问受保护页面时又被重定向回登录页。

技术分析

这个问题本质上是一个分布式会话管理问题，主要涉及以下几个技术点：

1. 会话机制：Wakapi使用基于Cookie的会话管理
2. 负载均衡：部署中配置了3个副本的Wakapi实例
3. 反向代理：通过Nginx Ingress Controller进行流量转发

在默认配置下，Nginx会使用轮询方式将请求分发到不同的Pod实例。当登录请求被路由到Pod A处理并设置会话Cookie后，下一个请求可能被路由到Pod B，而Pod B并不知晓这个会话，导致认证失败。

解决方案

通过在Ingress资源中添加特定的Nginx注解，可以强制Nginx使用基于Cookie的会话保持策略：

nginx.ingress.kubernetes.io/affinity: "cookie"

这个配置的作用是：

1. 使Nginx识别应用设置的会话Cookie
2. 确保同一用户的所有后续请求都被路由到同一个后端Pod
3. 维持会话状态的一致性

深入理解

会话亲和性(Session Affinity)

会话亲和性，也称为"粘性会话"(Sticky Session)，是负载均衡中的一种重要策略。在需要保持状态的Web应用中尤为重要，它确保来自同一客户端的请求始终被路由到同一后端服务器。

Kubernetes中的实现方式

在Kubernetes中，可以通过以下方式实现会话亲和性：

1. Service层：使用sessionAffinity: ClientIP（基于客户端IP）
2. Ingress层：如本例所示，使用Nginx的Cookie亲和性（更精确）
3. 应用层：使用分布式会话存储（如Redis）

为什么Cookie亲和性更优

相比基于IP的亲和性，基于Cookie的方式：

1. 更精确（同一IP可能有多个用户）
2. 不受NAT影响
3. 可以处理移动设备切换网络的情况

最佳实践建议

1. 副本数量：对于Wakapi这类轻量级应用，通常1-2个副本即可满足需求
2. 健康检查：确保配置适当的存活和就绪探针
3. 资源限制：为容器设置合理的资源请求和限制
4. 监控：监控各Pod的负载情况，确保亲和性不会导致负载不均

总结

在Kubernetes中部署有状态Web应用时，正确处理会话保持是确保应用功能完整性的关键。通过合理配置Ingress控制器的会话亲和性，可以解决因负载均衡导致的登录状态丢失问题。对于Wakapi这类时间跟踪工具，保持用户会话的连续性尤为重要，以确保数据记录的准确性和用户体验的连贯性。