Kubernetes实战：MariaDB误删恢复与数据持久化

K_i1342025-10-02 15:15

MariaDB Deployment 误删恢复与数据持久化实战指南

在 Kubernetes 集群中，数据库类应用的数据持久性是核心诉求 ------ 一旦 Deployment 被误删，若未做好数据持久化，将直接导致业务数据丢失。本文以 "MariaDB Deployment 误删后恢复" 为场景，详细讲解如何通过 PersistentVolumeClaim（PVC）绑定现有 PersistentVolume（PV），实现 Deployment 恢复与数据持久化，同时拆解每一步背后的关键知识点。

一、场景背景与核心目标

1. 问题场景

  • 集群中mariadb命名空间下的 MariaDB Deployment 被误删除，需重新恢复部署。
  • 集群已存在一个可用的 PersistentVolume（PV），需利用该 PV 确保 MariaDB 数据不丢失（避免 Pod 重建后数据归零）。

2. 核心目标

  • 创建符合规格的 PVC，绑定现有 PV；
  • 修复 Deployment 配置，挂载 PVC 实现数据持久化；
  • 验证 Deployment 正常运行且数据持久化生效。

二、前置知识与环境准备

在开始操作前，需明确以下基础概念与环境前提，这是理解后续步骤的关键。

1. 核心知识点铺垫

|--------------------------------|--------------------------------------------------------------------------------------------|
| 概念 | 作用与核心逻辑 |
| PV（PersistentVolume） | 集群级别的 "持久化存储资源"，由管理员提前创建，对应物理存储（如本地磁盘、云存储），生命周期独立于 Pod。 |
| PVC（PersistentVolumeClaim） | Pod 对 PV 的 "存储请求"，由开发 / 运维人员创建，声明所需的存储大小、访问模式，K8s 会自动匹配符合条件的 PV 并绑定。 |
| 数据持久化 | 数据库数据默认存储在 Pod 的 "临时存储" 中（Pod 删除后数据丢失），通过将 PVC 挂载到 Pod 的 "数据目录"，可将数据写入 PV，实现 Pod 重建后数据仍保留。 |
| 访问模式（Access Mode） | 定义 PVC 如何使用 PV，本次需用ReadWriteOnce（仅允许单个节点上的单个 Pod 读写，适合数据库单实例场景）。 |

2. 环境前提

  • 已存在mariadb命名空间（可通过kubectl get ns mariadb验证，不存在则执行kubectl create ns mariadb创建）；
  • 集群中存在可用 PV（可通过kubectl get pv查看，状态为Available表示可绑定）；
  • 本地已存在待修复的~/mariadb-deployment.yaml文件；
  • 已安装kubectl工具并配置集群访问权限。

三、实战步骤：从 PVC 创建到 Deployment 恢复

步骤 1：创建符合规格的 PVC（绑定现有 PV）

首先需创建 PVC，声明 MariaDB 所需的存储资源，让 K8s 自动绑定现有 PV。

1.1 编写 PVC 配置文件

创建mariadb-pvc.yaml文件，内容如下（需严格匹配规格要求）：

复制代码
复制代码 
apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: mariadb-pvc # PVC名称，后续Deployment需引用该名称

namespace: mariadb # 限定在mariadb命名空间

spec:

accessModes:

- ReadWriteOnce # 访问模式：单节点读写

resources:

requests:

storage: 250Mi # 存储大小：250兆

# 若PV有指定storageClassName，需在此添加（如storageClassName: "standard"）

# 无则省略，K8s会匹配同命名空间下无storageClassName的PV
1.2 执行 PVC 创建命令
复制代码
复制代码 
kubectl apply -f mariadb-pvc.yaml
1.3 验证 PVC 绑定状态
复制代码
复制代码 
kubectl get pvc -n mariadb
  • 若输出状态为Bound，表示 PVC 已成功绑定现有 PV（VOLUME列会显示绑定的 PV 名称）；
  • 若状态为Pending，需检查 PV 是否满足条件（如 PV 的存储大小≥250Mi、访问模式包含ReadWriteOnce、无命名空间限制等）。

关键原理：PVC 是 "存储请求的抽象"，它不直接关联物理存储，而是通过 K8s 的 "PV-PVC 绑定机制"，匹配符合需求的 PV------ 这一步是数据持久化的基础，没有 PVC，Pod 无法使用 PV 的持久化存储。

步骤 2：编辑 Deployment 文件，挂载 PVC

误删的 Deployment 文件（~/mariadb-deployment.yaml）可能未配置持久化存储，需修改文件，将步骤 1 创建的 PVC 挂载到 MariaDB 的数据目录。

2.1 理解 Deployment 挂载逻辑

