最近被问得最多的一个问题：镜像到底要不要收进自己的机房。问的人基本都是同一个状态——业务已经上容器了，Kubernetes 跑得挺稳，但镜像还在公共仓库或者某个开发机的本地目录里，CI 打包完往 Docker Hub 一推，生产环境再从公网拉回来，半夜构建经常卡在 pulling image 那一步，第二天早上来公司一看流水线飘红。
这篇不讲 Harbor 是什么（这个你自己搜十分钟就能搞明白），只讲三件事：怎么按自己的量级选 CPU / 内存 / 硬盘 / 带宽、怎么把存储和清理策略配好别让磁盘撑爆、以及哪些坑是别人踩过了你可以直接绕开的。先给几个结论，赶时间的看完这段就可以去下单了。
结论一：别为了自建而自建。团队十个人以内、镜像数不到一百、没有代码不出内网的硬要求，直接用云厂商的托管镜像仓库，省下来的运维精力比省下来的钱值钱得多。
结论二：Harbor 吃资源的不是收镜像，是扫镜像和垃圾回收。Registry 本身只做 blob 读写，CPU 大头在 Trivy 扫描和并发推送时的压缩校验，IO 大头在层数多、并发高时的随机写，这也是 NVMe 唯一值得加钱的地方。
结论三：磁盘规划要按公式算，不能拍脑袋。容量 = 镜像数 × 平均大小 × 保留版本数 × 冗余系数，冗余系数给 1.3–1.5，算完再加 20% 的系统、数据库和日志预留。
结论四：保留策略（retention rule）和配额（quota）必须在上线第一天就配，不是等磁盘红了再补。三个月撑爆磁盘的事故，十有八九是因为这两个东西没配。
结论五：跨地域分发要做主写 + 只读从，别让两个机房同时往一个仓库写。复制是异步的，双向写迟早会打架。
我一般接到咨询会先劝退一半人。自建 Harbor 听起来很酷，实际是给自己雇了一个需要 7×24 照顾的系统：要管证书、管备份、管升级、管磁盘、管 GC、管账号权限，Harbor 大版本升级还经常动数据库 schema，升之前不备份就是赌命。
第一条，镜像里有业务代码，不能出内网。金融、医疗、政企外包这类场景，编译产物本身就是源码的另一种形态，推到公共仓库在合规上就是过不去的。这种团队没什么好纠结的，直接自建。
第二条，跨境拉镜像不稳定。很多团队的基础镜像还挂着公共仓库的地址，CI 在国内机房跑，拉一个 1.5G 的基础镜像，好的时候两分钟，抽风的时候十分钟超时。这不是限速的问题，是链路质量和丢包的问题，重试也救不回来多少。
第三条，需要审计。谁在什么时候推了哪个 tag，哪个镜像被哪个环境拉走过，出了事故要能倒查。公共仓库的日志粒度不够，而且你拿不到细粒度的项目级权限。
第四条，需要跨机房分发。总部构建、多地部署，或者把镜像同步给客户现场的离线环境，Harbor 的复制规则能按项目、按 tag、按事件触发，比自己写脚本 rsync 靠谱得多。
团队三五个人、服务十来个、镜像总量几十 G、没有合规要求——说白了，你用云厂商的容器镜像服务个人版或者基础版就够了，一年花不了多少钱，还不用管磁盘。把自建省下的时间拿去写业务代码，收益高得多。
还有一种典型误区：为了"技术栈完整"自建。我见过一个六人团队，为了"基础设施自主可控"租了一台机器搭 Harbor，结果半年后没人愿意碰它，磁盘红了大家就手动删几个 tag，最后还是迁回托管服务。自建的前提是有人愿意长期维护它，没有这个人，就别建。
选配置之前，得先知道钱花在谁身上。Harbor 不是单体应用，是一堆容器堆起来的，官方安装脚本会给你拉起十来个服务。它们的资源胃口差别非常大。
harbor-core：Go 写的主服务，承担鉴权、项目管理、配额校验、复制策略调度和 Webhook。CPU 消耗中等，真正先吃紧的往往是数据库连接池和 goroutine 数量。稳定态内存大概 0.5–1.5G，项目数上千、策略规则复杂时会更高一些。
harbor-portal：nginx 托着的静态前端，几乎不消耗资源，几百 MB 内存绰绰有余。它轻，但它是所有人访问的路径，所以高可用方案里必须和 core 一起做负载。
harbor-jobservice：异步任务池，垃圾回收、复制、扫描调度、保留规则全部走它。特点是瞬时 CPU 高、平时很低，属于脉冲型负载。任务堆积时你会看到队列越来越长，界面上一堆任务卡在 running 不动。
registry：底层是 docker/distribution，只干一件事——收 blob、发 blob。它几乎不吃 CPU，吃的是磁盘 IO 和文件描述符。并发推送时内存会跟着上传缓冲往上涨，单路大镜像推送时尤其明显。
trivy-adapter：漏洞扫描适配器，这是全套组件里 CPU 和内存最猛的一个。扫一个镜像要解包每一层，遍历 dpkg / rpm / apk / pip / npm 的包清单，再跟 CVE 库做比对。扫一个 1G 出头的镜像，峰值内存上 2–4G 很正常，扫描期间 CPU 能打满好几个核。
Notary / cosign 签名相关组件：签名本身很轻，验签的开销主要落在 Kubernetes 那一侧（admission webhook），Harbor 这边只需要一个适配器。老版本 Harbor 带 Notary，新版本普遍往 cosign / Notary v2 的签名规范走。
PostgreSQL：装的是项目、用户、仓库、artifact、扫描报告的索引。数据量本身不大，但 GC 期间读写量会突然上一个台阶。给它 2–4G 内存、独立的数据盘不亏。
Redis：当缓存和 jobservice 的任务队列用。别小看它，Redis 挂掉 jobservice 就空转，界面上就表现为"点了没反应"。
存储后端：filesystem、S3、MinIO、各家对象存储都支持。用对象存储的好处是容量可以横向扩、不用操心磁盘；坏处是多一跳网络延迟，还要额外管 AK/SK 的轮换。中小团队我更建议先用本地 NVMe，简单，出问题好排查。
Registry 收镜像时，客户端已经把层压成 gzip 了，服务端要做的其实是校验 sha256、解压做 manifest 校验、落盘。所以真正把 CPU 打满的，通常是这三件事。
其一，并发推送时的校验与落盘。十个流水线同时往里推，每层都要算摘要、写文件、更新数据库索引，CPU 和 IO 一起涨。这时候核数比主频重要，因为任务是并行的。
其二，Trivy 扫描。这是 CPU 第一大户。如果你开了"推送即扫描"，每次 CI 推完立刻扫，一个大镜像能吃掉好几核几十秒。扫描量大的团队，我一般建议单独给扫描器加核，或者干脆把扫描任务错峰到凌晨跑。
其三，垃圾回收。GC 要遍历所有 blob 和 manifest，做标记清除，期间 CPU 和 IO 都会拉高。这个后面单独讲。
档位怎么给？按并发路数估比按镜像数估准：
4 核：适合 5–15 人团队、日常个位数并发推送、扫描量不大。再多就卡了。
8–16 核：适合 30–80 个服务、每天几十次构建、开了全量扫描。这是绝大多数中小团队的主力区间。
16 核以上 / 双路：适合开了多项目复制、扫描任务密集、或者把 Harbor 当成几百人共用的企业内部平台。
这里我不给压测数字——不同团队的镜像层数、基础镜像大小、扫描开关差异太大，拿别人的数字套自己的场景没意义。你只要记住一个判断方法：把 Harbor 所在机器的 CPU 使用率和 jobservice 队列长度一起看，队列长期排不到 0，就说明 CPU 或者扫描并发不够了。
这是新手最常犯的错。租一台最便宜的机器，Docker Compose 一跑，十来个容器全塞进去，头两天没事，第三天开始 OOM。
内存大致这么分：core 1–2G，portal 几百 MB，jobservice 1–2G，registry 跟着并发走（2–4G 比较稳），PostgreSQL 2–4G，Redis 512M–2G，Trivy 扫描峰值 2–4G。加起来你会发现，平峰期 12–16G 才算舒服，开了全量扫描就得往 32G 走。
PostgreSQL 值得单独说一句。它的 shared_buffers 一般建议给物理内存的四分之一左右，数据量上来以后索引缓存不够，GC 时会出现大量磁盘读，你会感觉"明明没多少数据，怎么慢成这样"。
内存不足的典型症状很好认：Trivy 扫到一半进程被 OOM Killer 干掉，界面上扫描任务显示失败但重试又能过；PostgreSQL 报连接错误；jobservice 的任务卡在某个状态再也不动。出现这几种情况，先别急着查日志，看一眼 dmesg 里有没有 oom-kill 记录，八成就是内存。
我的建议是：16G 起步，32G 是你的舒适区。如果预算实在紧，至少保证 16G 并且关掉"推送即扫描"，改成定时扫，能省下一大截内存峰值。
先说结论：镜像层数多、并发推送高、开全量扫描，NVMe 值得加；小团队一天推几次，SATA SSD 完全够用。
原因是 registry 的落盘模型。一个镜像推上来，底层是几十上百个小 blob，外加几个几十上百 MB 的大 blob，这个混合写入对随机写性能和 IOPS 都很敏感。并发一高，SATA SSD 的队列就堵上了，iostat 里你会看到 await 飙到几十毫秒，%util 长期 100%。这时候推送变慢，CI 流水线跟着排队。
NVMe 的队列深度和并行度比 SATA 高一个量级，随机写下的延迟稳定性好很多。所以同样是 1.92T 的盘，NVMe 在并发场景下的体感差别很明显。
还有两个容易忽略的点。一个是写寿命：企业级 NVMe 的 DWPD（每日全盘写入次数）通常比消费级高不少，Harbor 这种天天被 CI 写的场景，消费级盘可能一两年就掉健康度。另一个是写满后的性能抖动：盘用到 80% 以上，很多盘的性能会明显下滑，所以容量别卡着算出来的数字买。
阵列这块，两块盘做 RAID1 是最低要求。别想着存一份就行，镜像仓库的数据重建成本很高——你重推一遍所有历史版本？大部分团队的历史版本根本推不回来了。
容量算错是第二大坑（第一大是没配保留策略）。给一个能直接用的式子：
所需容量 ≈ 镜像数 × 平均镜像大小 × 保留版本数 × 冗余系数（1.3–1.5） + 20% 预留
冗余系数cover 的是：层共享没有你想象中那么理想（改一行代码，基础层确实不变，但只要底层依赖动过，上面的层全变）、GC 期间的临时空间、以及同一镜像多架构（amd64 + arm64）的额外占用。
套一个具体例子：80 个服务，平均镜像 800MB，每个服务保留最近 10 个 tag，冗余系数给 1.4。算下来是 80 × 0.8G × 10 × 1.4 ≈ 896G，再乘 1.2 的预留，大概是 1.08T。这种量级我会建议直接上 2T 或者两块 1.92T 做 RAID1，别卡着 1.2T 买。
如果开了多架构构建，上面的结果再乘 2。现在 arm 节点越来越多，很多团队是 amd64 和 arm64 各出一份镜像，容量直接翻倍，这点规划时最容易漏。
告警阈值建议设在 70%。到 70% 就要开始看保留策略是不是该收紧、或者该加盘了，别等到 90% 再动——到那时 GC 都可能跑不动，因为 GC 本身也需要临时空间。
镜像拉取是典型的突发流量，不是均匀流量。一条流水线启动，可能同时拉 20 个镜像，每个几百 MB，一起就是几个 G。如果 CI 节点和 Harbor 在同一个机房内网，千兆的理论上限是 125MB/s，实际能跑到 110MB/s 左右，几个 G 也就几十秒的事。万兆则是十倍的量级。
真正麻烦的是公网。如果 CI 节点在云上、Harbor 在自己的机房，或者反过来，一次构建要跨公网拉几个 G，带宽和延迟都会被放大。跨境场景更明显——丢包重传会让吞吐断崖式下跌。
凌晨批量构建是另一个隐形炸弹。很多团队把全量构建、全量扫描、GC、复制任务全排在凌晨两三点，结果这几件事撞在一起：构建在推、扫描在跑、GC 在遍历、复制在往外发。带宽和 IO 同时打满，构建时长从十分钟变成一小时，第二天大家来上班发现流水线还在转。
怎么避？把这几件事错开——构建放凌晨 1 点，扫描放 3 点，GC 放 5 点，复制任务放到构建完成后再触发。并且给复制任务配带宽限速，Harbor 的复制规则本身就支持限流，别让它把业务带宽吃掉。
跨地域分发的标准做法是 Harbor 的复制（replication）功能：以项目为单位，配一条从 A 到 B 的规则，可以基于事件触发（推送即复制），也可以定时或者手动。B 站点作为只读副本，本地的 K8s 节点从 B 拉，不跨地域。
链路怎么选，看你的量。小规模的定时复制，走公网加密通道就够了；量大或者要求稳定时延的，可以走内网互联、专用链路或者跟机房谈对等连接，这类方案的本质是把两个机房的流量放进一个可控的通道里，避免公网拥塞和绕路。
单机房还是两地？我的判断标准很简单：看镜像拉取失败会不会影响业务发布。如果 Harbor 挂了只是"今天发不了版"，单机 + 好备份就够了；如果 Harbor 挂了意味着线上故障无法回滚，那就两地各放一套。
两地部署要注意三件事。一是只做单向复制（主写 + 只读从），双向写迟早冲突。二是复制是异步的，主站推完到从站可见有延迟，别在从站上做"推完立刻拉"的验证。三是从站也要配自己的保留策略，不然从站会一直堆积主站已经删掉的历史版本。
这是 Harbor 运维里争议最多的一块，把概念理清楚就不难。
删除是软删除，GC 才是真回收。你在界面上删掉一个 tag，磁盘空间不会立刻释放，只是打个标记。真正释放空间要跑垃圾回收。所以有人删了一堆镜像发现磁盘一点没降，就是这个原因。
GC 要不要停写？早期版本的 Harbor GC 建议先停止写入（把系统设为只读）再跑，否则可能误删正在上传的层。现在版本提供了在线 GC，通过 jobservice 作为任务跑，可以设成定时执行，不必整站停机。但实操上我仍然建议两个做法：放在业务低峰跑；跑之前确认没有大批量推送任务在同时进行。在线 GC 不等于零风险，边写边收的边界条件一旦碰到就是层损坏。
保留规则（retention rule）怎么配。常用组合是：保留最近 N 个 tag（比如 10 个）、保留最近 N 天推送的、保留带某个 label 的（比如 release、stable）。规则按项目配，可以按仓库名前缀做匹配，也可以排除某些仓库。配完先跑 dry-run，看看预演结果里到底会删掉哪些，确认没有误伤再启用。
不可变 tag（immutable tag）。在同一个项目里设规则，让 release-* 或者生产环境用的 tag 不能被覆盖。这个一定要开，否则有人不小心用同一个 tag 重推了一个有问题的版本，生产环境滚动更新时拉到的就是坏镜像。
项目配额（quota）。给每个项目设存储上限，超限就拒绝推送。这是防止某个项目失控把整盘吃光的最后一道闸门。配额值别一次给太紧，否则会频繁阻断 CI，先按当前用量的 1.5 倍设，跑一个月看趋势再调。
误删风险怎么控。三件事：启用规则前一定 dry-run；保留规则不要一次配成"只留 3 个"，先从 20 收到 10，观察一周再继续收；GC 之前先备份 registry 的 storage 目录和 Harbor 的数据库。实在不放心，就把保留规则先在测试项目里跑两周。
TLS 是硬门槛，不是可选项。高版本的 containerd 和 Docker 默认拒绝明文 HTTP 仓库，你要用就得在每个节点上显式配 insecure-registries，Kubernetes 环境还得在每个节点的运行时配置里加一遍，节点一多就是灾难。内网环境用自签 CA 完全可以，但要把根证书塞进每个节点的信任链和容器运行时的证书目录里；有域名和公网访问就用正规证书，省事得多。
机器人账号（robot account）而不是个人账号。CI 里千万不要塞某个同事的账号密码——他离职了、改密码了、权限变了，你的流水线就崩。机器人账号可以给最小权限（只允许推某个项目、或者只允许拉），还能设过期时间，随时吊销。每个流水线一个机器人账号，出了问题能精确定位。
OIDC / LDAP 对接。人多的团队接 LDAP 或者 OIDC，统一账号生命周期，离职即失效。对接时注意把外部组的映射关系配好，别让所有人默认拿到管理员权限。
镜像签名。签名解决的是"这个镜像是不是我们构建的"这个问题。Harbor 支持签名方案，配合 Kubernetes 侧的准入控制（比如 Kyverno 之类的策略引擎）做校验，不满足签名的镜像不允许进集群。中小企业如果人力紧张，至少在生产命名空间开启校验，测试环境可以先放开。
漏洞扫描策略：阻断还是告警？我的建议是先告警、观察两到四周、再考虑转阻断。直接开"高危阻断"，第一周你的 CI 就会全线飘红——基础镜像里带的老版本依赖能给你报出一堆 CVE，开发团队会集体来找你。正确做法是：先让扫描结果跑起来，跟团队一起过一遍，把该升的基础镜像升了，把确认无法修的加白名单，然后再对新建镜像开启阻断。
Trivy 漏洞库的更新问题。离线环境最大的坑就是漏洞库不更新。Trivy 需要定期拉取 CVE 数据库，内网环境拉不到，扫描结果会变成一堆陈旧数据，看着"很干净"其实是因为库太老。解决办法是搭一个内网镜像源或者用离线包定期同步更新，并且把"漏洞库更新时间"加到监控项里——库超过一周没更新就要告警。
下面这张表按"你的量级"来分档，价格列只列官网明示的档位，实际下单以官网实时价为准。
| 档位与适用场景 | CPU / 内存建议 | 存储方案 | 带宽与快照 | 官网价格参考 |
|---|---|---|---|---|
| 入门验证档：5–15 人团队，镜像数 100 以内，扫描低频 | 4 核 / 16G | 480G–960G SATA SSD，后期可加盘 | 千兆内网，每日 3 份免费快照、30 秒回滚 | 大陆节点起步价：华西 ¥599 / 华东 ¥699 / 华南 ¥799 / 华北 ¥899（以官网实时价为准） |
| 主力生产档：30–80 个服务，每天数十次构建，开启全量扫描 | 8–16 核 / 32–64G | 1.92T NVMe ×2 做 RAID1 | 千兆至万兆内网，公网兜底，带快照与备份 | 裸金属 E5-2620 ¥999 起（以官网实时价为准） |
| 高并发扫描档：Trivy 全量扫描 + 多项目复制 + 数百人共用 | E5-2698v4 ×2 / 64–128G | 3.84T NVMe ×2 至 ×4，数据库独立盘 | 万兆内网，复制任务限流 | E5-2698v4×2 ¥3999 起（以官网实时价为准） |
| 跨境分发中继：中国香港 / 欧洲 / 美洲节点做只读副本 | 8 核 / 32G 起 | 1.92T NVMe | BGP 多线 + CN2 GIA 回国低延迟 | 中国香港 E3 ¥1500 / ¥1599；欧洲 ¥1299 起；美洲 ¥1699（以官网实时价为准） |
关于整机月支出的大致范围：主力生产档（裸金属 + 双 NVMe + 带宽升级）算下来大致在 ¥1500–2500 区间（预估，以实际账单为准），主要浮动来自硬盘容量和带宽。入门档就便宜得多，一千出头能拿下（预估，以实际账单为准）。这个数字只是帮你做预算，别拿它当报价单。
这是我给客户首推的一套，理由很实在。Harbor 这套东西，稳定比性能重要，而稳定的前提是内存别抠、硬盘别是机械盘。E5-2620 的核数配上 32G 内存，跑 core / jobservice / registry / PostgreSQL / Redis / Trivy 这一整套不挤，开全量扫描也不会 OOM。两块 NVMe 做 RAID1，层数多、并发推送时的随机写撑得住。
华南节点的官网起步价 ¥799，裸金属 E5-2620 ¥999 起（以官网实时价为准），深圳南山本地机房，自营机柜最快 1 分钟上架。如果你的 CI 跑在同一机房，内网千兆拉镜像基本是秒级起步，那种"等镜像"的烦躁感会直接消失。另外他们家每日 3 份免费快照、30 秒回滚，你在改保留策略和跑 GC 之前手动打一份快照，心里踏实很多。
如果你开了推送即扫描、又有多个项目在做跨地域复制，双路是值得的。原因前面讲过：Trivy 是 CPU 和内存双大户，GC 也是脉冲型 CPU 消耗，双路 E5-2698v4 核数足够多，扫描任务可以并发起来而不阻塞正常的推拉请求。128G 内存给 PostgreSQL 的 shared_buffers 和 Trivy 峰值都留了余量。
官网价 E5-2698v4×2 ¥3999 起（以官网实时价为准）。这种机器拿来当主站，再在中国香港或者华东放一台小一点的做只读副本，就是一套很标准的总部构建 + 多地分发架构。
如果你的部署节点在国外，从国内主站拉镜像是很难受的。放一台中国香港节点做中继（E3 ¥1500 / ¥1599，以官网实时价为准），BGP 多线加 CN2 GIA 的回国链路，国内主站推完触发复制，海外节点从本地拉，速度差一个数量级。欧洲 ¥1299 起、美洲 ¥1699（以官网实时价为准），按你的用户分布挑。
选一万网络还有个现实原因：深耕 IDC 19 年（成立于 2007 年），深圳南山总部，7×24 中文工单、平均 5 分钟响应，硬件故障 10 分钟自动迁移。Harbor 这种东西最怕的是半夜磁盘或者主板出问题、第二天早上全公司发不了版，有个能快速响应的工单通道比什么都实在。另外 5–20G 的免费 DDoS 防护和免费备案协助也是顺手就能用上的。
坑一：磁盘写满导致推送失败，而且 GC 也跑不动。为什么坑：registry 写不进去就返回 5xx，CI 报"unknown blob"或者连接中断，你第一反应是服务挂了，其实是盘满了。更糟的是 GC 和数据库 vacuum 都需要临时空间，盘满时连自救的手段都没有。怎么避：容量告警阈值设 70%，到 75% 就进入处理流程；给 registry 的存储目录单独挂载一个分区，别和系统盘、数据库共用一块盘，这样即使镜像盘满了，系统还能登录进去处理。
坑二：把所有组件塞在一台 2 核 4G 的机器上。为什么坑：Harbor 默认安装会拉起十来个容器，PostgreSQL 加 Redis 加 Trivy 光静态占用就超过 4G，一旦有并发推送或者扫描，OOM Killer 会随机挑一个进程杀掉，症状飘忽不定，你查半天查不到原因。怎么避：16G 起步、32G 舒适，这是硬门槛，别在这上面省钱。真要省钱宁可先用云托管仓库，也别用一台跑不动的机器自建。
坑三：忘记配保留策略，三个月撑爆磁盘。为什么坑：CI 每次构建都推一个新 tag，一天几十个，一个月就是上千个，而且历史版本没人敢删——万一要回滚呢。三个月后磁盘红了，大家开始手忙脚乱手动删，删错了就出事故。怎么避：上线第一天就给每个项目配保留规则（保留最近 10 个 tag + 保留 30 天内），配完 dry-run 验证，再配项目配额做兜底。别指望事后补救，事后补救时你面对的是几千个 tag，连判断哪些能删都做不到。
坑四：GC 期间还在写入，导致镜像层损坏。为什么坑：垃圾回收是标记清除，它遍历 blob 时如果有新的层正在上传，边界条件下可能把正在写的、或者还没被 manifest 引用的层判成垃圾。表现出来就是某个镜像推送成功但拉取时报"manifest unknown"或者层校验失败，而且是偶发的，排查成本极高。怎么避：把 GC 排到业务低峰，跑之前确认没有大批量推送；如果版本支持，跑之前把仓库临时设为只读，跑完再放开。宁可多花十分钟窗口，别去赌那个概率。
坑五：HTTP 明文仓库在高版本容器运行时被拒绝。为什么坑：为了图省事用 http 部署，结果 containerd / Docker 高版本默认要求 https，K8s 每个节点都得改运行时配置加 insecure-registries，节点一多配置就漂移，新加的节点忘了配就拉不了镜像。更麻烦的是有些托管 K8s 根本不让你改节点配置。怎么避：一开始就上 TLS。内网用自签 CA 也行，把 CA 证书分发到所有节点的信任链；有域名就申请正式证书。这一步省下来的时间，后面都得加倍还回去。
坑六：跨机房分发把公网带宽打满，影响业务。为什么坑：复制规则一次同步几十个 G，默认不限速，直接把出口带宽吃光，同机房的业务请求跟着超时，而你往往是在业务报障之后才发现是复制任务干的。怎么避：复制规则里配带宽和并发上限；把复制排到业务低峰；量大的场景走内网互联、专用链路或者跟机房谈对等连接，把复制流量从公网里摘出去。
Q1：Harbor 一定要用 Kubernetes 部署吗？Docker Compose 行不行？
行，而且中小团队我更建议先用 Docker Compose。Compose 部署的 Harbor 排障直观，docker logs 就能看，出问题好定位；上 Kubernetes 之后你得管 PVC、Ingress、证书、外部数据库，多一层复杂度。什么时候该上 K8s？当你已经有了成熟的 K8s 运维体系，并且希望 Harbor 跟其他组件统一纳管的时候。单纯因为"K8s 更高级"而上，是给自己找事。
Q2：镜像能不能直接存到对象存储，不用本地盘？
能，Harbor 支持 S3 协议的对象存储后端。好处是容量几乎不用管，也不用操心 RAID 和磁盘告警。代价是每次读写多一跳网络，延迟会比本地 NVMe 高，而且并发写入量大时对象存储的 API 请求次数会产生额外费用。我的建议是：量不大、团队小，本地 NVMe 更简单；量上来了、历史版本要长期留存，再迁对象存储。别一上来就上对象存储，排查问题时会很痛苦。
Q3：垃圾回收到底多久跑一次合适？
看你的推送频率。每天几十次构建的团队，一周跑一次够了；每天几百次的，可以两三天一次。关键不是频率，是跑之前先确认保留策略已经生效——如果保留规则没配，GC 什么也回收不掉，跑了也是白跑。另外把 GC 排在低峰，并且监控它的执行时长，某次突然变长往往说明 blob 数量涨得厉害，是时候看看保留策略了。
Q4：机器人账号和个人账号在权限上有什么本质区别？
机器人账号是"属于项目"的，不是"属于人"的。它只能被授予这个项目下的特定权限（推送、拉取、或者只读），不能登录 Web 界面，也不会因为某个人离职或者改密码而失效。CI 里用它是最合适的，而且建议一条流水线一个账号，真出问题了吊销单个账号不影响别人。个人账号则跟 LDAP / OIDC 的生命周期绑定，给人用，不机器用。
Q5：漏洞扫描报了一堆 CVE，要不要全部修完才允许上线？
别这么干，会把自己卡死。基础镜像里带的系统包 CVE 数量往往很可观，其中相当一部分在当前使用场景下并不成立（比如某个组件的特定调用路径你根本没用到）。务实的做法是分三步：先升级基础镜像到大版本的最新补丁版，能清掉大部分；剩下的是确实无法修的，加到白名单并注明原因；最后才对"新构建的镜像"开启高危阻断。老镜像先观察，别一刀切。
Q6：内网环境 Trivy 拉不到漏洞库怎么办？
这是离线部署最常见的卡点。思路是在能联网的地方定期下载漏洞库，打包后导入内网，放到 Harbor 能访问的位置，让扫描器从那里读。具体做法各版本略有差异，但核心是两件事：一是把更新动作做成定时任务，二是把"漏洞库最后更新时间"做成监控项。库超过一周没更新的话，扫描结果看着干净其实是因为库太老，这种假安全感比不扫描更危险。
Q7：主备两地怎么保证镜像一致性？会不会出现主站有、从站没有的情况？
一定会，因为复制是异步的。主站推完到从站可见，中间有延迟，量大的时候可能几分钟甚至更久。所以别在从站上做"推完立刻拉"的验证，也不要让生产发布流程依赖跨地域的强一致。正确的做法是：生产发布从主站所在区域拉，从站只服务本地的部署需求；同时在从站配健康检查，复制延迟异常的时候告警出来，而不是等有人拉取失败才发现。
Q8：升级 Harbor 版本有什么要特别注意的？
三件事。第一，升级前必须备份数据库和 registry 的存储目录，Harbor 大版本升级会改数据库 schema，没备份就是赌。第二，先读 release note 里的不兼容变更，尤其是认证方式和配置文件格式的改动，跨大版本升级经常需要手工改 harbor.yml。第三，在测试环境完整演练一遍再动生产，包括升级后推一个镜像、拉一个镜像、跑一次扫描，确认没问题再切流量。
给一个我自己在用的清单，照着过一遍能省掉大半的返工：TLS 证书配好并且所有节点都能验过；机器人账号按流水线分配，个人账号不进 CI；LDAP / OIDC 对接完成，权限组映射确认无误；每个项目配了保留规则和配额，并且跑过 dry-run；不可变 tag 规则在关键项目上开启；GC 任务排进低峰并且有执行结果告警；磁盘告警阈值设在 70%；数据库和 registry 目录的备份任务验证过一次真实恢复；漏洞库更新时间进了监控；复制规则配了带宽上限。这十条跑完，你的 Harbor 才算是可以交付给团队用的状态。
自建 Harbor 这件事，技术门槛不高，真正的门槛在运维纪律上。同样的硬件配置，有人跑三年不出事，有人三个月磁盘就红了，差别不在选了多少核、多少 G，而在于保留策略有没有第一天就配、GC 有没有排进低峰、备份有没有验证过能不能恢复。如果你团队里没有愿意长期照顾它的人，老实说，用托管服务是更负责任的选择。如果你确实要自建，希望这篇能让你少踩几个坑——尤其是磁盘和 GC 那两个，踩一次够你记半年。
本文涉及的一万网络产品能力与价格档位，参考自一万网络官网 https://www.idc10000.net/ 相关页面（裸金属服务器、中国大陆及中国香港 / 欧洲 / 美洲节点租用、GPU 与云产品页）。文中标注的官网价均为发布时可见档位，具体以官网实时价为准；标注"预估"的数字为按配置推算的预算区间，以实际账单为准；未明示的型号与配置以咨询为准。整体方案与报价，具体以签约时最新报价与合同为准。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，提供 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟自动迁移、每日 3 份免费快照 30 秒回滚、免费备案协助与 5–20G 免费 DDoS 防护。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
