NextJS部署在Kubernetes集群中，router.push跨Pod处理问题咨询

首先明确核心问题：你用的router.push是客户端侧导航，会触发浏览器发起新的HTTP请求，而K8s Service默认的负载均衡策略（比如轮询）会把新请求随机分发到集群内的Pod，所以才会出现首次请求在Pod#1、重定向请求到Pod#2的情况。要解决这个问题，核心是让同一客户端的请求绑定到固定Pod，有以下几种可行方案：

1. 配置K8s Service的会话亲和性（ClientIP） #

直接修改NextJS应用对应的K8s Service配置，开启基于客户端IP的会话亲和性，这样来自同一IP的所有请求都会被路由到同一个Pod。

示例Service YAML：

apiVersion: v1
kind: Service
metadata:
  name: nextjs-app-service
spec:
  selector:
    app: nextjs-app
  ports:
    - port: 80
      targetPort: 3000
  # 开启ClientIP会话亲和性
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800 # 绑定有效期3小时，可根据业务调整

配置生效后，同一客户端的首次请求和重定向请求都会落到同一个Pod上。

2. 用Ingress Controller实现Cookie-based会话亲和性（适配代理/CDN场景） #

如果你的应用是通过代理或CDN对外提供服务，客户端IP会被替换成代理/CDN的IP，导致多个客户端被绑定到同一个Pod，影响负载均衡效果。这种情况下可以用Ingress Controller（比如NGINX Ingress）配置基于Cookie的会话亲和性：

示例Ingress YAML注解：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nextjs-app-ingress
  annotations:
    # 开启Cookie亲和性
    nginx.ingress.kubernetes.io/affinity: "cookie"
    # 自定义会话Cookie名称
    nginx.ingress.kubernetes.io/session-cookie-name: "nextjs-session-id"
    # Cookie有效期（2天）
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
spec:
  rules:
    - host: your-domain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nextjs-app-service
                port:
                  number: 80

这种方式会给客户端设置一个会话Cookie，后续所有带该Cookie的请求都会被路由到首次处理的Pod。

3. 改用服务器端重定向（避免客户端新请求） #

如果你的重定向逻辑可以在服务器端处理，建议用NextJS的服务器端重定向（比如在getServerSideProps或getStaticProps中返回redirect），这种方式不会触发客户端发起新请求，而是在服务器端直接完成重定向逻辑，自然在同一个Pod内处理：

示例代码：

export async function getServerSideProps(context) {
  // 替换成实际业务逻辑判断是否需要重定向
  const shouldRedirect = true;

  if (shouldRedirect) {
    return {
      redirect: {
        destination: "/target-path",
        permanent: false, // 临时重定向用302，永久用301
      },
    };
  }

  return { props: {} };
}

注意：这种方式仅让重定向逻辑在当前Pod执行，如果目标路径需要服务器端渲染，后续请求仍可能被负载到其他Pod，若要保持整个会话的Pod绑定，仍需结合前面的会话亲和性配置。

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