彻底搞懂k8s中 PV/PVC 与 Harbor 部署类比

Kubernetes 中 PV/PVC 与 Harbor 部署类比

Kubernetes 中 PV/PVC 与 Harbor 部署类比

没问题！我们可以用你熟悉的 Docker 和 Docker Compose 来类比 Kubernetes 中的 PV/PVC 和 Harbor 部署，帮你理清逻辑：

一、先理解核心概念：用 Docker 类比 Kubernetes 存储

1. Docker 中的数据持久化

在 Docker 中，如果你想让容器内的数据持久化（比如 MySQL 数据），会用 -v 挂载本地目录：

# 启动 MySQL，把容器内的 /var/lib/mysql 挂载到本地的 /data/mysql docker run -d -v /data/mysql:/var/lib/mysql mysql:5.7

• 本地目录 /data/mysql 就是实际存储数据的地方。
• 容器内的 /var/lib/mysql 是容器访问数据的路径。

2. Kubernetes 中的 PV 和 PVC（对应 Docker 的 -v 挂载）

Kubernetes 中，“本地目录” 和 “容器内路径” 的映射被拆成了两个部分：

• PV（PersistentVolume，持久卷）：

相当于 Docker 中 “本地实际存储目录”（如 /data/mysql），是集群级别的 “存储资源”，由管理员创建。

例：一个 PV 可以是节点上的 /data/harbor/db 目录，容量 10Gi。

• PVC（PersistentVolumeClaim，持久卷声明）：

相当于 Docker 中 “容器内要挂载的路径”（如 /var/lib/mysql），是用户（Pod）对存储的 “需求申请”。

例：Pod 需要 10Gi 容量、可读写的存储，就创建一个 PVC 声明这个需求。

• 绑定关系：

Kubernetes 会自动匹配 “需求（PVC）” 和 “资源（PV）”，类似 Docker 中 -v 手动指定映射的过程，但 Kubernetes 是自动的（匹配失败就会 Pending）。

二、用 Docker Compose 类比 Harbor 部署

1. Docker Compose 部署 Harbor

如果你用 Docker Compose 部署 Harbor，docker-compose.yml 里会定义多个服务（数据库、Redis、核心服务等），并指定每个服务的数据挂载：

# docker-compose.yml 片段 services:   postgresql:  # 数据库服务     image: postgres:13     volumes:       - /data/harbor/db:/var/lib/postgresql/data  # 本地目录挂载到容器内   redis:  # Redis 服务     image: redis:6     volumes:       - /data/harbor/redis:/data  # 本地目录挂载到容器内   core:  # Harbor 核心服务     image: goharbor/harbor-core     depends_on:  # 依赖数据库和 Redis       - postgresql       - redis

• 每个服务的 volumes 就是数据持久化的关键，如果本地目录不存在或权限不对，服务会启动失败。
• depends_on 定义了服务依赖关系（核心服务依赖数据库和 Redis）。

2. Kubernetes 部署 Harbor（用 Helm 类比 Docker Compose）

你用 Helm 部署 Harbor，相当于用 docker-compose up 启动服务：

• Helm Chart 相当于 docker-compose.yml：定义了 Harbor 所有组件（数据库、Redis、core 等）的配置。
• StatefulSet/Deployment 相当于 Compose 中的 services：定义每个组件如何运行。
• PV/PVC 相当于 Compose 中的 volumes：数据库和 Redis 需要持久化数据，所以 Helm 会自动创建 PVC 申请存储，再由 Kubernetes 匹配 PV 提供实际存储目录。

你的问题就出在：

Helm 自动创建了 PVC（类似 Compose 中声明了 volumes），但 Kubernetes 没找到匹配的 PV（类似 Compose 中本地目录不存在），导致数据库和 Redis 启动失败（Pending），进而依赖它们的 harbor-core 也启动失败（CrashLoopBackOff）。

三、解决思路：像处理 Docker 挂载问题一样处理 PV/PVC

1. 类比 Docker 中的排查步骤

如果 Docker 中某个服务因挂载失败启动不了，你会：

1. 检查本地目录是否存在：ls /data/harbor/db
2. 检查目录权限：chmod 777 /data/harbor/db
3. 重启服务：docker-compose restart postgresql

2. Kubernetes 中的对应步骤

针对 Harbor 数据库和 Redis 的 Pending：

1. 检查 PVC 是否有需求：

类似确认 Compose 中 volumes 的路径和容量，用 kubectl get pvc -n harbor 看 PVC 是否需要 10Gi 存储。

1. 手动创建 PV 提供存储：

类似在 Docker 中创建本地目录，用 kubectl apply -f pv.yaml 创建 PV，指定实际目录（如 /data/harbor/db）、容量 10Gi。

1. 强制绑定 PV 和 PVC：

类似 Docker 中 -v 手动指定映射，用 kubectl patch pvc 让 PVC 绑定到你创建的 PV。

1. 重启服务：

类似 docker-compose restart，用 kubectl delete pod 让数据库和 Redis 重建，此时它们能找到存储，就能启动了。

四、一句话总结

• PV 就是 Kubernetes 中的 “本地存储目录”，由你手动创建，指定路径、容量。
• PVC 就是 “容器内要挂载的路径需求”，由应用（如 Harbor）自动创建，申请存储。
• Harbor 启动失败的本质：数据库和 Redis 的 PVC 没找到对应的 PV（类似 Docker 中挂载目录不存在），导致依赖它们的核心服务启动失败。

按这个类比，你可以像处理 Docker 挂载问题一样，一步步创建 PV、绑定 PVC、重启服务，就能解决问题了。