保姆级教程：从Docker镜像到K8s服务，一步步搞定Ruoyi Cloud微服务上云部署
从零到生产：Ruoyi Cloud微服务在Kubernetes上的完整部署指南
当企业级应用从单体架构转向微服务时，Kubernetes（K8s）已成为部署和管理这些分布式系统的首选平台。本文将带你深入探索如何将流行的Ruoyi Cloud微服务框架无缝迁移到Kubernetes集群，从基础环境准备到生产级部署，涵盖全链路实践细节。
1. 环境准备与架构设计
在开始部署前，我们需要对整体架构有清晰认识。Ruoyi Cloud是一个基于Spring Cloud Alibaba的企业级微服务解决方案，包含网关、认证、系统管理等多个模块。在Kubernetes环境中，这些组件将以容器化方式运行，并通过K8s原生服务发现机制相互通信。
1.1 基础组件规划
Ruoyi Cloud在K8s上的部署需要以下核心组件协同工作：
有状态服务：
- MySQL 8.0：主数据库
- Redis 7.2：缓存服务
- MinIO：对象存储服务
无状态服务：
- Nacos 2.3：服务注册与配置中心
- Sentinel 1.8：流量控制组件
- Ruoyi各业务模块（网关、认证、系统管理等）
1.2 集群资源建议
根据实践经验，建议为测试环境准备以下资源配置：
| 节点类型 | CPU核心 | 内存 | 磁盘 | 数量 |
|---|---|---|---|---|
| Master | 4 | 8GB | 50GB | 1-3 |
| Worker | 8 | 16GB | 100GB | 3+ |
提示：生产环境应根据实际负载情况适当增加资源，特别是对于有状态服务节点
1.3 网络拓扑设计
服务间的通信关系需要提前规划：
graph LR A[Ruoyi-UI] --> B[Ruoyi-Gateway] B --> C[Auth-Service] B --> D[Sys-Service] B --> E[File-Service] C & D & E --> F[MySQL] C & D & E --> G[Redis] E --> H[MinIO]2. 关键配置改造
将Ruoyi Cloud迁移到Kubernetes需要对原有配置进行针对性调整，主要涉及服务发现、配置中心和持久化存储等方面。
2.1 Bootstrap配置改造
每个微服务模块的bootstrap.yml需要增加K8s环境专用配置：
spring: config: activate: on-profile: k8s cloud: nacos: discovery: server-addr: ry-cloud-nacos-service:8848 config: server-addr: ry-cloud-nacos-service:8848 sentinel: transport: dashboard: ry-cloud-sentinel-service:8858关键改动点：
- 将硬编码的IP地址替换为K8s Service名称
- 为K8s环境创建独立的profile配置
- 确保服务发现使用集群内部DNS解析
2.2 持久化存储适配
对于文件上传等需要持久化存储的功能，需要调整实现类：
@Primary @Service public class MinioSysFileServiceImpl implements ISysFileService { // 修改URL生成逻辑，使用NodePort访问地址 public String getUrl(String bucketName, String fileName) { return minioConfig.getImgOuterAccessUrlPrefix() + "/" + bucketName + "/" + fileName; } }2.3 日志收集方案
在容器环境中，日志需要输出到标准输出或持久化卷：
<!-- logback.xml配置调整 --> <property name="log.path" value="/opt/project/ruoyi/logs/ruoyi-gateway" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender>3. Kubernetes资源编排
合理的K8s资源定义是部署成功的关键，我们需要为每种服务类型设计合适的部署方案。
3.1 有状态服务部署
以MySQL为例，需要配置持久化卷和初始化脚本：
apiVersion: v1 kind: PersistentVolume metadata: name: ruoyi-cloud-mysql-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: /pv/ry-cloud/mysql --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ruoyi-cloud-mysql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: ry-cloud-mysql-deployment spec: template: spec: containers: - name: mysql image: mysql:8.0 env: - name: MYSQL_ROOT_PASSWORD value: "123456" volumeMounts: - mountPath: /docker-entrypoint-initdb.d name: init-sql - mountPath: /var/lib/mysql name: mysql-data volumes: - name: init-sql configMap: name: ruoyi-cloud-init-sql-config-map - name: mysql-data persistentVolumeClaim: claimName: ruoyi-cloud-mysql-pvc3.2 无状态服务部署
后端服务部署模板（以网关为例）：
apiVersion: apps/v1 kind: Deployment metadata: name: ruoyi-cloud-gateway-deployment spec: replicas: 2 template: spec: initContainers: - name: wait-for-dependencies image: busybox command: ['sh', '-c', 'until nslookup ry-cloud-mysql-service; do echo waiting; sleep 2; done'] containers: - name: gateway image: node63:5000/ruoyi-gateway:1.0 args: ["--spring.profiles.active=k8s"] ports: - containerPort: 8080 readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 103.3 服务暴露配置
根据不同服务的访问需求，采用不同的Service类型：
| 服务类型 | Service类型 | 访问方式 | 示例 |
|---|---|---|---|
| 内部服务 | ClusterIP | 集群内部DNS名称 | ry-cloud-mysql-service |
| 管理界面 | LoadBalancer | 外部IP+端口 | 192.168.10.241:8848 |
| 前端访问 | NodePort | 节点IP+固定端口 | node60:9000 |
4. 部署流程与优化
4.1 分阶段部署策略
为确保服务依赖关系，建议按以下顺序部署：
基础设施层：
kubectl apply -f 1_ry-cloud-mysql.yml kubectl apply -f 2_ry-cloud-redis.yml中间件层：
kubectl apply -f 3_ry-cloud-nacos.yml kubectl apply -f 4_ry-cloud-sentinel.yml kubectl apply -f 5_ry-cloud-minio.yml业务服务层：
kubectl apply -f ry-cloud-backend.yml接入层：
kubectl apply -f ry-cloud-fronted.yml
4.2 健康检查与就绪探针
为关键服务添加健康检查配置：
livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 120 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30 periodSeconds: 54.3 资源限制与调度优化
通过资源请求和限制保证服务质量：
resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1"使用节点亲和性控制Pod分布：
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: NotIn values: - node605. 运维与监控
5.1 日志收集方案
建议采用EFK栈进行日志收集：
- 配置Fluentd DaemonSet收集节点日志
- 使用Elasticsearch存储日志数据
- 通过Kibana提供查询界面
5.2 监控指标采集
Prometheus监控配置示例：
- job_name: 'ruoyi-services' metrics_path: '/actuator/prometheus' kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true5.3 常见问题排查
镜像拉取失败：
kubectl describe pod [pod-name] | grep -A 10 Events服务启动顺序问题：
kubectl logs [pod-name] -c [init-container-name]资源不足：
kubectl describe nodes | grep -A 10 Allocatable6. 生产环境进阶建议
6.1 高可用架构
- MySQL：配置主从复制+Sentinel自动故障转移
- Redis：部署Redis Cluster模式
- MinIO：使用分布式模式部署多个节点
6.2 持续交付流水线
建议CI/CD流程：
- 代码提交触发镜像构建
- 扫描镜像漏洞
- 部署到测试环境验证
- 蓝绿部署到生产环境
6.3 安全加固措施
- 为每个服务配置独立的ServiceAccount
- 使用NetworkPolicy限制Pod间通信
- 定期轮换Secret和ConfigMap中的敏感信息
在实际项目中，我们通过逐步验证的方式确保每个组件稳定运行。特别是在服务依赖管理方面，initContainer模式能有效解决启动顺序问题。对于有状态服务，建议在生产环境使用云厂商提供的持久化存储方案，而非hostPath方式。