企业官网建设流程全解析

简介：本资源是一套面向Kubernetes初学者与运维人员的Nacos高可用集群部署脚本，专为简化云原生环境下服务发现与配置中心的落地而设计。针对传统Nacos K8s部署中配置繁杂、StatefulSet与Headless Service联动易错等痛点，提供开箱即用的极简YAML方案，覆盖数据库配置、无头服务、有状态应用编排、ClusterIP服务暴露及Ingress入口全链路，小白按序执行即可完成生产级部署。压缩包共6个文件（5个核心YAML配置文件 + 1份说明文档），总大小仅3KB，轻量紧凑；其中ConfigMap定义MySQL连接参数，Headless Service支撑Nacos节点间通信，StatefulSet保障副本有序启停，Service与Ingress实现内外网访问闭环。目前已有763人学习下载，适合快速搭建测试环境、理解Nacos在K8s中的典型部署模式，或作为企业级微服务基础设施的参考模板。

1. 为什么你写的 Nacos 集群 YAML 在 K8s 里总起不来？——这不是配置问题，是部署逻辑没对齐

“k8s nacos集群部署脚本yaml”这个搜索词背后，藏着大量真实翻车现场：Pod 卡在Init:0/1、Nacos 节点互相发现失败、配置中心写入后不生效、升级时整个集群脑裂……根本原因不是 YAML 写错了，而是把「单机启动脚本」硬套进「云原生有状态服务」的范式里。Nacos 不是无状态 Web 服务，它依赖三重强一致性保障：节点间通信（Raft）、配置元数据持久化（MySQL 或嵌入式 Derby）、以及服务注册状态的本地快照同步。K8s 原生的 Deployment + Service 模式天然破坏这三者——比如滚动更新时旧 Pod 还没退出，新 Pod 就已加入集群，Raft 投票数瞬间失衡；又比如用 emptyDir 存配置，Pod 重建后所有服务实例全丢。本文不讲 Nacos 架构原理，只聚焦一个目标：用一套可复现、可验证、带边界说明的 YAML 组合，在标准 K8s v1.22+ 环境中跑通真正可用的 Nacos 2.3.x 集群。适合正在搭建微服务基础设施的 DevOps 工程师、需要快速交付稳定配置中心的 SRE，以及被“Nacos 高可用”文档绕晕的 Java 后端。我们跳过 Helm Chart 的黑盒封装，从 StatefulSet 控制器、Headless Service、PersistentVolumeClaim 绑定策略、JVM 参数与容器内存限制的协同关系开始，一帧一帧还原生产级部署的最小闭环。

2. 用 StatefulSet + Headless Service 跑通 Nacos 3 节点集群：最小可运行 YAML 拆解

Nacos 集群必须满足两个刚性条件：节点名固定可解析、启动顺序可控、存储独立不共享。Deployment 无法保证 Pod 名称稳定（nacos-5f8b9d7c4-2xqz9这类随机后缀会破坏nacos-0.nacos-headless.default.svc.cluster.local的 DNS 解析），也无法控制 Pod 启动/终止顺序（Raft 要求 leader 先就位）。StatefulSet 是唯一正解。下面给出经实测的最小可用 YAML 集合（不含 MySQL 外置部分，先用嵌入式 Derby 验证集群逻辑）。

2.1 创建 Headless Service：让 Nacos 节点能互相发现

# nacos-headless-svc.yaml apiVersion: v1 kind: Service metadata: name: nacos-headless namespace: default spec: clusterIP: None # 关键：禁用 ClusterIP，启用 DNS A 记录直出 publishNotReadyAddresses: true # 关键：允许未就绪 Pod 的 DNS 记录提前注册（避免启动时解析失败） ports: - port: 8848 name: client - port: 7848 name: raft selector: app: nacos

提示：publishNotReadyAddresses: true是血泪经验。Nacos 启动需 10~20 秒加载配置、初始化 Raft 日志，若 DNS 只返回就绪 Pod，nacos-0启动时查不到nacos-1和nacos-2，直接卡死在 “waiting for peer list”。此参数让所有 Pod 的 DNS 记录在创建即刻生效，无论 Ready 状态。

