Kubernetes上构建高可用Nacos集群：从架构设计到生产部署全解析

1. 项目背景与核心价值

最近在搞微服务架构的落地，服务注册与发现中心是绕不开的一环。Nacos作为阿里开源的一款集服务发现、配置管理于一体的平台，凭借其易用性和对K8s生态的友好支持，成了很多团队的首选。但很多朋友在初次尝试将Nacos部署到Kubernetes（k8s）上时，往往会直接使用单节点模式，这在生产环境是存在风险的。单点故障一旦发生，整个微服务体系的注册中心和配置中心就会瘫痪，后果不堪设想。因此，在k8s上搭建一个高可用的Nacos集群，是保障微服务架构稳定性的基础操作。

这个操作听起来简单，不就是多跑几个Pod吗？但实际做起来，你会发现从存储选型、网络配置到集群发现，每一步都有讲究。比如，Nacos集群节点间需要相互通信以同步数据，在k8s的动态网络环境下，如何让它们稳定地发现彼此？再比如，Nacos支持多种存储模式，是选择内置的Derby数据库，还是外置的MySQL集群？不同的选择直接关系到集群的数据一致性和运维复杂度。今天，我就结合自己多次在生产环境部署的经验，手把手带你走一遍在k8s上搭建Nacos集群的完整流程，并重点剖析那些容易踩坑的细节。我们的目标不仅仅是“跑起来”，而是要搭建一个稳定、可观测、易于运维的生产级Nacos集群。

2. 架构设计与核心组件选型

在动手写YAML之前，我们必须先想清楚架构。一个典型的k8s化Nacos集群，核心在于解决三个问题：状态持久化、服务发现与负载均衡。

2.1 存储方案：为什么选择MySQL集群模式？

Nacos支持两种存储模式：嵌入式数据库（Apache Derby）和外部数据库（如MySQL）。对于单机模式，Derby足够简单。但在集群模式下，每个Nacos节点如果都使用内置的Derby，数据将无法在各节点间共享，这会导致配置信息不一致，集群也就失去了意义。

因此，生产环境必须使用外部共享数据库。通常我们选择MySQL，并且为了保证数据库本身的高可用，建议使用MySQL的主从复制集群或云上的RDS服务。这样，所有Nacos节点都连接到同一个MySQL数据库，数据自然就实现了统一存储和一致性。这是整个集群搭建的基石。

注意：Nacos对MySQL版本有要求，通常需要5.7及以上。同时，需要提前在MySQL中创建名为nacos的数据库，并执行Nacos发行包中conf目录下的mysql-schema.sql脚本来初始化表结构。这一步务必提前完成。

2.2 服务发现：StatefulSet与Headless Service的黄金组合

在k8s中部署有状态集群，首选的控制器是StatefulSet，而不是Deployment。为什么？因为StatefulSet能为我们提供稳定的网络标识和持久化存储。

• 稳定的网络标识：StatefulSet创建的Pod名称是固定的、有序的（如nacos-0,nacos-1,nacos-2）。更重要的是，我们可以通过一个Headless Service（无头服务）为这些Pod提供稳定的DNS域名。每个Pod都会获得一个唯一的域名：<pod-name>.<svc-name>.<namespace>.svc.cluster.local。例如，nacos-0.nacos-headless.default.svc.cluster.local。这样，Nacos节点在启动时，就能通过预定义的规则（如拼接域名列表）准确地找到集群中的其他伙伴。
• 稳定的存储：StatefulSet可以关联PVC（持久卷声明），为每个Pod实例提供独立的持久化存储。即使Pod被重新调度到其他节点，它的数据也会跟着“走”。这对于存储一些本地缓存（虽然不是核心数据）和日志是有帮助的。

2.3 对外暴露：多种Service类型的选择

集群内部通信解决了，还需要让外部的微服务应用能够访问到Nacos服务器。这里通常有两种模式：

1. ClusterIP + Ingress：为Nacos集群创建一个普通的ClusterIP类型的Service，然后通过Ingress（如Nginx Ingress Controller）配置域名和路由规则，将流量分发到后端Pod。这是最常用、最灵活的方式，便于统一管理网关和SSL证书。
2. NodePort：在测试或简单环境中，可以直接使用NodePort类型的Service，它会将服务映射到每个Node的某个端口上。这种方式不推荐用于生产，因为需要管理防火墙和端口，且缺乏高级路由能力。

在我们的部署中，会同时创建两个Service：一个Headless Service用于集群内部发现，一个ClusterIP Service用于对外提供统一访问入口。

3. 实战部署：从YAML编写到集群启动

