Pod 重启 IP 就变——Nacos 上 k8s 的三个致命问题与完整解决方案
Deployment 部署 Nacos，重启后集群全员失联
团队决定把 Nacos 迁移到 k8s。我想着"三个 Deployment 不就完了"——结果踩了一串连环坑。
第一版配置：
apiVersion:apps/v1kind:Deploymentmetadata:name:nacosspec:replicas:3三个 Pod 跑起来，控制台能看到所有节点。一切正常。直到有一天——Pod-0 被 k8s 调度器驱逐重启，新 Pod 拿到了新 IP。
cluster.conf 里还写着旧 IP。三个节点互相找不到对方，集群裂了。
后来发现三个问题：
- Pod IP 会变，重启后 cluster.conf 里存的是旧地址。
- 不能用 Deployment，需要稳定的 Pod 标识来维护集群拓扑。
- 自发现机制和 Readiness Probe 会打架——启动中就被 Service 路由了流量。
下面把 k8s 部署 Nacos 的正确姿势完整拆开。
第一个问题：Pod IP 不稳定
Pod 重启后 IP 变化，cluster.conf 里的旧 IP 失效。如果两个以上节点同时受此影响——集群完全崩溃。
解决：StatefulSet + Headless Service
StatefulSet 给每个 Pod 分配固定网络标识：
nacos-0.nacos-headless.nacos.svc.cluster.local nacos-1.nacos-headless.nacos.svc.cluster.local nacos-2.nacos-headless.nacos.svc.cluster.localPod 重启后域名不变，即使 IP 变了。
# headless-service.yamlapiVersion:v1kind:Servicemetadata:name:nacos-headlessnamespace:nacosspec:clusterIP:None# Headless Service：不分配 ClusterIPselector:app:nacosports:-name:httpport:8848targetPort:8848-name:grpc-clientport:9848targetPort:9848-name:grpc-clusterport:9849targetPort:9849坑1：不能用普通 Service，必须 Headless。普通 Service 有 ClusterIP，所有流量经过它代理，Pod 不知道自己的域名。Headless Service（clusterIP: None）让每个 Pod 获得独立 DNS 记录。
第二个问题：Deployment 不适合有状态集群
Deployment 管的是"无状态副本"——Pod 从哪个节点启动无所谓，名称随机，IP 随机。但集群模式需要：
- 启动顺序可控（先启动的当 Leader）
- 每个节点有固定身份标识
- 滚动更新时知道"现在重启的是哪个"
StatefulSet 完美匹配这三个需求：
StatefulSet 四大保障：固定名称、有序启动、逆序终止、独立存储。每一项都命中集群部署的痛点。
完整 StatefulSet 配置
# statefulset.yamlapiVersion:apps/v1kind:StatefulSetmetadata:name:nacosnamespace:nacosspec:serviceName:nacos-headless# 绑定 Headless Servicereplicas:3podManagementPolicy:Parallel# 并行启动（非严格有序，但第一个先启）selector:matchLabels:app:nacostemplate:metadata:labels:app:nacosspec:# 反亲和：三个 Pod 尽量分布在不同节点上affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchLabels:app:nacostopologyKey:kubernetes.io/hostnamecontainers:-name:nacosimage:nacos/nacos-server:v2.3.2env:-name:MODEvalue:"cluster"-name:PREFER_HOST_MODEvalue:"hostname"-name:NACOS_SERVERSvalue:"nacos-0.nacos-headless.nacos.svc.cluster.local:9849 nacos-1.nacos-headless.nacos.svc.cluster.local:9849 nacos-2.nacos-headless.nacos.svc.cluster.local:9849"-name:SPRING_DATASOURCE_PLATFORMvalue:"mysql"-name:MYSQL_SERVICE_HOSTvalue:"mysql.nacos.svc.cluster.local"-name:MYSQL_SERVICE_PORTvalue:"3306"-name:MYSQL_SERVICE_DB_NAMEvalue:"nacos_config"-name:MYSQL_SERVICE_USERvalueFrom:secretKeyRef:name:nacos-mysql-secretkey:username-name:MYSQL_SERVICE_PASSWORDvalueFrom:secretKeyRef:name:nacos-mysql-secretkey:passwordports:-containerPort:8848name:http-containerPort:9848name:grpc-client-containerPort:9849name:grpc-clusterreadinessProbe:httpGet:path:/nacos/v1/console/health/readinessport:8848initialDelaySeconds:30periodSeconds:10failureThreshold:5livenessProbe:httpGet:path:/nacos/v1/console/health/livenessport:8848initialDelaySeconds:60periodSeconds:20failureThreshold:3第三个问题：Readiness Probe 与启动时间打架
坑2：Readiness Probe 太早探活。Nacos 集群启动需要 30~60 秒（初始化数据库 + 选举）。如果initialDelaySeconds设太短，Pod 还没准备好就被打入 Service 后端，请求直接超时。
# 推荐值（生产环境）readinessProbe:httpGet:path:/nacos/v1/console/health/readinessport:8848initialDelaySeconds:60# 给足启动时间periodSeconds:10failureThreshold:5# 容忍偶尔超时livenessProbe:httpGet:path:/nacos/v1/console/health/livenessport:8848initialDelaySeconds:120# 比 readiness 更晚periodSeconds:20failureThreshold:3Nacos 内部有两个健康端点：
| 端点 | 含义 | 探活类型 |
|---|---|---|
/nacos/v1/console/health/readiness | 服务是否准备好接收请求 | Readiness Probe |
/nacos/v1/console/health/liveness | 进程是否存活 | Liveness Probe |
如果 Liveness Probe 失败，k8s 会杀死 Pod 重建。Readiness 失败只是暂时不路由流量。
坑3：Liveness Probe 设置太激进。选举期间 Nacos 可能短暂不响应，不要因为一两次失败就 kill 容器。
对外暴露：集群内外双通道
# service-for-external.yaml# 给集群外客户端和控制台访问apiVersion:v1kind:Servicemetadata:name:nacos-externalnamespace:nacosspec:type:NodePort# 或 LoadBalancerselector:app:nacosports:-name:httpport:8848targetPort:8848nodePort:30848# 对外暴露的端口两套 Service：Headless 给集群内 Pod 直连（固定 DNS），NodePort/LoadBalancer 给集群外客户端和控制台访问。
ConfigMap 统一管理配置
# configmap.yamlapiVersion:v1kind:ConfigMapmetadata:name:nacos-confignamespace:nacosdata:application.properties:|spring.sql.init.platform=mysqldb.num=1 db.url.0=jdbc:mysql://mysql.nacos.svc.cluster.local:3306/nacos_config?useSSL=false&serverTimezone=Asia/Shanghainacos.core.auth.enabled=true nacos.core.auth.server.identity.key=nacos nacos.core.auth.server.identity.value=nacos通过volumeMounts挂入 Pod：
volumeMounts:-name:nacos-confmountPath:/home/nacos/conf/application.propertiessubPath:application.propertiesvolumes:-name:nacos-confconfigMap:name:nacos-configHelm 一键部署（懒人版）
# 添加 Nacos Helm 仓库helm repoaddnacos https://nacos-group.github.io/nacos-helm helm repo update# 一键安装helminstallnacos nacos/nacos\--namespacenacos\--create-namespace\--setglobal.mode=cluster\--setreplicaCount=3\--setmysql.enabled=true\--setmysql.mysqlUser=nacos\--setmysql.mysqlPassword=Nacos@2024# 验证kubectl get pods-nnacos-w# nacos-0 nacos-1 nacos-2 Running常见 k8s 部署问题速查
| 现象 | 原因 | 解决 |
|---|---|---|
| Pod 反复 CrashLoopBackOff | Liveness Probe 太激进 | initialDelaySeconds设 120s+ |
| 集群成员列表只看到自己 | NACOS_SERVERS写的是 Pod IP 不是 DNS | 改用 Headless Service DNS 名 |
| 注册的服务跨 Pod 查不到 | 未共享 MySQL，各 Pod 用内置 Derby | 配置共享 MySQL |
| 启动后 Pod 被 Service 路由但仍 503 | Readiness Probe 还没探活成功 | 耐心等 30~60s，不要过早请求 |
podAntiAffinity导致 Pending | 节点数少于 Pod 数 | 改为preferredDuringScheduling |
总结
Nacos 上 k8s 的五个核心决策：
- StatefulSet 不是 Deployment：需要固定 Pod 名 + DNS 做集群发现。
- Headless Service 不是普通 Service：
clusterIP: None给每个 Pod 独立 DNS。 - cluster.conf 用 DNS 名不是 IP：
nacos-0.nacos-headless.nacos.svc.cluster.local:9849。 - Probe 要宽松：
initialDelaySeconds给 60~120 秒，选举期间容忍失败。 - MySQL 是必须的：不能指望 Pod 本地的 Derby 来做集群数据同步。
从 Deployment 踩坑到 StatefulSet + Headless Service 组合，其实就改了三处：kind: StatefulSet+serviceName绑定 +NACOS_SERVERS换 DNS。但每一处都踩过坑才知道。
你们 Nacos 跑在什么环境？评论区留个数字：1=传统虚拟机部署 2=裸 Docker 容器 3=k8s StatefulSet 4=Nacos 托管服务（MSE/PolarisMesh 等）。顺带说一句你觉得 Nacos 上 k8s 最大的坑是什么。
