DevOps全链路实战 | 第 3 天：Harbor 私有镜像仓库部署与验证：Helm 安装与镜像推送

第 3/18 天

引言

在前两天的实践中，我们已经完成了全链路架构的整体设计，并用 kubeadm 离线部署了一套带 Cilium 网络插件的 Kubernetes 集群。从今天开始，我们正式进入”流水线底座”的搭建阶段，而第一个要落地的组件，就是整个 DevOps 管道中最核心的”制品中转站”——Harbor 私有镜像仓库。

为什么镜像仓库如此重要？因为无论是 GitLab CI 的构建产物，还是 Argo CD 拉取的部署清单，最终所有应用镜像都要经过统一的地方进行存储、校验和分发。把镜像放在 Docker Hub 等公共仓库，既不安全也不可控；而 Harbor 作为 CNCF 孵化的开源项目，在原生 Docker Distribution 之上补齐了 RBAC 权限、镜像复制、漏洞扫描、保留策略、不可变标签等企业级能力，是目前国内使用最广泛的私有镜像仓库方案。

本文是「DevOps全链路实战」第 3 篇，我们将使用 Helm 3 在一套标准 K8s 集群上完成 Harbor 的安装、配置与验证，最终成功推送并拉取一个业务镜像，为后续 GitLab CI + Kaniko 的镜像构建环节打好基础。

核心概念：Harbor 组件架构与部署选型

Harbor 的六大核心组件

Harbor 本质上是围绕 Docker Distribution 构建的一组微服务，主要包含以下组件：

组件	作用
core	提供 REST API 与 Web 门户，负责鉴权、项目管理
registry	基于 Docker Distribution 的镜像存储服务
jobservice	异步任务调度，负责复制、GC、扫描等后台任务
portal	前端页面（nginx 托管）
database	PostgreSQL，存储元数据
redis	缓存与任务队列

此外，通过集成 Trivy 扫描器，Harbor 还能在镜像推送时自动进行漏洞扫描，这一能力我们会在第 18 天”供应链安全闭环”中继续深化。

为什么选择 Helm 方式部署

Harbor 官方提供了两种主流部署方式：一种是 docker-compose 单机部署，适合快速体验；另一种是 Helm Chart 部署到 K8s 集群，这也是生产环境的标准姿势。选择 Helm 的原因很直观：我们可以把整套配置以 values.yaml 的方式纳入 Git 版本管理，实现基础设施即代码；同时可以利用 K8s 的副本调度能力做到高可用，并与后续 Argo CD 的 GitOps 管理无缝衔接。

实战步骤：Helm 安装 Harbor 并验证镜像推送

前置条件确认

开始之前，请确认集群满足以下条件：

Kubernetes 集群运行正常（前一篇已通过 kubeadm 部署）
已安装 Helm 3（版本不低于 3.8）
集群中存在默认 StorageClass，用于 PVC 动态供给
已规划好 Harbor 访问域名，例如 harbor.stellardata.top

第一步：添加 Helm 仓库并准备配置

Harbor 官方 Chart 托管在 Helm 官方仓库中，我们先添加仓库并更新索引：

💻 代码示例

helm repo add harbor https://helm.goharbor.io

helm repo update

helm search repo harbor/harbor –versions | head -5

接下来创建一个自定义的 values 文件，按我们的环境覆盖默认配置。这里的关键点有三个：外部访问地址 externalURL、管理员初始密码、以及持久化存储类：

💻 代码示例

# values.yaml

expose:

type: ingress

ingress:

hosts:

core: harbor.stellardata.top

className: "nginx"

externalURL: https://harbor.stellardata.top

persistence:

persistentVolumeClaim:

registry:

storageClass: "nfs-client"

size: 100Gi

database:

storageClass: "nfs-client"

size: 10Gi

harborAdminPassword: "ChangeMe-2026"

# 与后续 Trivy 扫描联动，提前开启内置扫描器

trivy:

enabled: true

第二步：使用 Helm 安装 Harbor

配置准备好后，执行安装命令，将其命名为 harbor，安装到 harbor 命名空间：