理论清晰后，我们开始动手。这里我提供一个经过生产验证的Kubernetes资源配置清单。假设我们的命名空间是middleware，计划部署3个节点的Nacos集群。

3.1 配置文件详解：ConfigMap

首先，我们需要将Nacos的集群配置通过ConfigMap来管理，这样比直接写在镜像命令或环境变量中更清晰、更易维护。

apiVersion: v1 kind: ConfigMap metadata: name: nacos-cluster-config namespace: middleware data: # 关键配置：集群成员列表。这里利用了StatefulSet的Pod域名规则。 # `nacos-0.nacos-headless`, `nacos-1.nacos-headless`, `nacos-2.nacos-headless` 就是三个Pod的稳定域名。 cluster.conf: | 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 # 应用配置文件，这里主要设置存储模式为MySQL，并关闭权限校验（生产环境建议开启并配置）。 application.properties: | # 启用数据持久化到外部数据库 spring.datasource.platform=mysql # 数据库实例数量，通常为1 db.num=1 # 数据库连接信息，以下值仅为示例，真实密码应通过Secret管理 db.url.0=jdbc:mysql://your-mysql-cluster-address:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC db.user.0=nacos db.password.0=your_strong_password_here # 是否开启权限认证，测试可关闭，生产必须开启 nacos.core.auth.enabled=false # 其他性能参数可根据需要调整 server.tomcat.accesslog.enabled=true server.tomcat.accesslog.pattern=%h %l %u %t "%r" %s %b %D management.endpoints.web.exposure.include=*

重要提示：数据库密码等敏感信息绝不应该明文写在ConfigMap中。上述示例仅为演示。生产环境中，db.password.0等字段应使用占位符，如${MYSQL_PASSWORD}，然后在Pod的环境变量中通过valueFrom.secretKeyRef从Kubernetes Secret中读取。这是安全部署的基本要求。

3.2 无头服务：Headless Service

创建Headless Service，用于为StatefulSet的Pod提供稳定的DNS域名。

apiVersion: v1 kind: Service metadata: name: nacos-headless namespace: middleware labels: app: nacos spec: clusterIP: None # 这就是定义Headless Service的关键 ports: - port: 8848 name: server - port: 9848 name: raft-rpc # Nacos 2.0 新增的Raft协议通信端口 - port: 9849 name: grpc # Nacos 2.0 新增的gRPC通信端口 selector: app: nacos

3.3 对外服务：ClusterIP Service

创建对外提供访问的Service，微服务应用将通过这个Service的域名或IP来访问Nacos集群。

apiVersion: v1 kind: Service metadata: name: nacos namespace: middleware labels: app: nacos spec: type: ClusterIP ports: - port: 8848 targetPort: 8848 name: server selector: app: nacos

3.4 有状态应用：StatefulSet

这是最核心的部分。我们定义StatefulSet来创建3个Nacos Pod实例。

apiVersion: apps/v1 kind: StatefulSet metadata: name: nacos namespace: middleware spec: serviceName: nacos-headless # 必须指向前面创建的Headless Service replicas: 3 selector: matchLabels: app: nacos template: metadata: labels: app: nacos spec: # 如果使用主机网络或需要特定亲和性，可在此配置 # hostNetwork: true # nodeSelector: # node-type: middleware containers: - name: nacos image: nacos/nacos-server:v2.2.3 # 建议使用特定稳定版本，而非latest imagePullPolicy: IfNotPresent ports: - containerPort: 8848 name: server - containerPort: 9848 name: raft-rpc - containerPort: 9849 name: grpc env: # 传递MySQL密码等敏感信息，从Secret读取 - name: MYSQL_SERVICE_HOST value: "your-mysql-cluster-address" - name: MYSQL_SERVICE_DB_NAME value: "nacos" - name: MYSQL_SERVICE_USER value: "nacos" - name: MYSQL_SERVICE_PASSWORD valueFrom: secretKeyRef: name: nacos-mysql-secret # 假设你已创建名为nacos-mysql-secret的Secret key: password # Nacos 2.0 重要参数：指定集群节点IP。这里使用Pod IP。 - name: NACOS_SERVER_IP valueFrom: fieldRef: fieldPath: status.podIP # Nacos 2.0 重要参数：集群成员列表，与ConfigMap中的cluster.conf对应 - 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内存参数，根据机器配置调整 - name: JVM_XMS value: "1g" - name: JVM_XMX value: "1g" - name: JVM_XMN value: "512m" resources: requests: memory: "2Gi" cpu: "500m" limits: memory: "4Gi" cpu: "1000m" volumeMounts: - name: nacos-config mountPath: /home/nacos/conf - name: nacos-logs mountPath: /home/nacos/logs # 健康检查，确保Pod就绪和存活 livenessProbe: httpGet: path: /nacos/actuator/health port: 8848 initialDelaySeconds: 60 # Nacos启动较慢，延迟检查 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /nacos/actuator/health port: 8848 initialDelaySeconds: 30 periodSeconds: 5 volumeClaimTemplates: # StatefulSet特有，为每个Pod动态创建PVC - metadata: name: nacos-logs spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "standard" # 替换为你集群中可用的StorageClass resources: requests: storage: 10Gi volumes: - name: nacos-config configMap: name: nacos-cluster-config

