GKE中API与MongoDB连接粘性致HPA扩容无效，端口受限

1. 第二个MongoDB Pod未被使用的原因 #

没错，就是粘性连接导致的，具体细节：

• PyMongo的MongoClient初始化时会一次性解析mongodb-service的DNS，拿到当时唯一的MongoDB Pod IP，之后默认维持长连接池，不会主动重新解析DNS去获取新扩容出来的Pod IP。
• 你的API代码里每次调用get_db都新建MongoClient，但每个API Pod的系统会缓存DNS结果（K8s默认DNS TTL是30秒，但客户端缓存可能更久），再加上MongoDB长连接的特性，每个API Pod都会持续和第一个MongoDB Pod保持连接，所有请求都走这些老连接，新Pod根本没机会接到流量。
• 这里要重点提醒：你当前的MongoDB Deployment是单实例本地存储架构，就算解决了连接问题，新Pod的数据和原Pod完全不一致，业务会直接出现数据错误，这是架构上的致命问题，必须优先修复。

2. 解决方法（先修架构，再调连接） #

第一步：紧急修复MongoDB架构（必须优先做） #

你当前用Deployment部署MongoDB的方式，根本无法实现有效负载均衡——每个Pod的/data/db是本地存储，扩出来的Pod数据完全独立，这不是扩缩容，是创建了一堆数据不一致的实例。正确的做法选下面一种：

• MongoDB副本集（推荐）：把Deployment改成StatefulSet，配置MongoDB副本集，所有节点共享同一数据集，MongoDB自身会处理读写路由（主节点写，从节点读），扩缩容时新节点自动加入集群。
• 托管MongoDB服务：直接用GCP的Cloud MongoDB Atlas或者Cloud SQL for MongoDB，托管集群自动处理数据同步、扩缩容，无需手动维护。
• 临时测试方案：给MongoDB Pod挂载共享存储（比如GCE Persistent Disk），确保所有Pod用同一份数据，但这个方案生产环境绝对不能用，数据风险极高。

第二步：优化PyMongo连接，打破粘性 #

架构修复后，调整PyMongo的连接逻辑，让它能自动发现新的MongoDB节点：

• 复用MongoClient实例：别每次请求都新建MongoClient，它是线程安全的，全局初始化一次即可，避免重复创建连接，还能合理控制连接池大小：

  # 全局初始化，整个API服务生命周期只执行一次
  mongo_client = MongoClient(
      host="$Cluster_IP_of_{mongodb-service}",
      port=27017,
      username="...",
      password="...",
      authSource="admin",
      maxPoolSize=100,  # 根据API并发量调整，默认值为100
      socketTimeoutMS=30000,
      connectTimeoutMS=10000,
      retryWrites=True
  )
  
  def get_db(database: str):
      return mongo_client.get_database(database)
  

• 开启DNS自动刷新：给MongoClient添加dnsRefreshIntervalMS参数，定期重新解析DNS，获取新的Pod IP：

  mongo_client = MongoClient(
      # 其他参数不变
      dnsRefreshIntervalMS=30000  # 每30秒刷新一次DNS
  )
  

• 调整K8s Service配置：显式关闭会话亲和性，缩短DNS缓存时间，让客户端更快获取新Pod的IP：

  apiVersion: v1
  kind: Service
  metadata:
    name: mongodb-service
    labels:
      app: mongodb
    annotations:
      service.kubernetes.io/dns-ttl: "5"  # 把DNS缓存时间缩到5秒
  spec:
    selector:
      app: mongodb
    sessionAffinity: None  # 强制关闭会话亲和性，默认值即为None，显式声明更保险
    ports:
      - protocol: TCP
        port: 27017
        targetPort: 27017
  

额外提示 #

• 既然核心计算在MongoDB，优先优化查询语句和索引，降低单个Pod的CPU负载，比单纯扩缩容更高效。
• 监控MongoDB的连接数、CPU使用率，合理调整HPA的阈值，避免频繁扩缩容导致资源浪费。

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