2.2 定义 StatefulSet：控制启动顺序与网络身份

# nacos-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: nacos namespace: default spec: serviceName: "nacos-headless" # 必须匹配 Headless Service 名 replicas: 3 podManagementPolicy: OrderedReady # 关键：严格按 0→1→2 顺序启动，且前一个 Ready 后才启下一个 updateStrategy: type: RollingUpdate rollingUpdate: partition: 3 # 关键：初始设为 3，禁止自动滚动更新（防脑裂），后续升级时手动调小 selector: matchLabels: app: nacos template: metadata: labels: app: nacos spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nacos topologyKey: "kubernetes.io/hostname" containers: - name: nacos image: nacos/nacos-server:v2.3.2 ports: - containerPort: 8848 name: client - containerPort: 7848 name: raft env: - name: MODE value: "cluster" - name: NACOS_SERVERS value: "nacos-0.nacos-headless.default.svc.cluster.local:8848 nacos-1.nacos-headless.default.svc.cluster.local:8848 nacos-2.nacos-headless.default.svc.cluster.local:8848" - name: PREFER_HOST_MODE value: "hostname" - name: NACOS_APPLICATION_PORT value: "8848" - name: JVM_XMS value: "1g" - name: JVM_XMX value: "1g" resources: requests: memory: "1Gi" cpu: "500m" limits: memory: "1.5Gi" # 关键：limit > request，防 OOMKill 后 JVM 无法优雅退出 cpu: "1" livenessProbe: httpGet: path: /actuator/health port: 8848 initialDelaySeconds: 60 periodSeconds: 30 timeoutSeconds: 5 readinessProbe: httpGet: path: /actuator/health port: 8848 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 3 volumeMounts: - name: nacos-data mountPath: /home/nacos/data - name: nacos-logs mountPath: /home/nacos/logs volumes: - name: nacos-data emptyDir: {} - name: nacos-logs emptyDir: {}

关键参数说明：

• podManagementPolicy: OrderedReady：确保nacos-0完全就绪（readinessProbe 成功）后，才创建nacos-1，依此类推。这是 Raft 集群形成的基础。
• updateStrategy.rollingUpdate.partition: 3：初始设为副本数，等同于冻结更新。生产环境升级必须手动kubectl patch statefulset nacos -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":2}}}}'，再逐个滚动nacos-2→nacos-1→nacos-0，避免多数派中断。
• resources.limits.memory: "1.5Gi"：Nacos JVM 默认-Xms1g -Xmx1g，但容器 runtime 本身、Linux page cache、Nacos 自身 native 内存（Netty direct buffer）会额外占用。若 limit = request = 1Gi，极易触发 OOMKill，导致 Pod 被强制终止而 Raft 状态丢失。
• livenessProbe.initialDelaySeconds: 60：Nacos 启动慢，尤其首次加载内置 Derby 数据库时可能超 45 秒。设太短会导致 probe 失败，反复重启。

2.3 验证集群是否真正就绪：不只是看 Pod Running

仅kubectl get pods显示Running不代表集群可用。必须验证三层状态：

1. DNS 解析层：

   kubectl exec -it nacos-0 -- nslookup nacos-headless # 应返回三条 A 记录：nacos-0.nacos-headless, nacos-1.nacos-headless, nacos-2.nacos-headless

2. Nacos 内部节点视图层：

   kubectl exec -it nacos-0 -- curl -s "http://localhost:8848/nacos/v1/ns/operator/metrics" | jq '.servers' # 正确响应示例：[{"ip":"nacos-0.nacos-headless.default.svc.cluster.local:8848","state":"UP"},{"ip":"nacos-1...","state":"UP"},{"ip":"nacos-2...","state":"UP"}]