3.5 执行部署与验证

将以上YAML文件保存（例如nacos-cluster.yaml），然后执行部署命令：

kubectl apply -f nacos-cluster.yaml

接下来，观察部署状态：

# 查看Pod启动情况，直到所有Pod都进入Running状态 kubectl get pods -n middleware -l app=nacos -w # 查看Service kubectl get svc -n middleware -l app=nacos # 查看StatefulSet kubectl get sts -n middleware

当所有Pod都就绪后，我们可以通过端口转发临时访问Nacos控制台进行验证：

kubectl port-forward -n middleware svc/nacos 8848:8848

然后在浏览器中访问http://localhost:8848/nacos，默认账号密码是nacos/nacos。进入控制台后，点击顶部菜单栏的“集群管理” -> “节点列表”。你应该能看到三个节点，它们的IP地址分别是各自Pod的IP，且状态均为“健康”。这证明集群内部通信正常，节点已成功组成集群。

4. 关键配置解析与深度避坑指南

部署成功只是第一步，要让集群稳定运行，必须理解几个关键配置点，这些地方最容易出问题。

4.1 NACOS_SERVER_IP 与网络模式的选择

这是Nacos 2.x版本集群搭建中最容易踩的坑。环境变量NACOS_SERVER_IP必须正确设置，它告诉Nacos实例：“我自己的地址是什么”。在k8s中，通常有几种选择：

1. 使用Pod IP（推荐）：如上文YAML所示，通过status.podIP自动注入。这是最通用和推荐的方式，兼容各种网络插件（Calico, Flannel等）。
2. 使用主机网络（HostNetwork）：在Pod spec中设置hostNetwork: true，这样Pod会直接使用宿主机网络命名空间，其IP就是Node的IP。此时NACOS_SERVER_IP可以设置为$(HOST_IP)或通过Downward API获取status.hostIP。
   • 优点：网络性能最好，避免了一层Overlay网络转发。
   • 缺点：端口冲突风险高（每个Node上只能运行一个占用8848端口的Nacos Pod），且Pod失去了k8s网络策略的隔离保护。
   • 建议：除非对网络性能有极致要求且能妥善管理端口，否则不推荐。

踩坑实录：我曾遇到在Calico网络环境下，未显式设置NACOS_SERVER_IP，Nacos实例启动后默认使用了Pod内部的一个回环地址（如127.0.0.1），导致集群其他节点无法与之通信，节点列表里永远只有一个“健康”节点，其他节点反复报连接失败。所以，务必显式、正确地设置这个参数。

4.2 多网卡与IP选择问题

在一些云环境或特殊网络配置的k8s集群中，Node或Pod可能拥有多个IP地址（如内网IP、公网IP、隧道IP等）。如果通过status.podIP获取到的IP不是集群内部可路由的IP，就会导致通信失败。

排查思路：

1. 进入Pod内部，执行hostname -i或ifconfig，查看容器内识别的IP。
2. 在另一个Pod中，尝试ping或curl这个IP，看是否通。
3. 如果不通，需要检查k8s CNI网络插件的配置，或者考虑使用Downward API获取特定的Pod IP字段（如果CNI插件支持注解特定IP）。更直接的方法是，如果Pod有固定的标签或注解包含了正确IP，可以通过环境变量fieldRef.fieldPath读取metadata.annotations['自定义注解']。

4.3 Nacos 2.0 新增端口的处理

Nacos 1.x 版本集群通信主要使用8848端口。从Nacos 2.0开始，为了提升性能和一致性，引入了基于Raft的分布式协议，新增了两个核心端口：

• 9848：用于节点间RPC通信（Jraft）。
• 9849：用于gRPC通信，处理客户端连接（如Nacos 2.0客户端）。

这意味着：

• 在Service（无论是Headless还是ClusterIP）的定义中，必须暴露这两个端口，否则集群内部通信和部分客户端连接会失败。
• 如果集群节点部署在不同网络域（如跨防火墙），需要确保这三个端口（8848, 9848, 9849）在节点间是互通的。
• 在我们的YAML中，已经在Service和StatefulSet的容器端口部分明确定义了这三个端口。

