这组文章来自一次完整的集群重建，但它不是按故障发生时间记的流水账，而是重新整理成可以从头执行的教程。

所有内部地址、域名、节点、命名空间、账号和容量都已脱敏。命令中的 <...> 是必须替换的变量，不能直接复制到生产环境。

推荐阅读顺序

第一阶段：先获得一个健康的空集群

  1. 从零搭建 Kubernetes：准备 Rocky Linux 和 containerd，使用 kubeadm 创建三节点控制平面，配置 kube-vip 与 Calico。
  2. 理解三类网络地址：分清 Node、Pod、Service CIDR 与 DNS 的区别，避免地址重叠和固定 IP 依赖。
  3. 安装基础组件：部署 metrics-server、动态存储和 NGINX Ingress，并用测试工作负载验收。
  4. 规划节点池：用标签、污点、容忍和亲和性划分入口、业务、数据、监控和预留节点。
  5. 设计无感滚动发布：正确配置三类探针、优雅停机、Deployment 策略与 PDB。

第二阶段：建立平台依赖

  1. 搭建 Nacos 三节点集群：理解 Headless Service 与普通 Service，配置数据库、鉴权、探针和反亲和。
  2. 把固定 Service IP 改成 DNS：盘点 Nacos 配置，逐条替换、回读、重启和验证。
  3. 把 Nacos 服务发现迁移到 Service DNS：保留配置中心，逐条迁移 Feign、Gateway 和内部 HTTP 调用链。
  4. 平滑升级 Nacos：备份配置与数据库，验证版本兼容性，逐节点滚动升级并设计回滚。
  5. 排查 Service 与注册失败：按 DNS、Service、Endpoint、Pod、CNI 和 kube-proxy 逐层定位。

第三阶段：迁移业务和制品库

  1. 迁移有状态服务：分别处理 MySQL、Redis、Kafka、RabbitMQ 和 ZooKeeper 的备份、恢复与切换。
  2. 业务迁移 Runbook：资源以零副本方式落地、数据恢复、分批启动、真实业务验收、入口切换和回滚。
  3. 在 Kubernetes 部署 Nexus 3：先把新的制品库稳定运行起来。
  4. 从 Nexus 2 平滑迁移到 Nexus 3：Upgrade Wizard、H2 升级、PostgreSQL 迁移和 VIP 切换。
  5. 治理 Nexus CE 用量：区分组件、请求和 Blob 空间，安全清理代理缓存和过期制品。

第四阶段：运行时优化与事故复盘

  1. 分析多服务 Pod 重启风暴：从终止状态和 previous logs 定位慢依赖、连接池与探针放大效应。
  2. 统一多服务 Spring Boot 3 Deployment 模板：合并重复模板，以参数表达资源和兼容例外，并统一安全、运行和跨节点契约。
  3. 建立 Spring Boot 3 Nacos 全局配置基线：治理 Redis、Redisson、RabbitMQ、Hikari、Tomcat、Actuator 和配置覆盖关系。
  4. 复盘 Boot 2/3 Redis 配置回退 localhost：解释 Nacos 属性前缀、延迟建连、应用级兼容别名与 commons-pool2 依赖陷阱。
  5. 优化 JDK 17 与 G1 容器内存：从 3–4GiB 与同版本 Pod 内存差异出发，治理堆、线程、消息预取、glibc arena 与诊断工具。
  6. 收缩 ZooKeeper 在 Kubernetes 中的内存：用真实 JVM 参数、mntr 与快照建立容量模型，分阶段降低 Heap 和资源请求，并处理 emptyDir 风险。
  7. 优化 JDK 25 与 ZGC 容器内存：分解 Heap、Native Memory 和 cgroup 工作集，验证 Soft Max 与内存归还。
  8. 复盘 Spring Boot 3 容器启动兼容问题：按文件系统、废弃属性、classpath 和业务代码分层解决目录、日志与空驱动异常。
  9. 复盘 Spring Boot 3.1.7 → 3.5.13 升级：定位编译通过后才暴露的 Batch Job 重名、线程池注入和 MongoDB 健康检查问题。
  10. 规划 Spring Boot 3.5.13 → 4.1 迁移：只梳理 Boot 4 新增的 Cloud Alibaba、Config Data、Web 容器、Jackson 与数据访问边界。

为什么不写成一篇

集群安装、应用迁移和 Nacos 治理的失败边界完全不同。把它们放在一篇文章里，容易出现三个问题：

  • 读者不知道当前命令应该在哪台机器、哪个集群执行。
  • 故障处理被埋在长文中，无法作为独立手册复用。
  • 某个组件升级后，整篇文章都需要重新校验。

拆分后，每篇文章都遵循相同的结构：

目标 → 前置条件 → 文件准备 → 逐步执行 → 预期结果 → 故障判断 → 回滚 → 完成定义

实验环境约定

示例统一使用以下占位符：

占位符含义
<api-vip>Kubernetes API 虚拟地址
<pod-cidr>Pod 地址段
<service-cidr>Service 地址段
<node-ip>节点管理地址
<image-registry>已审核的镜像仓库
<storage-server>存储服务器地址或 DNS
<nacos-domain>Nacos 访问域名

如果需要在实验环境使用示例 IP，应使用 RFC 5737 规定的文档地址段；文章中不会出现真实内网地址。

每一阶段的停止条件

遇到以下任一情况，不要继续下一篇：

  • etcd 或数据备份没有完成恢复验证。
  • 节点不是全部 Ready，或跨节点 Pod 网络不通。
  • ClusterIP、DNS、PVC、Ingress 任意一项冒烟失败。
  • Nacos 三节点状态不一致，或者服务实例列表为空。
  • 新旧入口没有可执行的回滚方案。

教程的目标不是“命令执行完了”，而是每一步都留下可验证证据，并且能安全返回上一个稳定状态。