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