4.4 存储与数据一致性终极保障

虽然我们使用了共享的MySQL来保证配置数据的一致性，但Nacos的服务注册信息（即服务实例列表）在2.0版本默认是存储在内存中，并通过Raft协议在集群节点间同步的。这是一种最终一致性模型。

这里存在一个风险：如果整个Nacos集群所有节点同时宕机并重启，内存中的服务注册数据会丢失。虽然客户端有重试和缓存机制，但这会导致服务列表的短暂清空，对调用链造成冲击。

解决方案与建议：

1. 启用持久化服务元数据（推荐）：在Nacos 2.2及以上版本，可以通过配置开启服务数据的持久化。在application.properties中添加nacos.naming.data.warmup=true和nacos.naming.data.distro.sync.retryDelay=5000等参数，并确保存储目录（如/home/nacos/data）被持久化卷挂载。这样即使集群全重启，也能从磁盘恢复服务数据。
2. 优雅上下线：在滚动更新或重启Nacos集群前，先通过k8s的preStop钩子，让Nacos Pod在终止前主动从集群中注销自己，减少对客户端的影响。
3. 客户端容错：确保微服务客户端（如Spring Cloud Alibaba Nacos Client）配置了合适的重试机制和本地缓存，以应对注册中心的短暂不可用。

5. 生产环境运维与监控建议

集群跑起来后，运维和监控才是持久战。

5.1 资源限制与弹性伸缩

务必在StatefulSet中配置resources.requests和resources.limits。Nacos在内存使用上，尤其是服务实例数量庞大时，增长会比较明显。根据经验，一个中等规模的微服务系统（数百个服务，数千个实例），每个Nacos节点分配2-4GiB内存是合理的起点。CPU请求可以设置为0.5-1核。

可以通过Horizontal Pod Autoscaler (HPA)基于CPU或内存使用率对StatefulSet进行自动扩缩容。但注意，由于Nacos是有状态应用，缩容需谨慎，避免直接删除持有数据的Pod（如nacos-0）。通常更安全的做法是固定副本数。

5.2 日志与监控接入

• 日志：我们将/home/nacos/logs目录挂载到了持久化存储上。建议使用EFK（Elasticsearch, Fluentd, Kibana）或Loki+Grafana等方案，收集这些日志，便于问题排查。
• 监控：Nacos原生集成了Micrometer，暴露了丰富的Actuator端点（我们在ConfigMap中通过management.endpoints.web.exposure.include=*开启了）。可以将这些指标（/nacos/actuator/prometheus）接入Prometheus，然后在Grafana中配置官方或社区提供的Nacos监控大盘，实时监控节点状态、连接数、配置/服务数量、JVM状态等关键指标。

5.3 版本升级与数据备份

• 升级：升级Nacos版本时，务必先查阅官方Release Notes，确认是否有不兼容的变更。升级流程建议：1) 备份数据库；2) 逐个Pod进行滚动更新，并密切观察集群健康度和客户端连接。
• 备份：定期备份MySQL中的nacos数据库。这是配置数据的唯一来源，至关重要。可以结合cronjob和云数据库的备份功能实现自动化。

5.4 安全加固

1. 开启认证：生产环境必须将nacos.core.auth.enabled设置为true，并配置自定义的nacos.core.auth.server.identity.key和nacos.core.auth.server.identity.value。同时为不同团队或应用创建独立的账号和角色，分配最小必要权限。
2. 网络策略：使用Kubernetes NetworkPolicy限制对Nacos Service（尤其是8848、9848、9849端口）的访问来源，只允许特定的应用命名空间或网关访问。
3. TLS传输：对于安全性要求极高的环境，可以考虑为Nacos配置TLS证书，启用HTTPS和gRPC over TLS。这需要修改server配置和客户端连接地址。

搭建k8s上的Nacos集群，就像为微服务体系搭建了一个“总机电话局”。它看似只是几个Pod的组合，但细节决定稳定性。从正确的存储选型、精准的网络标识配置，到理解2.0版本的新端口和一致性模型，每一步都需要结合k8s的特性和Nacos的原理来思考。我最深的一个体会是：一定要在测试环境模拟各种故障场景，比如随机杀掉一个Pod、重启整个StatefulSet、模拟网络分区，观察集群的恢复情况和服务客户端的表现。只有这样，你才能对这套部署方案的健壮性有真正的信心，也才能在生产环境故障发生时，做到心中有数，快速响应。