MariaDB 的数据默认存储在容器内的/var/lib/mysql目录（不同版本可能略有差异，需确认），我们需要：

  • 在 Deployment 的spec.template.spec中添加volumes，引用 PVC；
  • 在containers中添加volumeMounts，将 PVC 挂载到/var/lib/mysql目录。
2.2 编辑 Deployment 文件（核心修改部分）

打开~/mariadb-deployment.yaml，找到spec.template.spec节点，添加如下配置：

复制代码
复制代码 
apiVersion: apps/v1

kind: Deployment

metadata:

name: mariadb # Deployment名称，与原误删名称一致

namespace: mariadb

spec:

replicas: 1 # 单实例（数据库通常先部署单实例）

selector:

matchLabels:

app: mariadb

template:

metadata:

labels:

app: mariadb

spec:

containers:

- name: mariadb

image: mariadb:latest # 镜像版本根据实际需求指定

ports:

- containerPort: 3306

# 关键1：将PVC挂载到容器的数据目录

volumeMounts:

- name: mariadb-storage # 与下方volumes.name保持一致

mountPath: /var/lib/mysql # MariaDB数据存储路径

subPath: mysql # 可选，在PV中创建子目录，避免存储冲突

env: # 数据库必要环境变量（如root密码，根据实际需求添加）

- name: MYSQL_ROOT_PASSWORD

valueFrom:

secretKeyRef:

name: mariadb-secret # 需提前创建secret存储密码

key: root-password

# 关键2：定义volume，引用PVC

volumes:

- name: mariadb-storage

persistentVolumeClaim:

claimName: mariadb-pvc # 引用步骤1创建的PVC名称
2.3 配置说明
  • volumeMounts.mountPath：必须指向 MariaDB 的实际数据目录（可通过docker inspect mariadb查看镜像默认数据路径）；
  • volumes.persistentVolumeClaim.claimName：必须与步骤 1 创建的 PVC 名称完全一致，否则无法挂载；
  • env部分：数据库运行需配置 root 密码等环境变量，建议用 Secret 存储敏感信息（避免明文写在 Deployment 中）。

步骤 3：应用更新后的 Deployment 文件

将修改后的 Deployment 配置应用到集群，恢复 MariaDB 部署。

3.1 执行应用命令
复制代码
复制代码 
kubectl apply -f ~/mariadb-deployment.yaml
3.2 查看 Deployment 创建进度
复制代码
复制代码 
kubectl get deployment -n mariadb
  • 若READY列显示1/1，表示 Deployment 已成功创建 1 个 Pod 实例；
  • 若STATUS为Progressing，可通过kubectl describe deployment mariadb -n mariadb查看创建日志（如镜像拉取失败、PVC 挂载错误等）。

步骤 4：验证 Deployment 运行状态与数据持久化

Deployment 创建成功后，需从 "运行状态" 和 "数据持久化" 两方面验证，确保业务可用。

4.1 验证 Pod 运行状态
复制代码
复制代码 
kubectl get pods -n mariadb
  • 若 Pod 状态为Running，表示容器正常启动；
  • 若状态为CrashLoopBackOff，需检查：
    1. PVC 是否成功挂载（kubectl describe pod <pod-name> -n mariadb查看Volumes部分）；
    1. 环境变量是否配置正确（如 Secret 是否存在、密码是否正确）；
    1. 数据目录权限（可在容器中执行ls -ld /var/lib/mysql查看权限）。
4.2 验证数据持久化（关键步骤）

数据持久化的核心是 "Pod 删除后数据不丢失"，验证方法如下：

  1. 进入 Pod，创建测试数据：
复制代码
复制代码 
# 进入MariaDB容器

kubectl exec -it <pod-name> -n mariadb -- bash

# 登录MariaDB，创建测试数据库

mysql -u root -p

# 输入密码后执行

CREATE DATABASE test_db;

exit # 退出MariaDB

exit # 退出容器
  1. 删除当前 Pod（模拟 Pod 重建场景）：
复制代码
复制代码 
kubectl delete pod <pod-name> -n mariadb -n mariadb
  • Deployment 会自动重建新 Pod（因为replicas: 1），等待新 Pod 状态变为Running。
  1. 检查测试数据是否保留：
复制代码
复制代码 
# 进入新Pod

kubectl exec -it <new-pod-name> -n mariadb -- bash

# 登录MariaDB，查看测试数据库

mysql -u root -p

SHOW DATABASES LIKE 'test_db';
  • 若输出包含test_db，表示数据已通过 PV 持久化，Pod 重建后数据未丢失；
  • 若数据丢失，需检查 PVC 挂载路径是否正确、PV 是否正常（kubectl describe pv <pv-name>查看状态）。

四、关键知识点总结