3. Raft 一致性层（最核心）：

   kubectl exec -it nacos-0 -- curl -s "http://localhost:8848/nacos/v1/ns/operator/raft/state" | jq '{raftGroupMemberCount,raftState,leader}' # 正确响应：{"raftGroupMemberCount":3,"raftState":"FOLLOWER","leader":"nacos-0.nacos-headless.default.svc.cluster.local:7848"} # 注意：leader 字段必须是非空字符串，且三个 Pod 中仅一个返回 "LEADER"，其余为 "FOLLOWER"

若第 3 步失败（如全部为 FOLLOWER 或 leader 字段为空），说明 Raft 集群未形成，大概率是NACOS_SERVERS环境变量中的域名无法互通，或publishNotReadyAddresses未开启导致 DNS 解析延迟。

3. 从嵌入式 Derby 切到外置 MySQL：YAML 中必须改的 5 个位置

用嵌入式 Derby 仅用于验证集群通信逻辑。生产环境必须切换 MySQL，否则存在单点故障、数据无法备份、性能瓶颈三大硬伤。但直接替换application.properties不够——Nacos 启动流程中，数据库连接初始化早于 Spring Context 加载，因此必须通过 JVM 参数或环境变量注入，而非 ConfigMap 挂载配置文件。

3.1 创建 MySQL Secret：安全传递凭证

# nacos-mysql-secret.yaml apiVersion: v1 kind: Secret metadata: name: nacos-mysql-secret namespace: default type: Opaque data: MYSQL_SERVICE_HOST: bXlzcWwtaGVhZGxlc3Muc2VydmljZS5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2Fs # base64 of "mysql-headless.default.svc.cluster.local" MYSQL_SERVICE_PORT: ODQ0Mw== # base64 of "3306" MYSQL_SERVICE_DB_NAME: bmFjb3M= # base64 of "nacos" MYSQL_SERVICE_USER: cm9vdA== # base64 of "root" MYSQL_SERVICE_PASSWORD: cGFzc3dvcmQxMjM= # base64 of "password123"

注意：Secret 的data字段必须是 base64 编码。不要用stringData（非加密明文），生产环境必须用data。

3.2 修改 StatefulSet：注入 MySQL 连接参数

在nacos-statefulset.yaml的containers.env下追加以下 5 个环境变量（覆盖默认 Derby 配置）：

- name: MYSQL_SERVICE_HOST valueFrom: secretKeyRef: name: nacos-mysql-secret key: MYSQL_SERVICE_HOST - name: MYSQL_SERVICE_PORT valueFrom: secretKeyRef: name: nacos-mysql-secret key: MYSQL_SERVICE_PORT - name: MYSQL_SERVICE_DB_NAME valueFrom: secretKeyRef: name: nacos-mysql-secret key: MYSQL_SERVICE_DB_NAME - name: MYSQL_SERVICE_USER valueFrom: secretKeyRef: name: nacos-mysql-secret key: MYSQL_SERVICE_USER - name: MYSQL_SERVICE_PASSWORD valueFrom: secretKeyRef: name: nacos-mysql-secret key: MYSQL_SERVICE_PASSWORD

同时，必须删除NACOS_SERVERS中的空格分隔写法（Nacos 2.3+ 对空格敏感），改用换行符分隔（通过valueFrom.configMapKeyRef注入）：

# 新增 ConfigMap：nacos-servers-cm.yaml apiVersion: v1 kind: ConfigMap metadata: name: nacos-servers-cm namespace: default data: nacos.servers: | nacos-0.nacos-headless.default.svc.cluster.local:8848 nacos-1.nacos-headless.default.svc.cluster.local:8848 nacos-2.nacos-headless.default.svc.cluster.local:8848

然后在 StatefulSet 中引用：

- name: NACOS_SERVERS valueFrom: configMapKeyRef: name: nacos-servers-cm key: nacos.servers

3.3 初始化 MySQL 数据库：执行官方 SQL 脚本

Nacos 官方 GitHub 仓库中config/src/main/resources/mysql-schema.sql是唯一可信来源。不要用网上流传的简化版。执行方式（以本地 kubectl proxy 为例）：

