KubeSphere 部署中间件：我如何从 MySQL、Redis 到 Nacos 看见云原生边界

我以前写这篇文章，是因为在 KubeSphere 里安装 MySQL、Redis、Nacos、Seata、Sentinel 这些中间件时，踩了不少坑。

当时的文章更像操作记录：点哪里、填什么、挂哪个卷、暴露哪个端口。

现在我更想保留的是另一层东西：把传统中间件搬到 K8s 里，并不是把 Docker 命令换成界面配置，而是重新理解配置、存储、网络和生命周期。

如果这个理解没有建立起来，表面上服务跑起来了，真正使用时还是会出现问题。

我为什么用 KubeSphere 练中间件

K8s 抽象很多，新手直接写 YAML 很容易迷路。

KubeSphere 给了我一个更直观的入口。它把工作负载、服务、配置项、密钥、存储卷和容器日志放在一个界面里，让我能看到中间件在 K8s 里的基本形态。

对我来说，这不是为了偷懒，而是为了更快建立对象关系。

一个 MySQL 在 K8s 里不再只是一个进程，它至少涉及：

StatefulSet 或 Deployment；

PVC 和 StorageClass；

ConfigMap；

Secret；

Service；

容器镜像和环境变量；

端口暴露方式；

备份和恢复路径。

这些对象组合起来，才是真正的服务。

我现在会先问四个问题

第一，数据在哪里？

MySQL、Redis、Nacos、Seata 都不是纯无状态服务。只要有数据，就要考虑 PVC、存储类型、备份和恢复。没有想清楚数据位置，就不要谈稳定。

第二，配置在哪里？

配置不应该散落在容器里。能抽成 ConfigMap 或 Secret 的，就应该从镜像里拆出来。这样升级镜像和修改配置才不会绑死。

第三，服务给谁访问？

有些服务只给集群内部访问，有些需要给外部应用访问。内部 Service、NodePort、Ingress、hostPort，每一种方式都有成本和边界。

第四，失败后怎么恢复？

容器重启、节点漂移、存储重新挂载、配置变更失败，这些都要提前想。中间件的价值不是“启动成功”，而是“失败后能恢复”。

我的部署地图

我会把 KubeSphere 中间件部署拆成五层。

第一层，先选部署形态。

像 MySQL 这类有状态服务，我更倾向于 StatefulSet。测试环境可以单节点，生产环境则要重新设计主从、高可用和备份。

第二层，准备配置项。

例如 MySQL 的字符集配置、Nacos 的启动参数、Seata 的存储模式，都应该提前写清楚。不要等容器启动失败后再到处找配置。

第三层，准备存储卷。

PVC 不是一个表单字段，而是数据生命周期的入口。我要知道它绑定到哪里，删除工作负载会不会删除数据，迁移时能不能恢复。

第四层，创建工作负载。

镜像、端口、环境变量、挂载路径、启动探针和资源限制都要明确。测试环境可以简化，但不能不知道自己简化了什么。

第五层，暴露服务并验证。

我会从集群内部访问开始验证，再考虑外部暴露。外部访问一旦涉及 NodePort 或 hostPort，就要记录端口占用和网络路径。

Seata 给我的提醒

Seata 是这篇旧文里最值得复盘的部分。

它让我意识到，服务“部署成功”和“业务可用”是两件事。

Seata 容器在 K8s 里启动成功，不代表外部业务系统就能正确访问它。如果它注册到 Nacos 里的地址是集群内部 IP，而业务系统在集群外部，那么客户端仍然连不上。

这个问题看起来是 Seata 配置问题，本质上是服务发现边界问题。

我会用这个案例提醒自己：

注册中心里暴露的地址，要能被客户端真实访问；

K8s 内部 IP 不等于外部可访问地址；

NodePort、hostPort、Ingress 都要匹配真实调用路径；

一次临时打通不等于长期架构合理。

这类问题只有把调用链画出来，才容易看清楚。

我对生产环境的边界

我不会把这篇文章里的单机测试方案当成生产建议。

我的边界很清楚：

单节点只适合学习、演示和功能验证；

生产 MySQL、Redis、Nacos 要有独立高可用方案；

Secret 不应该明文散落；

存储要有备份和恢复演练；

外部暴露端口要经过安全审查；

中间件升级要先在测试环境验证。

KubeSphere 让部署变简单，但简单不代表风险消失。

它只是把风险从命令行藏到了界面后面。真正负责的人，仍然要理解这些对象如何协作。

这篇旧文现在对我的价值

我现在看这篇旧文，最大的收获不是某个中间件怎么点出来。

它让我建立了一个判断：把服务放进 K8s，不是把服务器换个地方，而是把服务拆成配置、存储、网络、生命周期和恢复能力。

这张地图对后来很多项目都有帮助。

当我再遇到一个新系统时，我会先问：

它有没有状态；

状态在哪里；

谁访问它；

地址如何被发现；

配置如何变更；

失败后如何恢复。

这些问题比某个界面按钮更长期。

按钮会变，版本会变，但云原生系统的边界一直在那里。