本次实战涉及 K8s 存储与部署的核心知识点，理解这些能帮助你应对更多类似场景：

1. PV 与 PVC 的关系

  • PV 是 "资源"，PVC 是 "请求"，二者通过 K8s 自动匹配绑定，绑定后 PVC 独占 PV（除非 PV 设置reclaimPolicy: Recycle，但已 deprecated）；
  • 绑定条件：访问模式兼容、存储大小满足、storageClassName 一致（若指定）、命名空间匹配（仅针对Namespaced的 PV）。

2. 访问模式的选择

|--------------------|--------------------|-------------------------|
| 访问模式 | 含义 | 适用场景 |
| ReadWriteOnce（RWO） | 仅允许单个节点上的单个 Pod 读写 | 数据库单实例（如 MariaDB、MySQL） |
| ReadOnlyMany（ROX） | 允许多个 Pod 只读访问 | 静态资源共享（如配置文件、日志） |
| ReadWriteMany（RWX） | 允许多个节点的多个 Pod 读写 | 分布式存储（如 NFS、GlusterFS） |

  • 数据库场景优先选ReadWriteOnce，避免多 Pod 同时写导致数据冲突。

3. Deployment 与数据持久化的结合

  • Deployment 管理 Pod 的生命周期，但 Pod 默认使用 "临时存储"；
  • 只有通过volumes引用 PVC，将持久化存储挂载到 Pod 的数据目录，才能实现 "Pod 重建数据不丢"；
  • 若需升级数据库版本，Deployment 的滚动更新会创建新 Pod，只要 PVC 挂载正确，数据会自动继承。

五、常见问题排查

  1. PVC 一直 Pending：
    • 检查 PV 是否存在且状态为Available；
    • 检查 PV 的capacity.storage是否≥PVC 的requests.storage；
    • 检查 PV 的accessModes是否包含 PVC 的访问模式。
  1. Pod 启动失败，提示 "permission denied"：
    • 容器内数据目录权限不足，可在 Deployment 中添加securityContext：
复制代码
复制代码 
securityContext:

fsGroup: 999 # MariaDB默认用户组ID，根据镜像调整
  1. 数据持久化失效：
    • 检查volumeMounts.mountPath是否为数据库实际数据目录；
    • 检查 PVC 是否与 Pod 在同一命名空间；
    • 检查 PV 的reclaimPolicy是否为Retain（若为Delete，PV 删除后数据丢失）。

六、结语

MariaDB Deployment 误删恢复的核心，不仅是重新创建 Deployment，更关键是通过 PV/PVC 确保数据持久化 ------ 这是数据库类应用在 K8s 中部署的 "生命线"。本文通过 "PVC 创建→Deployment 配置→验证" 的流程，既覆盖了实战操作，也拆解了存储与部署的核心原理，希望能帮助大家在实际工作中应对类似问题，保障业务数据安全。

相关推荐
Lin_Aries_04214 小时前
基于 CI/CD（Jenkins）将 Spring Boot 应用自动部署到 Kubernetes 集群
spring boot·ci/cd·docker·容器·自动化·jenkins
Lin_Aries_04216 小时前
在 Kubernetes 集群中运行并发布应用程序
运维·nginx·docker·云原生·容器·kubernetes·自动化
2501_920047036 小时前
k8s-pod的镜像升级与回滚
云原生·容器·kubernetes
码路工人6 小时前
第10章：K8s 数据持久化
docker·云原生·容器
Achou.Wang7 小时前
Kubernetes 的本质：一个以 API 为中心的“元操作系统”
java·容器·kubernetes
2501_920047038 小时前
k8s-Service服务
云原生·容器·kubernetes
rggrgerj9 小时前
前后端部署实战:Vue3+Vite+PNPM + NestJS + Docker + Nginx + 云效
nginx·docker·容器
ayaya_mana10 小时前
Docker常见问题与解决
运维·docker·容器
江湖有缘11 小时前
【Docker项目实战】使用Docker部署Hasty Paste粘贴应用程序
docker·容器·eureka
热门推荐
01GitHub 镜像站点02OpenSpeedy简介03KGG转MP3工具|非KGM文件|解密音频04UV安装并设置国内源05在国行 macOS 下用 DeepSeek 补齐 Xcode 26 的 AI 能力：问题、原因与 mitmproxy 解决方案（含可用脚本与安装教程）06jdk21下载、安装（Windows、Linux、macOS）07Linux下V2Ray安装配置指南08UV 工具安装与国内镜像源配置指南09阿里最新开源Wan2.2-Animate-14B 本地部署教程：统一双模态框架，MoE架构赋能电影级角色动画与替换10VsCode远程Copilot无法使用Claude Agent问题