# 1. 启动临时 MySQL 客户端 kubectl run mysql-client --image=mysql:8.0.33 -it --rm --restart=Never \ --env="MYSQL_ROOT_PASSWORD=password123" \ -- bash -c "mysql -h mysql-headless.default.svc.cluster.local -P 3306 -uroot -ppassword123 -e 'CREATE DATABASE IF NOT EXISTS nacos CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;'" # 2. 执行建表语句（需提前下载 mysql-schema.sql 到本地） kubectl cp ./mysql-schema.sql mysql-client:/tmp/ kubectl exec -it mysql-client -- mysql -h mysql-headless.default.svc.cluster.local -P 3306 -uroot -ppassword123 nacos < /tmp/mysql-schema.sql

玄学提示：mysql-schema.sql中config_info_aggr表的gmt_modified字段默认为CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，但在某些 MySQL 版本下会报错。若执行失败，手动编辑 SQL，将该字段改为DEFAULT CURRENT_TIMESTAMP即可。这不是 bug，是 MySQL 5.7 与 8.0 的 TIMESTAMP 行为差异。

4. 避坑：Nacos 集群在 K8s 中的 4 个高频翻车点与修复方案

部署 Nacos 集群不是拼凑 YAML，而是和 K8s 调度器、网络插件、内核参数、JVM 机制持续博弈的过程。以下是某公司线上环境踩过的 4 个真实坑，每一条都附带可验证的现象、根因定位方法和落地修复命令。

4.1 现象：Pod 反复 CrashLoopBackOff，日志显示java.lang.OutOfMemoryError: Direct buffer memory

• 原因：Netty 使用堆外内存（Direct Buffer）处理网络请求，默认大小为 64MB。当 Nacos 集群节点多、客户端连接猛增时，Direct Buffer 耗尽，但 JVM Heap 仍有余量，-Xmx限制不生效，OOMKill 直接干掉容器。
• 验证：kubectl logs nacos-0 | grep "Direct buffer"；或进入容器jcmd 1 VM.native_memory summary查看Internal (reserved=... committed=...)是否远超 64MB。
• 解决：在 StatefulSet 的env中添加 JVM 参数：

  - name: JVM_OPT value: "-XX:MaxDirectMemorySize=256m"

  同时确保resources.limits.memory≥JVM_XMX + MaxDirectMemorySize + 256MB（预留 OS 与 page cache）。

4.2 现象：nacos-0一直是 leader，nacos-1和nacos-2长期处于FOLLOWER但lastHeartbeatTime停滞，/nacos/v1/ns/operator/raft/state返回"leader": ""

• 原因：K8s Node 节点时间不同步。Raft 协议要求所有节点时钟误差 < 500ms，否则心跳超时判定失效。ntpd或chrony未在宿主机启用，或容器内/etc/timezone与宿主机不一致。
• 验证：kubectl exec nacos-0 -- date; kubectl exec nacos-1 -- date; kubectl exec nacos-2 -- date，对比毫秒级时间差；或kubectl debug node/<node-name> -it --image=busybox --share-processes进入节点查chronyc tracking。
• 解决：
  1. 宿主机启用 chrony 并指向可靠 NTP 服务器；
  2. StatefulSet 中添加securityContext.hostPID: true和hostNetwork: true（不推荐）或更稳妥的——挂载宿主机/etc/localtime：

     volumeMounts: - name: tz-config mountPath: /etc/localtime readOnly: true volumes: - name: tz-config hostPath: path: /etc/localtime

4.3 现象：集群能启动，但服务注册后不持久，重启任意 Pod 后服务列表清空

• 原因：使用了emptyDir存储data目录，而 Nacos 的derby数据库文件（data/derby-data）和nacos-core的 Raft snapshot（data/protocol/raft/naming/）均落在此目录。Pod 删除即数据销毁。
• 验证：kubectl exec nacos-0 -- ls -l /home/nacos/data/derby-data/，若目录为空或只有.lock文件，说明 Derby 未成功初始化（常因权限问题）；若目录有文件但重启后消失，确认是emptyDir。
• 解决：必须用 PVC。为每个 Pod 分配独立 PV（推荐 NFS 或云厂商 CSI 驱动）：

  volumeClaimTemplates: - metadata: name: nacos-data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 5Gi storageClassName: "nfs-client" # 替换为你的 StorageClass

  并删除volumes下的emptyDir定义，volumeMounts保持不变。

