简介本资源面向需要在阿里云Kubernetes集群上落地前后端分离项目的开发与运维人员提供一套可直接参考的部署方案覆盖Vue2前端、Nginx反向代理、SpringBoot2.5后端以及Nacos2.0.3注册配置中心的完整编排。包内共16个文件以8个YAML清单为核心配合2个Shell部署脚本、2个Dockerfile、1份MySQL初始化SQL、1份Nginx配置、1个Jar包与1个前端压缩包压缩后约34.69MB结构清晰、按模块划分。内容涵盖Nacos的StatefulSet、Headless Service、Ingress与MySQL配置以及前后端应用的部署清单与镜像构建脚本便于读者对照理解各组件在K8s中的资源定义与依赖关系。已有1341人学习下载适合希望快速搭建微服务部署环境、梳理Nacos集群与网关接入思路的读者参考借鉴。1. 从一份能跑通的 K8s 部署清单说起Vue2、Spring Boot 2.5 与 Nacos 2.0.3 到底怎么串很多团队第一次把 Vue2 Nginx Spring Boot 2.5 Nacos 2.0.3 这套组合搬上 K8s 时都会经历一个相似的阶段本地 docker-compose 跑得好好的一进集群就开始出玄学问题——前端 502、后端连不上 Nacos、Pod 起来了但服务没注册。这套资源就是一份把四个组件在 K8s 里完整串起来的部署清单包含 Deployment、Service、ConfigMap、Ingress 以及 Nacos 的 StatefulSet 配置。它解决的不是“K8s 是什么”这种问题而是“这套具体版本组合怎么在集群里跑起来、参数怎么填、网络怎么通”。适合已经会写 Dockerfile、但对 K8s 编排还停留在 kubectl apply 阶段的后端和运维同学也适合想把单体应用平滑迁到集群的团队做参考基线。2. 镜像分层与构建Vue2 静态资源和 Spring Boot 2.5 的打包差异2.1 前端为什么用 Nginx 而不是 Node 直接跑Vue2 项目构建产物是纯静态文件用 Node 起服务在生产环境属于典型的资源浪费。常见做法是两阶段构建第一阶段用 node 镜像执行npm run build第二阶段把dist目录拷进 nginx 镜像。这样最终镜像只有几十 MB启动快也不需要在前端容器里装 node_modules。# 第一阶段构建 Vue2 静态资源 FROM node:14-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install --registryhttps://registry.npmmirror.com COPY . . RUN npm run build # 第二阶段Nginx 托管静态文件 FROM nginx:1.21-alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80逻辑说明--frombuilder只把构建产物带进最终镜像node_modules 和源码不会残留。参数上node 版本建议锁 14 或 16Vue2 在 node 18 上偶发 OpenSSL 报错这是血泪经验。nginx.conf 里要配try_files $uri $uri/ /index.html;否则前端路由刷新会 404。2.2 Spring Boot 2.5 镜像的层缓存优化Spring Boot 2.5 默认打包成 fat jar直接 COPY 进去会导致每次改代码都重建整个镜像层。常见做法是利用分层索引把依赖和业务代码分开。FROM openjdk:8-jre-slim WORKDIR /app COPY target/app.jar app.jar # 开启分层索引配合 spring-boot-maven-plugin 的 layers 配置 ENTRYPOINT [java, -jar, /app/app.jar, \ --spring.profiles.activek8s, \ --spring.cloud.nacos.discovery.server-addrnacos-svc:8848]参数说明--spring.profiles.activek8s用来加载集群专用配置避免把本地配置带进去。Nacos 地址用 Service 名而不是 IP这是 K8s 内部 DNS 的基本用法。注意 Spring Boot 2.5 对应 Spring Cloud 2020.0.xNacos 客户端版本要匹配 2.0.3 服务端版本错配会导致注册失败但日志不报错属于典型黑匣子问题。2.3 Nacos 2.0.3 的镜像与端口变化Nacos 2.0.3 相比 1.x 最大的变化是新增了 gRPC 端口。除了 8848 的 HTTP 端口还需要暴露 9848客户端 gRPC和 9849服务端 gRPC。很多人升级后服务注册不上就是因为只开了 8848。# nacos-statefulset.yaml 片段 ports: - containerPort: 8848 name: http - containerPort: 9848 name: client-grpc - containerPort: 9849 name: server-grpc逻辑说明9848 8848 10009849 8848 1001这是 Nacos 2.x 的固定偏移规则。如果改了 8848 端口gRPC 端口要同步调整。StatefulSet 配合 headless Service 保证每个 Pod 有稳定网络标识集群模式下三个节点互相通信靠的就是这个。3. K8s 编排落地Deployment、Service 与 Ingress 的参数怎么填3.1 后端 Deployment 的健康检查与优雅停机Spring Boot 在 K8s 里最容易翻车的地方是滚动更新时流量打到还没准备好的 Pod 上。必须配 readinessProbe 和 livenessProbe且路径要指向 actuator 的健康端点。apiVersion: apps/v1 kind: Deployment metadata: name: backend-deploy spec: replicas: 2 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: spec: containers: - name: backend image: registry.example.com/backend:v1 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30 periodSeconds: 10 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 60 periodSeconds: 15 lifecycle: preStop: exec: command: [sh, -c, sleep 10]参数说明maxUnavailable: 0保证更新期间可用副本不减少。initialDelaySeconds给 Spring Boot 启动留足时间2.5 版本冷启动通常 20 到 40 秒设太小会导致 Pod 被反复重启。preStop里的 sleep 是给 kube-proxy 更新转发规则留窗口不加的话会出现更新时少量 502。readiness 和 liveness 用不同端点避免启动慢被误杀。3.2 Service 与 Ingress 的流量路径前端 Nginx 和后端 Spring Boot 各配一个 ClusterIP ServiceIngress 按路径分流。/api转发到后端其余走前端。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/proxy-body-size: 20m spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: backend-svc port: number: 8080 - path: / pathType: Prefix backend: service: name: frontend-svc port: number: 80逻辑说明pathType: Prefix是 v1 版本的必填项不写会报错。proxy-body-size默认 1m文件上传场景必须调大否则大请求体直接被 Ingress 拒绝。前端 Nginx 里如果也配了/api的反向代理会和 Ingress 规则冲突建议只保留一层通常放在 Ingress 更利于统一管理。3.3 Nacos 集群的 StatefulSet 配置要点Nacos 集群模式需要外部数据库通常用 MySQL。StatefulSet 的每个 Pod 通过环境变量注入自己的序号拼出集群节点列表。env: - name: NACOS_SERVERS value: nacos-0.nacos-headless:8848 nacos-1.nacos-headless:8848 nacos-2.nacos-headless:8848 - name: SPRING_DATASOURCE_PLATFORM value: mysql - name: MYSQL_SERVICE_HOST value: mysql-svc - name: MYSQL_SERVICE_DB_NAME value: nacos_config参数说明nacos-headless是 headless Service 名Pod 序号通过 DNS 直接解析。数据库连接信息用环境变量注入不要硬编码在镜像里。Nacos 2.0.3 的集群健康检查依赖 gRPC 端口互通NetworkPolicy 如果开了要放行 9848 和 9849。4. 避坑排查这套组合在集群里最容易翻车的五个点4.1 服务注册不上Nacos 控制台看不到实例现象Spring Boot Pod 日志显示启动成功但 Nacos 控制台服务列表为空。原因Nacos 2.0.3 的 gRPC 端口 9848 没在 Service 里暴露或者客户端版本低于 2.0。解决检查 Service 的 ports 是否包含 9848确认 pom 里 nacos-discovery 版本与服务端一致用telnet nacos-svc 9848在 Pod 内验证连通性。4.2 前端刷新页面 404现象首页能打开点进子路由再刷新就 404。原因Nginx 没配 history 模式回退请求直接打到 Ingress 找不到对应路径。解决在 nginx.conf 的 location 里加try_files $uri $uri/ /index.html;同时确认 Ingress 的/路径指向前端 Service。4.3 滚动更新时出现短暂 502现象每次发版有几秒钟接口报 502。原因Pod 收到 SIGTERM 后立即停止接受新连接但 kube-proxy 还没更新转发规则。解决加 preStop sleep 10 秒同时 readinessProbe 在停机时先失败让 Endpoints 先摘除再停容器。这个顺序 K8s 会自动处理前提是配了 readinessProbe。4.4 Nacos 集群节点互相找不到现象三个 Nacos Pod 都起来了但集群状态异常配置推送失败。原因headless Service 没配clusterIP: None或者 NACOS_SERVERS 里的域名拼错。解决确认 headless Service 的 clusterIP 为 None用nslookup nacos-0.nacos-headless在 Pod 内验证 DNS 解析。4.5 镜像拉取失败 ImagePullBackOff现象Pod 一直卡在 ImagePullBackOff。原因私有仓库的 imagePullSecrets 没配或者镜像 tag 写成了 latest 导致节点缓存混乱。解决创建 docker-registry 类型的 Secret 并在 Deployment 里引用镜像 tag 用具体版本号禁止用 latest。节点上crictl pull手动拉一次能快速定位是网络问题还是认证问题。5. 进阶技巧用 ConfigMap 热更新 Nacos 配置与版本回滚验证5.1 把 Nacos 连接信息抽到 ConfigMap硬编码在 Deployment 里的 Nacos 地址改一次就要重新 apply常见做法是抽到 ConfigMap配合envFrom注入。这样换环境只改 ConfigMapDeployment 不动。apiVersion: v1 kind: ConfigMap metadata: name: app-config data: NACOS_ADDR: nacos-svc:8848 SPRING_PROFILES: k8s --- # Deployment 中引用 envFrom: - configMapRef: name: app-config逻辑说明envFrom会把 ConfigMap 所有 key 变成环境变量。注意 ConfigMap 更新后已运行的 Pod 不会自动重启需要配合kubectl rollout restart deployment/backend-deploy触发滚动更新。这是很多人以为改了 ConfigMap 就生效、结果发现没变化的常见误解。5.2 版本回滚的验证清单K8s 的kubectl rollout undo能回滚 Deployment但 Nacos 里的配置不会跟着回滚。我一般会按这个顺序验证步骤命令预期结果查看历史版本kubectl rollout history deployment/backend-deploy列出所有 revision回滚到指定版本kubectl rollout undo deployment/backend-deploy --to-revision2返回 rolled back观察滚动状态kubectl rollout status deployment/backend-deploy输出 successfully rolled out验证服务注册登录 Nacos 控制台查看实例数实例数与副本数一致验证接口curl Ingress 地址/api/health返回 200参数说明--to-revision不写默认回滚到上一个版本。回滚后要确认 Nacos 里的配置版本是否匹配如果新版本改了配置项回滚代码但配置没回滚会出现配置项缺失导致的启动失败。建议配置变更也走版本管理和代码版本对齐。5.3 一个我踩过的坑有次发版后回滚代码回去了但 Nacos 里的数据库连接串还是新的结果回滚后的 Pod 连不上库排查了半小时才反应过来。从那以后我每次回滚都强制走一遍配置核对把 Nacos 的配置版本和代码 tag 绑在一起记录。这套清单里我把 ConfigMap 和 Nacos 配置的对应关系写进了注释就是不想再吃这个亏。希望帮到你。本文还有配套的精品资源点击获取
简介本资源面向需要在阿里云Kubernetes集群上落地前后端分离项目的开发与运维人员提供一套可直接参考的部署方案覆盖Vue2前端、Nginx反向代理、SpringBoot2.5后端以及Nacos2.0.3注册配置中心的完整编排。包内共16个文件以8个YAML清单为核心配合2个Shell部署脚本、2个Dockerfile、1份MySQL初始化SQL、1份Nginx配置、1个Jar包与1个前端压缩包压缩后约34.69MB结构清晰、按模块划分。内容涵盖Nacos的StatefulSet、Headless Service、Ingress与MySQL配置以及前后端应用的部署清单与镜像构建脚本便于读者对照理解各组件在K8s中的资源定义与依赖关系。已有1341人学习下载适合希望快速搭建微服务部署环境、梳理Nacos集群与网关接入思路的读者参考借鉴。1. 从一份能跑通的 K8s 部署清单说起Vue2、Spring Boot 2.5 与 Nacos 2.0.3 到底怎么串很多团队第一次把 Vue2 Nginx Spring Boot 2.5 Nacos 2.0.3 这套组合搬上 K8s 时都会经历一个相似的阶段本地 docker-compose 跑得好好的一进集群就开始出玄学问题——前端 502、后端连不上 Nacos、Pod 起来了但服务没注册。这套资源就是一份把四个组件在 K8s 里完整串起来的部署清单包含 Deployment、Service、ConfigMap、Ingress 以及 Nacos 的 StatefulSet 配置。它解决的不是“K8s 是什么”这种问题而是“这套具体版本组合怎么在集群里跑起来、参数怎么填、网络怎么通”。适合已经会写 Dockerfile、但对 K8s 编排还停留在 kubectl apply 阶段的后端和运维同学也适合想把单体应用平滑迁到集群的团队做参考基线。2. 镜像分层与构建Vue2 静态资源和 Spring Boot 2.5 的打包差异2.1 前端为什么用 Nginx 而不是 Node 直接跑Vue2 项目构建产物是纯静态文件用 Node 起服务在生产环境属于典型的资源浪费。常见做法是两阶段构建第一阶段用 node 镜像执行npm run build第二阶段把dist目录拷进 nginx 镜像。这样最终镜像只有几十 MB启动快也不需要在前端容器里装 node_modules。# 第一阶段构建 Vue2 静态资源 FROM node:14-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install --registryhttps://registry.npmmirror.com COPY . . RUN npm run build # 第二阶段Nginx 托管静态文件 FROM nginx:1.21-alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80逻辑说明--frombuilder只把构建产物带进最终镜像node_modules 和源码不会残留。参数上node 版本建议锁 14 或 16Vue2 在 node 18 上偶发 OpenSSL 报错这是血泪经验。nginx.conf 里要配try_files $uri $uri/ /index.html;否则前端路由刷新会 404。2.2 Spring Boot 2.5 镜像的层缓存优化Spring Boot 2.5 默认打包成 fat jar直接 COPY 进去会导致每次改代码都重建整个镜像层。常见做法是利用分层索引把依赖和业务代码分开。FROM openjdk:8-jre-slim WORKDIR /app COPY target/app.jar app.jar # 开启分层索引配合 spring-boot-maven-plugin 的 layers 配置 ENTRYPOINT [java, -jar, /app/app.jar, \ --spring.profiles.activek8s, \ --spring.cloud.nacos.discovery.server-addrnacos-svc:8848]参数说明--spring.profiles.activek8s用来加载集群专用配置避免把本地配置带进去。Nacos 地址用 Service 名而不是 IP这是 K8s 内部 DNS 的基本用法。注意 Spring Boot 2.5 对应 Spring Cloud 2020.0.xNacos 客户端版本要匹配 2.0.3 服务端版本错配会导致注册失败但日志不报错属于典型黑匣子问题。2.3 Nacos 2.0.3 的镜像与端口变化Nacos 2.0.3 相比 1.x 最大的变化是新增了 gRPC 端口。除了 8848 的 HTTP 端口还需要暴露 9848客户端 gRPC和 9849服务端 gRPC。很多人升级后服务注册不上就是因为只开了 8848。# nacos-statefulset.yaml 片段 ports: - containerPort: 8848 name: http - containerPort: 9848 name: client-grpc - containerPort: 9849 name: server-grpc逻辑说明9848 8848 10009849 8848 1001这是 Nacos 2.x 的固定偏移规则。如果改了 8848 端口gRPC 端口要同步调整。StatefulSet 配合 headless Service 保证每个 Pod 有稳定网络标识集群模式下三个节点互相通信靠的就是这个。3. K8s 编排落地Deployment、Service 与 Ingress 的参数怎么填3.1 后端 Deployment 的健康检查与优雅停机Spring Boot 在 K8s 里最容易翻车的地方是滚动更新时流量打到还没准备好的 Pod 上。必须配 readinessProbe 和 livenessProbe且路径要指向 actuator 的健康端点。apiVersion: apps/v1 kind: Deployment metadata: name: backend-deploy spec: replicas: 2 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: spec: containers: - name: backend image: registry.example.com/backend:v1 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30 periodSeconds: 10 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 60 periodSeconds: 15 lifecycle: preStop: exec: command: [sh, -c, sleep 10]参数说明maxUnavailable: 0保证更新期间可用副本不减少。initialDelaySeconds给 Spring Boot 启动留足时间2.5 版本冷启动通常 20 到 40 秒设太小会导致 Pod 被反复重启。preStop里的 sleep 是给 kube-proxy 更新转发规则留窗口不加的话会出现更新时少量 502。readiness 和 liveness 用不同端点避免启动慢被误杀。3.2 Service 与 Ingress 的流量路径前端 Nginx 和后端 Spring Boot 各配一个 ClusterIP ServiceIngress 按路径分流。/api转发到后端其余走前端。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/proxy-body-size: 20m spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: backend-svc port: number: 8080 - path: / pathType: Prefix backend: service: name: frontend-svc port: number: 80逻辑说明pathType: Prefix是 v1 版本的必填项不写会报错。proxy-body-size默认 1m文件上传场景必须调大否则大请求体直接被 Ingress 拒绝。前端 Nginx 里如果也配了/api的反向代理会和 Ingress 规则冲突建议只保留一层通常放在 Ingress 更利于统一管理。3.3 Nacos 集群的 StatefulSet 配置要点Nacos 集群模式需要外部数据库通常用 MySQL。StatefulSet 的每个 Pod 通过环境变量注入自己的序号拼出集群节点列表。env: - name: NACOS_SERVERS value: nacos-0.nacos-headless:8848 nacos-1.nacos-headless:8848 nacos-2.nacos-headless:8848 - name: SPRING_DATASOURCE_PLATFORM value: mysql - name: MYSQL_SERVICE_HOST value: mysql-svc - name: MYSQL_SERVICE_DB_NAME value: nacos_config参数说明nacos-headless是 headless Service 名Pod 序号通过 DNS 直接解析。数据库连接信息用环境变量注入不要硬编码在镜像里。Nacos 2.0.3 的集群健康检查依赖 gRPC 端口互通NetworkPolicy 如果开了要放行 9848 和 9849。4. 避坑排查这套组合在集群里最容易翻车的五个点4.1 服务注册不上Nacos 控制台看不到实例现象Spring Boot Pod 日志显示启动成功但 Nacos 控制台服务列表为空。原因Nacos 2.0.3 的 gRPC 端口 9848 没在 Service 里暴露或者客户端版本低于 2.0。解决检查 Service 的 ports 是否包含 9848确认 pom 里 nacos-discovery 版本与服务端一致用telnet nacos-svc 9848在 Pod 内验证连通性。4.2 前端刷新页面 404现象首页能打开点进子路由再刷新就 404。原因Nginx 没配 history 模式回退请求直接打到 Ingress 找不到对应路径。解决在 nginx.conf 的 location 里加try_files $uri $uri/ /index.html;同时确认 Ingress 的/路径指向前端 Service。4.3 滚动更新时出现短暂 502现象每次发版有几秒钟接口报 502。原因Pod 收到 SIGTERM 后立即停止接受新连接但 kube-proxy 还没更新转发规则。解决加 preStop sleep 10 秒同时 readinessProbe 在停机时先失败让 Endpoints 先摘除再停容器。这个顺序 K8s 会自动处理前提是配了 readinessProbe。4.4 Nacos 集群节点互相找不到现象三个 Nacos Pod 都起来了但集群状态异常配置推送失败。原因headless Service 没配clusterIP: None或者 NACOS_SERVERS 里的域名拼错。解决确认 headless Service 的 clusterIP 为 None用nslookup nacos-0.nacos-headless在 Pod 内验证 DNS 解析。4.5 镜像拉取失败 ImagePullBackOff现象Pod 一直卡在 ImagePullBackOff。原因私有仓库的 imagePullSecrets 没配或者镜像 tag 写成了 latest 导致节点缓存混乱。解决创建 docker-registry 类型的 Secret 并在 Deployment 里引用镜像 tag 用具体版本号禁止用 latest。节点上crictl pull手动拉一次能快速定位是网络问题还是认证问题。5. 进阶技巧用 ConfigMap 热更新 Nacos 配置与版本回滚验证5.1 把 Nacos 连接信息抽到 ConfigMap硬编码在 Deployment 里的 Nacos 地址改一次就要重新 apply常见做法是抽到 ConfigMap配合envFrom注入。这样换环境只改 ConfigMapDeployment 不动。apiVersion: v1 kind: ConfigMap metadata: name: app-config data: NACOS_ADDR: nacos-svc:8848 SPRING_PROFILES: k8s --- # Deployment 中引用 envFrom: - configMapRef: name: app-config逻辑说明envFrom会把 ConfigMap 所有 key 变成环境变量。注意 ConfigMap 更新后已运行的 Pod 不会自动重启需要配合kubectl rollout restart deployment/backend-deploy触发滚动更新。这是很多人以为改了 ConfigMap 就生效、结果发现没变化的常见误解。5.2 版本回滚的验证清单K8s 的kubectl rollout undo能回滚 Deployment但 Nacos 里的配置不会跟着回滚。我一般会按这个顺序验证步骤命令预期结果查看历史版本kubectl rollout history deployment/backend-deploy列出所有 revision回滚到指定版本kubectl rollout undo deployment/backend-deploy --to-revision2返回 rolled back观察滚动状态kubectl rollout status deployment/backend-deploy输出 successfully rolled out验证服务注册登录 Nacos 控制台查看实例数实例数与副本数一致验证接口curl Ingress 地址/api/health返回 200参数说明--to-revision不写默认回滚到上一个版本。回滚后要确认 Nacos 里的配置版本是否匹配如果新版本改了配置项回滚代码但配置没回滚会出现配置项缺失导致的启动失败。建议配置变更也走版本管理和代码版本对齐。5.3 一个我踩过的坑有次发版后回滚代码回去了但 Nacos 里的数据库连接串还是新的结果回滚后的 Pod 连不上库排查了半小时才反应过来。从那以后我每次回滚都强制走一遍配置核对把 Nacos 的配置版本和代码 tag 绑在一起记录。这套清单里我把 ConfigMap 和 Nacos 配置的对应关系写进了注释就是不想再吃这个亏。希望帮到你。本文还有配套的精品资源点击获取
