GCE Kubernetes中WordPress/WooCommerce会话持久化扩容问题求助

你遇到的这个问题太典型了——当流量经过GCE Ingress和反向代理后，Kubernetes Service识别到的"客户端IP"其实是负载均衡器或者反向代理的IP，而不是用户的真实IP。这就导致你配置SessionAffinity: ClientIP后，所有请求都会被判定为来自同一个"客户端"，自然全扎堆到单个Pod上，其他Pod完全闲置，扩容也就失去了意义。

下面给你两个优先级不同的解决方案，按需选择：

方案1：用共享会话存储替代IP亲和（强烈推荐） #

这是分布式WordPress/WooCommerce部署的标准方案，彻底摆脱IP亲和的限制，扩容更灵活：

• 先在Kubernetes集群里部署Redis服务（用Helm可以一键搞定，比如helm install redis bitnami/redis）
• 给WordPress安装Redis缓存插件（比如Redis Object Cache），在插件设置里填写集群内Redis服务的地址和端口
• 修改wp-config.php，强制WordPress用Redis存储会话：

define('WP_REDIS_HOST', 'redis'); // 替换成你的Redis服务名称
define('WP_REDIS_PORT', 6379);
define('SESSION_SAVE_HANDLER', 'redis');
define('SESSION_SAVE_PATH', 'tcp://redis:6379?database=0');

这样所有Pod都会从同一个Redis实例读取会话数据，不管请求落到哪个Pod，用户的登录状态、购物车信息都能保持一致，完全不需要依赖会话亲和，扩容Pod时流量可以均匀分发。

方案2：配置代理和Service传递真实客户端IP #

如果你一定要用ClientIP会话亲和，需要确保后端Service能拿到用户的真实IP：

1. 配置反向代理传递真实IP：
   让你的反向代理在转发请求时添加真实IP相关的请求头，比如Nginx的配置片段：

   location / {
       proxy_pass http://wordpress-service;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header Host $host;
   }
   

   这样WordPod就能通过这些头拿到用户的真实IP。
2. 配置K8s Service保留真实IP：
   把WordPress Service的externalTrafficPolicy设为Local，避免Kubernetes做SNAT，让后端Pod能直接拿到真实客户端IP：

   apiVersion: v1
   kind: Service
   metadata:
     name: wordpress-service
   spec:
     type: ClusterIP
     externalTrafficPolicy: Local
     sessionAffinity: ClientIP
     sessionAffinityConfig:
       clientIP:
         timeoutSeconds: 10800 # 可根据业务调整会话超时时间
     selector:
       app: wordpress
     ports:
       - port: 80
         targetPort: 80
   

   注意：externalTrafficPolicy: Local可能会让流量分布略有不均（只有运行Pod的节点会接收流量），但至少能让会话亲和基于真实IP工作，多个Pod都能分到请求。

额外提醒 #

• 如果你用的是GCE原生Ingress，默认会自动添加X-Forwarded-For头，不用额外配置，但可以检查Ingress的后端规则确认。
• 测试WooCommerce时，一定要验证跨Pod访问的购物车状态是否正常，避免出现用户切换Pod后购物车清空的问题。

内容的提问来源于stack exchange，提问作者Steve