简介本资源是一套专为 Kubernetes 环境设计的 Nacos 高可用集群极简部署方案面向容器化初学者与 DevOps 实践者解决传统 Nacos 在 K8s 中配置繁杂、状态管理困难、服务暴露不直观等痛点。压缩包共6个文件含5个结构清晰的 YAML 配置文件分别覆盖数据库参数注入、Headless Service、StatefulSet 控制器、ClusterIP 服务及 Ingress 暴露和1份说明性 TXT 文档总大小仅3KB轻量易读、即下即用。已有763人学习下载印证其在快速验证、教学演示与测试环境搭建场景中的实用价值。用户可直接按序执行脚本完成 Nacos 集群部署无需手动修改复杂字段所有 YAML 均遵循 K8s 最佳实践具备命名规范、标签统一、资源定义完整等特点便于理解 StatefulSet 有状态应用编排逻辑并为后续扩展多节点、持久化存储或 TLS 配置提供可靠基线。1. k8s nacos集群部署脚本yaml不是“一键部署”而是把Nacos从单机黑匣子变成可伸缩、可观测、可回滚的云原生服务你是不是也试过在测试环境用docker run -p 8848:8848 nacos/nacos-server起一个Nacos配置中心跑得飞起一上K8s就卡在「服务注册不上」「配置读取超时」「集群节点始终显示为1」这不是你操作不对——是Nacos天生不认K8s那套ServiceEndpoint的发现逻辑它的集群通信依赖固定IP端口自定义端点nacos.core.member.list而K8s里Pod IP天生漂移。这份k8s nacos集群部署脚本yaml本质是一套面向生产级可用性的Nacos集群契约它用StatefulSet锁住Pod身份用Headless Service暴露稳定DNS名用InitContainer预检MySQL连接与端口占用用Liveness/Readiness探针定义“健康”的真实语义不只是端口通还内置了JVM参数调优和日志滚动策略。适合正在将Spring Cloud微服务迁入K8s、且已确认Nacos必须作为配置中心服务发现双核心的中型团队——别再拿Helm chart凑合了这份脚本里每个字段都对应一个线上翻车现场。2. 部署前必答三问为什么不用Helm为什么必须用StatefulSet为什么MySQL必须外置2.1 Helm chart vs 手写YAML当模板抽象成黑盒你就失去了调试权Helm chart看似省事但Nacos官方chart如nacos-k8s默认开启standalone模式切cluster需手动覆盖nacos.core.member.list——而K8s里这个列表不能写死IP得靠kubectl get endpoints nacos-headless -o jsonpath{.subsets[0].addresses[*].ip}动态生成Helm做不到。更致命的是Helm的values.yaml里mysql.db和mysql.port若填错Pod会无限重启日志只报Failed to init DataSource根本看不到具体连哪个地址失败。手写YAML则能直接在env里注入MYSQL_HOST和MYSQL_PORT配合initContainers做前置校验# 在initContainer中执行 mysqladmin -h $MYSQL_HOST -P $MYSQL_PORT -u $MYSQL_USER -p$MYSQL_PASSWORD ping -c 1 /dev/null 21提示这段检查必须放在initContainer而非main container否则Nacos进程已启动却连不上DB整个Pod状态不可控。2.2 StatefulSet是Nacos集群的刚性前提无序不可用Nacos集群节点间通过gRPC互相心跳要求每个节点有稳定网络标识hostname subdomain。Deployment的Pod名是随机字符串如nacos-7f8d9b4c56-xyzabDNS解析nacos-0.nacos-headless.default.svc.cluster.local会失败而StatefulSet的Pod名严格按序nacos-0,nacos-1,nacos-2配合Headless Service可解析出确定IP。关键配置只有两处serviceName: nacos-headless指向Headless ServicepodManagementPolicy: OrderedReady确保nacos-0先就绪再启nacos-1若误用Deployment你会看到Nacos控制台「集群管理」里永远只有1个节点日志反复刷failed to report new node——因为新节点试图向nacos-0.nacos-headless注册但DNS查不到该域名。2.3 MySQL外置不是可选项而是Nacos数据一致性的生死线Nacos的config_info表主键是idBIGINT AUTO_INCREMENT若用StatefulSet挂载本地PV当nacos-0 Pod重建新Pod挂载旧PV后MySQL服务可能因auto_increment_offset错位导致主键冲突。外置MySQLRDS或K8s内独立MySQL StatefulSet强制所有Nacos实例共享同一套ID生成器。脚本中必须显式声明env: - name: MYSQL_SERVICE_HOST value: mysql-prod.default.svc.cluster.local # 绝对不能写127.0.0.1 - name: MYSQL_SERVICE_PORT value: 3306 - name: MYSQL_SERVICE_DB_NAME value: nacos_config注意MYSQL_SERVICE_HOST必须用FQDN而非ClusterIP否则跨Namespace访问失败若MySQL在其他Namespace需补全mysql-prod.prod-ns.svc.cluster.local。3. 核心YAML结构拆解从Pod定义到集群通信的七层契约3.1 StatefulSet主体身份锚点与资源硬约束以下为nacos-statefulset.yaml核心段已脱敏apiVersion: apps/v1 kind: StatefulSet metadata: name: nacos namespace: middleware spec: serviceName: nacos-headless replicas: 3 podManagementPolicy: OrderedReady selector: matchLabels: app: nacos template: metadata: labels: app: nacos spec: initContainers: - name: check-mysql image: mysql:8.0 command: [sh, -c] args: - | until mysqladmin -h $(MYSQL_HOST) -P $(MYSQL_PORT) -u $(MYSQL_USER) -p$(MYSQL_PASSWORD) ping -c 1 /dev/null; do echo Waiting for MySQL...; sleep 5; done env: - name: MYSQL_HOST valueFrom: configMapKeyRef: name: nacos-config key: mysql.host - name: MYSQL_PORT valueFrom: configMapKeyRef: name: nacos-config key: mysql.port # ... 其他env同理 containers: - name: nacos image: nacos/nacos-server:v2.2.3 ports: - containerPort: 8848 name: client - containerPort: 9848 name: raft - containerPort: 9849 name: naming-raft env: - name: MODE value: cluster - name: NACOS_SERVERS value: nacos-0.nacos-headless.middleware.svc.cluster.local:8848 nacos-1.nacos-headless.middleware.svc.cluster.local:8848 nacos-2.nacos-headless.middleware.svc.cluster.local:8848 # JVM参数必须显式设置否则容器OOM - name: JVM_XMS value: 2g - name: JVM_XMX value: 2g livenessProbe: httpGet: path: /actuator/health port: 8848 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /actuator/health port: 8848 initialDelaySeconds: 30 periodSeconds: 10 resources: requests: memory: 2Gi cpu: 1000m limits: memory: 4Gi cpu: 2000m关键参数说明NACOS_SERVERS这是Nacos集群通信的“通讯录”必须用FQDNnacos-0.nacos-headless.middleware.svc.cluster.local不能简写为nacos-0否则跨Namespace失败livenessProbe.initialDelaySeconds: 60Nacos启动慢加载配置初始化DB连接池设太小会导致Pod被反复killresources.limits.memory: 4GiNacos v2.x默认堆内存2G但Raft日志缓存Netty缓冲区需额外2G设低必OOMpodManagementPolicy: OrderedReady确保nacos-0完全就绪Readiness为True后才创建nacos-1避免集群脑裂。3.2 Headless Service让DNS成为集群的神经系统apiVersion: v1 kind: Service metadata: name: nacos-headless namespace: middleware annotations: service.alpha.kubernetes.io/tolerate-unready-endpoints: true spec: clusterIP: None # 关键必须为None才是Headless selector: app: nacos ports: - name: client port: 8848 targetPort: 8848 - name: raft port: 9848 targetPort: 9848 - name: naming-raft port: 9849 targetPort: 9849为什么需要clusterIP: NoneHeadless Service不分配ClusterIP而是为每个Pod生成独立DNS记录nacos-0.nacos-headless.middleware.svc.cluster.local→ 解析为nacos-0 Pod IPnacos-1.nacos-headless.middleware.svc.cluster.local→ 解析为nacos-1 Pod IPNacos源码中com.alibaba.nacos.core.cluster.MemberManager会调用InetAddress.getByName(nacos-0.nacos-headless...)获取IP若Service有ClusterIPDNS返回的是Service VIP而非Pod IP集群通信直接中断。3.3 ConfigMap与Secret配置与密钥的分离契约ConfigMap存非敏感配置MySQL地址、端口、数据库名apiVersion: v1 kind: ConfigMap metadata: name: nacos-config namespace: middleware data: mysql.host: mysql-prod.default.svc.cluster.local mysql.port: 3306 mysql.db.name: nacos_config # ... 其他Secret存密码Base64编码apiVersion: v1 kind: Secret metadata: name: nacos-secret namespace: middleware type: Opaque data: mysql.password: cGFzc3dvcmQxMjM # echo -n password123 | base64必须用Secret而非ConfigMap存密码ConfigMap内容在etcd中明文存储任何有get secrets权限的用户都能kubectl get secret nacos-secret -o yaml解密而ConfigMap无此保护。4. 避坑指南Nacos集群在K8s中最常踩的五个深坑4.1 现象Nacos控制台显示“集群管理”仅1个节点日志反复出现failed to report new node原因NACOS_SERVERS环境变量中节点地址未使用FQDN或Headless Service未正确关联StatefulSet Pod。例如写成nacos-0:8848缺少域名后缀DNS无法解析。解决进入任意Nacos Pod执行nslookup nacos-0.nacos-headless.middleware.svc.cluster.local若返回server cant find ...检查Service的selector.app是否与Pod标签完全一致包括大小写若返回IP但错误检查Service的namespace是否与StatefulSet一致。4.2 现象Pod状态为CrashLoopBackOff日志首行即Caused by: java.lang.RuntimeException: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure原因MySQL连接参数错误但initContainer未捕获该异常如密码错误时mysqladmin ping仍返回0。解决修改initContainer命令增加mysql -h $MYSQL_HOST -P $MYSQL_PORT -u $MYSQL_USER -p$MYSQL_PASSWORD -e SELECT 1该命令在密码错误时明确返回非0码同时检查Secret中密码Base64是否含换行符echo xxx | base64末尾的\n会被编码需用echo -n xxx | base64。4.3 现象Nacos服务注册成功但客户端调用curl http://nacos-0.nacos-headless:8848/nacos/v1/ns/instance/list?serviceNamexxx返回空列表原因客户端SDK版本与Nacos Server不兼容。Nacos v2.2.x要求客户端使用2.2.0版本若用1.4.3其HTTP注册协议不支持v2的gRPC服务发现。解决升级客户端依赖Spring Cloud Alibaba用户将spring-cloud-starter-alibaba-nacos-discovery版本升至2022.0.0.0并确认nacos-client传递依赖为2.2.3。4.4 现象集群运行2小时后某个Pod CPU飙升至900%top显示java进程占满但jstack无明显阻塞线程原因JVM未设置-XX:UseG1GCNacos v2.x默认CMS GC在容器环境下触发频繁Full GC。解决在StatefulSet的env中添加- name: JVM_OPT value: -XX:UseG1GC -XX:MaxGCPauseMillis200G1 GC在容器内存限制下更稳定MaxGCPauseMillis防止GC停顿超长导致Readiness探针失败。4.5 现象执行kubectl scale statefulset nacos --replicas5扩容后nacos-3、nacos-4节点在控制台显示为UNREACHABLE原因NACOS_SERVERS环境变量是静态字符串扩容后新Pod读取的仍是旧列表3个地址无法感知新增节点。解决改用Nacos官方推荐的K8s ConfigMap自动发现部署nacos-k8s项目中的nacos-pvc.yaml它通过ConfigMap监听Pod变化并动态更新nacos.core.member.list或改用nacos-operator需额外部署Operator。5. 生产验证四步法从部署完成到真正可信的集群5.1 第一步验证集群拓扑真实性不止看控制台控制台「集群管理」显示3个节点只是表象需直连Pod验证Raft状态# 进入nacos-0 Pod kubectl exec -it nacos-0 -n middleware -- sh # 查看Raft节点状态 curl http://localhost:8848/nacos/v1/ns/operator/raft/state预期输出{raftGroup:DEFAULT_GROUP,leader:nacos-0.nacos-headless.middleware.svc.cluster.local:8848,peers:nacos-0.nacos-headless.middleware.svc.cluster.local:8848,nacos-1.nacos-headless.middleware.svc.cluster.local:8848,nacos-2.nacos-headless.middleware.svc.cluster.local:8848}若peers字段缺失某节点或leader为空说明Raft集群未形成需检查9848端口是否被防火墙拦截K8s NetworkPolicy常误封该端口。5.2 第二步压测配置推送一致性检验数据同步用nacos-sdk-go写一个推送脚本向test-group推送1000条配置然后并发从3个节点拉取// 推送端 client, _ : vo.NewClient(vo.Config{ ServerConfigs: []constant.ServerConfig{{ IpAddr: nacos-0.nacos-headless.middleware.svc.cluster.local, Port: 8848, }}, }) for i : 0; i 1000; i { client.PublishConfig(vo.ConfigParam{ DataId: fmt.Sprintf(test-%d, i), Group: test-group, Content: value- strconv.Itoa(i), }) } // 拉取端分别请求nacos-0/1/2 resp, _ : http.Get(http://nacos-0:8848/nacos/v1/cs/configs?dataIdtest-1grouptest-group) // 验证3个节点返回Content完全一致通过标准1000次推送后3个节点拉取结果100%一致且耗时5秒。若某节点延迟30秒检查nacos-0的logs/nacos.log中是否有[db-load] load config info from db failed说明DB连接池耗尽。5.3 第三步模拟节点故障检验自愈能力# 删除nacos-1 Pod观察是否重建 kubectl delete pod nacos-1 -n middleware # 等待2分钟检查 kubectl get pods -n middleware | grep nacos # 应显示nacos-1处于Running kubectl logs nacos-1 -n middleware | tail -20 # 日志应包含start stand alone mode→start cluster mode关键观察点新Pod日志中必须出现start cluster mode而非stand alone且/actuator/health探针在30秒内变绿。若持续CrashLoopBackOff检查nacos-1的/root/logs/start.out中是否有java.net.UnknownHostException: nacos-0.nacos-headless这表示DNS解析失败需排查CoreDNS日志。5.4 第四步验证服务发现链路端到端闭环部署一个Spring Boot客户端application.ymlspring: cloud: nacos: discovery: server-addr: nacos-headless.middleware.svc.cluster.local:8848 # 必须用Headless Service名 group: DEFAULT_GROUP启动后执行# 查看客户端注册的IP是否为Pod IP非ClusterIP kubectl get endpoints nacos-headless -n middleware -o wide # 在客户端Pod内curl curl http://nacos-headless.middleware.svc.cluster.local:8848/nacos/v1/ns/instance/list?serviceNameclient-app预期返回JSON中hosts数组包含客户端Pod的IP且healthy为true。若hosts为空检查客户端server-addr是否误写为nacos-0.nacos-headless...应走Service负载均衡。6. 进阶技巧用PrometheusGrafana构建Nacos可观测性闭环6.1 暴露Nacos原生Metrics端点Nacos v2.2内置/actuator/prometheus端点但默认关闭。需在StatefulSet中启用env: - name: SPRING_PROFILES_ACTIVE value: standalone,actuator # 启用actuator profile - name: MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE value: prometheus,health,info # 显式暴露prometheus然后配置ServiceMonitorPrometheus OperatorapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: nacos-monitor namespace: monitoring spec: selector: matchLabels: app: nacos namespaceSelector: matchNames: - middleware endpoints: - port: client path: /actuator/prometheus interval: 15s6.2 关键指标监控清单Grafana面板必备指标名Prometheus查询语句告警阈值业务含义集群节点数count(count by (instance)(nacos_monitor_status{jobnacos}))3Raft集群至少3节点才具备容错能力配置推送延迟histogram_quantile(0.95, sum(rate(nacos_config_publish_duration_seconds_bucket[1h])) by (le))5s配置变更到全集群生效的P95耗时Raft Leader切换次数increase(nacos_raft_leader_change_total[1h])3次/h频繁切换Leader表明网络不稳定或节点负载过高MySQL连接池使用率nacos_datasource_active_connections{datasourcenacos_config}/nacos_datasource_max_connections{datasourcenacos_config}0.9连接池打满将导致配置读取超时6.3 自定义告警规则Alertmanager在alert-rules.yaml中添加- alert: NacosClusterNodeDown expr: count by (job)(nacos_monitor_status{jobnacos, statusUP}) 3 for: 2m labels: severity: critical annotations: summary: Nacos集群节点数低于3 description: 当前{{ $value }}个节点存活低于最小容错数3 - alert: NacosConfigPublishLatencyHigh expr: histogram_quantile(0.95, sum(rate(nacos_config_publish_duration_seconds_bucket[1h])) by (le)) 5 for: 5m labels: severity: warning annotations: summary: Nacos配置推送P95延迟超过5秒 description: 配置中心响应变慢影响服务发布效率从那以后我每次上线新集群都强制走一遍这四步验证先curl Raft状态再推1000条配置比对接着删Pod看自愈最后用客户端实测服务发现。少走任何一步线上就可能遇到「配置改了但服务没刷新」这种玄学问题——而这类问题的根因90%都在集群拓扑或网络策略里。希望帮到你。本文还有配套的精品资源点击获取
