当前位置：首页 > news >正文

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

news 2025/10/2 6:09:41

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: v1kind: PersistentVolumeClaimmetadata: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/v1kind: Deploymentmetadata:name: mariadb # Deployment名称，与原误删名称一致namespace: mariadbspec:replicas: 1 # 单实例（数据库通常先部署单实例）selector:matchLabels:app: mariadbtemplate:metadata:labels:app: mariadbspec:containers:- name: mariadbimage: 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_PASSWORDvalueFrom:secretKeyRef:name: mariadb-secret # 需提前创建secret存储密码key: root-password# 关键2：定义volume，引用PVCvolumes:- name: mariadb-storagepersistentVolumeClaim: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 删除后数据不丢失”，验证方法如下：

进入 Pod，创建测试数据：

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

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

kubectl delete pod <pod-name> -n mariadb -n mariadb

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

检查测试数据是否保留：

# 进入新Podkubectl exec -it <new-pod-name> -n mariadb -- bash# 登录MariaDB，查看测试数据库mysql -u root -pSHOW 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 挂载正确，数据会自动继承。

五、常见问题排查

PVC 一直 Pending：

- 检查 PV 是否存在且状态为Available；

- 检查 PV 的capacity.storage是否≥PVC 的requests.storage；

- 检查 PV 的accessModes是否包含 PVC 的访问模式。

Pod 启动失败，提示 “permission denied”：

- 容器内数据目录权限不足，可在 Deployment 中添加securityContext：

securityContext:fsGroup: 999 # MariaDB默认用户组ID，根据镜像调整

数据持久化失效：

- 检查volumeMounts.mountPath是否为数据库实际数据目录；

- 检查 PVC 是否与 Pod 在同一命名空间；

- 检查 PV 的reclaimPolicy是否为Retain（若为Delete，PV 删除后数据丢失）。

六、结语

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

查看全文

http://www.dtcms.com/a/430715.html