4.4 现象：kubectl get endpoints nacos-headless显示 IP 正确，但curl http://nacos-0.nacos-headless:8848/nacos/v1/ns/service/list返回 404 或空数组

• 原因：Nacos 2.3+ 默认开启鉴权（nacos.core.auth.enabled=true），但未配置 token 或用户，导致所有 HTTP 接口返回 401/404（伪装成 404）。
• 验证：kubectl logs nacos-0 | grep "auth"，若出现AuthFilter doFilter或no auth token，即命中。
• 解决：关闭鉴权（测试环境）或配置 JWT 密钥（生产环境）。测试环境添加：

  - name: NACOS_AUTH_ENABLE value: "false"

  生产环境则需生成密钥并挂载：

  openssl rand -base64 32 > jwt-key.txt kubectl create secret generic nacos-jwt-secret --from-file=jwt-key.txt

  再在 env 中添加：

  - name: NACOS_AUTH_TOKEN valueFrom: secretKeyRef: name: nacos-jwt-secret key: jwt-key.txt

5. 生产就绪检查清单：5 项必须做的验证与 3 个不可妥协的配置

部署完成不等于可用。我经手的 12 个 Nacos 集群项目中，7 个在上线后 48 小时内暴露出隐性缺陷。以下是我固化在 CI/CD 流水线中的 5 项自动化验证，以及 3 个写死在团队规范里的硬性配置。它们不炫技，但能拦住 90% 的线上事故。

5.1 5 项必须做的验证（建议写成 Bash 脚本接入 GitOps）

提示：以上脚本应集成到 Argo CD 的PostSyncHook 或 Jenkins Pipeline 的deploy-and-validate阶段。任何一项失败，自动回滚并告警。

5.2 3 个不可妥协的配置（写死在团队 YAML 模板中）

1. podAntiAffinity必须用requiredDuringSchedulingIgnoredDuringExecution
   不能用preferredDuringSchedulingIgnoredDuringExecution。后者只是“尽量不调度到同一节点”，而 Nacos 集群节点共存于一节点时，CPU 争抢会导致 Raft 心跳超时，引发频繁 leader 选举。某次压测中，2 节点同机导致 3 分钟内选举 17 次，服务注册成功率跌至 42%。

2. volumeClaimTemplates的storageClassName必须显式指定
   禁止依赖defaultStorageClass。不同集群的default可能指向 HDD（慢盘）或 Local PV（无高可用）。Nacos 的data/protocol/raft/目录是 Raft 日志落盘路径，IOPS 不足会导致appendEntries延迟，直接拖垮集群吞吐。我们统一要求storageClassName: "ssd-prod"，并通过准入控制器（ValidatingWebhook）拦截未指定 SC 的提交。

3. livenessProbe的failureThreshold必须 ≥ 5
   Nacos 启动后需加载全量配置、初始化 Raft Log、同步服务实例，首分钟内 CPU 占用常达 90%+，probe 可能偶发超时。若failureThreshold: 3，三次超时即重启，形成恶性循环。我们固定设为failureThreshold: 6，配合initialDelaySeconds: 60，给足冷启动窗口。

最后说一句个人习惯：我从不用kubectl apply -f *.yaml一键部署。而是分三步——先kubectl apply -f nacos-headless-svc.yaml，等kubectl get svc nacos-headless显示CLUSTER-IP: None；再kubectl apply -f nacos-mysql-secret.yaml；最后才kubectl apply -f nacos-statefulset.yaml。每步之间sleep 5，用kubectl wait等待资源就绪。看似笨拙，却让每一次部署都像拧紧一颗螺丝，而不是赌一把运气。希望帮到你。

本文还有配套的精品资源，点击获取