详细介绍：Kubernetes实战：MariaDB误删恢复与数据持久化

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. 1. PVC 是否成功挂载（kubectl describe pod <pod-name> -n mariadb查看Volumes部分）；

1. 1. 环境变量是否配置正确（如 Secret 是否存在、密码是否正确）；

1. 1. 数据目录权限（可在容器中执行ls -ld /var/lib/mysql查看权限）。

4.2 验证数据持久化（关键步骤）

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

1. 进入 Pod，创建测试数据：

# 进入MariaDB容器
kubectl exec -it  -n mariadb -- bash
# 登录MariaDB，创建测试数据库
mysql -u root -p
# 输入密码后执行
CREATE DATABASE test_db;
exit # 退出MariaDB
exit # 退出容器

1. 删除当前 Pod（模拟 Pod 重建场景）：

kubectl delete pod  -n mariadb -n mariadb

• Deployment 会自动重建新 Pod（因为replicas: 1），等待新 Pod 状态变为Running。

1. 检查测试数据是否保留：

# 进入新Pod
kubectl exec -it  -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 配置→验证” 的流程，既覆盖了实战操作，也拆解了存储与部署的核心原理，希望能帮助大家在实际工作中应对类似问题，保障业务数据安全。