💻 代码示例

kubectl create namespace harbor

helm install harbor harbor/harbor -f values.yaml -n harbor –version 1.14.0

安装过程会依次创建 PostgreSQL、Redis、core、registry、jobservice、portal 等 Deployment。我们可以通过以下命令观察 Pod 是否全部进入 Running 状态：

💻 代码示例

kubectl get pods -n harbor -w

kubectl get svc -n harbor

正常情况下，等待 1～2 分钟后所有 Pod 应处于 Running / Ready 状态：

💻 代码示例

kubectl get pods -n harbor

NAME READY STATUS RESTARTS AGE

harbor-core-7d8f9c6b7f-abc12 1/1 Running 0 95s

harbor-jobservice-5c9d8f4d9d-def34 1/1 Running 0 95s

harbor-portal-6b7c8d9e4f-ghi56 1/1 Running 0 95s

harbor-registry-5f6e7d8c9a-jkl78 2/2 Running 0 95s

第三步：配置 Docker 客户端并登录

如果使用了自签名证书或尚未为域名配置正式证书，最简单的验证方式是让 Docker 客户端信任该仓库。在 /etc/docker/daemon.json 中加入 insecure-registries（仅用于测试环境）：

💻 代码示例

{

"insecure-registries": ["harbor.stellardata.top"]

}

重启 Docker 后执行登录。默认管理员账号是 admin，密码为上一步 values.yaml 中配置的 harborAdminPassword：

💻 代码示例

systemctl restart docker

docker login harbor.stellardata.top -u admin -p 'ChangeMe-2026'

看到 “Login Succeeded” 即代表认证链路完全打通。

第四步：创建项目并推送镜像

Harbor 中”项目”是镜像的命名空间隔离单元，类似 Docker Hub 的 repository 分组。登录 Web 门户后，在”新建项目”中创建名为 devops 的项目，可见性选择”私有”。随后我们构建一个最简单的业务镜像并推送：

💻 代码示例

docker pull nginx:1.27-alpine

docker tag nginx:1.27-alpine harbor.stellardata.top/devops/nginx-demo:1.0.0

docker push harbor.stellardata.top/devops/nginx-demo:1.0.0

推送成功后，可以在 Harbor 门户的 devops 项目下看到 nginx-demo 仓库及其 1.0.0 标签，同时 Trivy 会自动触发漏洞扫描，展示镜像的安全等级。最后再验证拉取：

💻 代码示例

docker rmi harbor.stellardata.top/devops/nginx-demo:1.0.0

docker pull harbor.stellardata.top/devops/nginx-demo:1.0.0

能够成功从私有仓库拉回镜像，说明 Harbor 的存储、分发链路完全正常。

常见问题

docker login 报 x509 证书错误：说明 Docker 没有信任该仓库的证书，检查 daemon.json 中是否已配置 insecure-registries，或为域名配置受信任的正式证书。
推送时报 401 unauthorized：通常是账号密码错误，或推送的目标项目不存在、当前用户没有该项目的推送权限。先在门户确认项目名称，并在 Harbor 的”成员”中为账号授予”开发者”以上角色。
Helm 安装后 Pod 反复 CrashLoopBackOff：最常见原因是数据库或 Redis 的 PVC 未能绑定，检查 StorageClass 是否可用：kubectl get pvc -n harbor，若处于 Pending 状态，需要先修复存储插件。
镜像推送成功但门户看不到：刷新页面并确认项目切换正确；若使用 HTTP 访问，还需确认 expose.type 配置与实际入口一致。

总结

今天我们完成了全链路管道的第一个关键底座：通过 Helm 在 K8s 集群上部署了 Harbor 私有镜像仓库，配置了 Ingress 入口与持久化存储，并用 docker login / push / pull 完成了端到端验证。至此，我们的集群已经具备”存储和分发应用镜像”的能力，而这正是后续 GitLab CI 构建产物的重要归宿。

明天我们将搭建代码与项目管理平台——GitLab CE，把源码托管、分支保护、MR 评审等能力引入整个体系。