最近在帮团队搭一套内网Kubernetes环境镜像这一环又把我卡了好几天。直连Docker Hub拉镜像基本靠运气超时、限流、断流轮着来团队成员各自在本地存镜像导致版本漂移、依赖缺失真要出问题连排查的入口都没有。思前想后决定在集群旁边搞一个Harbor私有仓库一套服务把镜像存储、权限管理、安全扫描全包了。先说结论这个方案落地之后整个链路的镜像分发速度从“看天吃饭”变成了秒级响应Kubernetes集群拉取内部镜像的速度肉眼可见地提升而且每个镜像来自哪里、谁上传的、版本是否合规都有记录可查。如果你也在维护Kubernetes集群或者公司里有多套环境需要统一的镜像管理入口这篇实操记录应该能帮你少走不少弯路。下面我把从选型、安装、配置到对接Kubernetes的完整过程拆开来讲包括我踩过的坑和总结的排查思路。1. 为什么要折腾Harbor自建私有镜像仓库的真实价值1.1 镜像拉取速度只是表象供应链安全和团队协作才是刚需很多人觉得自建仓库就是为了“拉镜像快一点”这话只对了一半。速度问题确实是痛点但更关键的是镜像来源不可控。直接使用公共镜像仓库时拉下来的镜像是不是真的就是官方发布的版本里面有没有被篡改过有没有带漏洞的底层依赖这些都是黑盒。企业内网一旦出现镜像投毒或者供应链攻击影响的可不是一台机器。自建Harbor之后整个镜像流转链路变得完全可控开发在本地构建镜像push到Harbor经过漏洞扫描和签名校验再由Kubernetes集群从Harbor拉取。每一层都有审计日志每个项目可以有独立的账号权限谁上传了哪个镜像、谁删除了哪个tag全部留痕。对于需要合规审计的团队来说这一条比速度重要得多。还有一个容易忽略的点镜像的不可变性。公共仓库的tag可以被覆盖你今天拉到的v1.0和明天拉到的v1.0可能根本不是同一个东西。Harbor支持不可变tag策略一旦发布就不允许覆盖这在生产发布的时候能避免掉很多“明明没动过代码为什么线上行为变了”的诡异问题。1.2 Registry、Docker Hub与Harbor为什么偏偏是它官方Registry镜像也能搭一个私有仓库为什么不用我用过一段时间结论是功能太单薄了。Registry只解决了“存储镜像”这一个问题账号权限、Web界面、漏洞扫描、复制功能全都得靠自己另外想办法。而且没有UI团队里非基础设施的同学根本没法自助使用最后镜像管理还是落到运维一个人头上成了瓶颈。Harbor是基于Registry做的企业级扩展这类场景里它几乎“什么都有”项目级别的RBAC权限控制可以区分管理员、开发者、访客内置Trivy漏洞扫描器能扫镜像里的已知漏洞支持跨机房镜像复制一条规则把镜像同步到灾备站点还有Webhook和审计日志能跟现有的发布系统、工单系统做联动。Docker Hub和Harbor的定位也不同。公共仓库适合拿来做开源项目分发企业内网环境里镜像属于核心资产不能放在第三方平台上。Harbor能完全离线运行不依赖外网这对内网隔离环境是刚需。1.3 三种部署形态怎么选Compose、Helm、KubeKeyHarbor官方提供了几种部署方式我这次选型时逐个考虑过。Docker Compose方式是最成熟的方案Harbor安装包里直接带上编排文件和整套依赖镜像单机部署最简单升级路径也清晰。缺点是Harbor本身不在Kubernetes里跑需要单独一台机器。Helm方式是把Harbor部署在Kubernetes集群内部好处是实现“所有服务都在集群内”对已经稳定运行的K8s环境来说很优雅。但要注意Harbor需要数据库、Redis、对象存储这些依赖全跑在集群里对资源占用不小而且Helm chart的配置项复杂度比Compose高一个量级调试起来相对费劲。如果你的集群是用KubeKey装的还可以直接在安装阶段就把Harbor地址注入集群配置里让KubeKey在初始化时就完成私有仓库的对接。我这次环境单机就够用加上后面要频繁调参最后选了Docker Compose方案——稳、直接、好排查。2. 开工前准备环境规划与部署形态选型2.1 硬件、系统与网络规划Harbor本身不算重但跑起来之后Docker、PostgreSQL、Redis、Nginx、Trivy扫描器加在一起资源占用并不低。官方建议最低2核4G我实测下来这个配置只能满足“能跑”一旦并发推送几个大镜像内存直接见底。建议生产环境至少4核8G起步你后面还要跑Kubernetes节点的话这颗机器的资源要单独预留不要和集群节点抢内存。系统方面我这台是CentOS 7.9内核3.10需要注意几个点存储驱动一定要确认是overlay2不要用老的devicemapper磁盘分区格式化时确认开启了d_type支持不然Docker会报overlay2的兼容性警告。磁盘容量按镜像增长的速度来规划Harbor的registry数据目录默认在/data/harbor建议单独挂一块数据盘别跟系统盘混在一起。网络规划这里建议提前想清楚Harbor的hostname不要用IP尽量分配一个内网域名比如harbor.internal.example.com。Kubernetes节点、开发机都要能解析到这个域名。如果内网没有DNS至少在每台需要访问Harbor的机器上写好/etc/hosts映射。现在图省事直接用IP后面证书、HTTP跳转、复制功能全都会变得很别扭。2.2 证书方案先想清楚要走HTTP还是HTTPS这一步非常关键而且容易返工。Harbor默认配置文件里HTTP和HTTPS两段是都存在的你如果没仔细看就装很可能得到一个同时监听80和443的“混合怪”后面客户端配置又会因为证书信任问题反复报错。我的建议很直接生产环境必须用HTTPS。镜像仓库涉及的是内网最核心的资产明文传输的风险不只是被人抓包更重要的是Kubernetes节点和Harbor之间传输大镜像时中间有任何链路篡改你都无法感知。虽然企业内部网络相对可信但安全这个东西讲究的是纵深防御。测试环境如果实在懒得搞证书就统一走HTTP并把所有节点的insecure-registries配置好千万别混用。我这次直接发了自签CA证书# 1. 生成CA私钥有效期给的久一点省得频繁续签 openssl genrsa -out ca.key 4096 # 2. 生成CA根证书 openssl req -x509 -new -nodes -days 3650 \ -key ca.key -out ca.crt \ -subj /CNHarbor Private CA # 3. 生成Harbor服务端私钥 openssl genrsa -out harbor.key 2048 # 4. 生成证书签发请求CN一定要写Harbor的域名 openssl req -new -key harbor.key -out harbor.csr \ -subj /CNharbor.internal.example.com # 5. 保证证书里带上域名和IP的SAN字段不然新版本客户端会报证书校验错误 cat ext.cnf EOF subjectAltName DNS:harbor.internal.example.com,IP:192.168.10.20 extendedKeyUsage serverAuth EOF openssl x509 -req -in harbor.csr \ -CA ca.crt -CAkey ca.key -CAcreateserial \ -out harbor.crt -days 3650 -extfile ext.cnf生成完把harbor.crt和harbor.key放到固定目录后面配置harbor.yml的时候直接用绝对路径引用。2.3 工具链检查清单装之前先把环境检查一遍别等install.sh跑一半才报错。以下是我每次搭这类环境都会跑的检查你按顺序过一遍基本不会出幺蛾子# Docker版本Harbor 2.x需要20.10以上 docker version --format {{.Server.Version}} # Docker Compose需要v2版本老v1可能不被install.sh识别 docker compose version # 确认overlay2存储驱动已启用 docker info | grep -A2 Storage Driver # 如果装了旧docker-compose命令确认版本 docker-compose --version另外注意一点CentOS 7自带的Python是2.7Harbor 2.x的install.sh脚本对Python版本有要求如果系统里默认Python太老建议用yum装一个Python3备用或者直接在系统Python里补上缺失的模块。Harbor安装包内部会用Python跑prepare步骤这块报错排查起来挺浪费时间。3. 一步步搭起Harbor服务配置详解与完整命令3.1 下载安装包离线包与在线包怎么选Harbor的GitHub Release页面会同时提供online和offline两种安装包。online版本安装时要从Docker Hub拉取Harbor组件镜像对于内网环境通常不适用offline版本把所需镜像全部打进tar包里一键导入内网离线环境首选。体积方面offline包有几百MB到1GB多下载的时候注意选对版本号。我用的是2.x系列下载并解压后目录结构大致如下tar -xzvf harbor-offline-installer-v2.11.1.tgz cd harbor ls -la # 重点关心这几个文件/目录 # - harbor.yml.tmpl 配置模板 # - install.sh 安装脚本 # - harbor.v2.11.1.tar.gz 离线镜像包这里有个小技巧官方包里的模板文件是harbor.yml.tmpl记得先复制成harbor.yml再改不要直接在模板文件上动手后面升级或重新配置的时候一份干净模板会很有用。3.2 harbor.yml配置逐项解读harbor.yml是整个部署的核心改错一项轻则启动异常重则数据目录损坏。我按实际使用经验逐项说明。# 这里必须填域名或可解析的主机名切记不要写localhost或127.0.0.1 hostname: harbor.internal.example.com # HTTP和HTTPS建议只启用一个 http: port: 80 https: port: 443 certificate: /data/cert/harbor.crt private_key: /data/cert/harbor.key # 管理员初始密码建议设置一个高强度口令8位以上大小写数字符号 harbor_admin_password: YourStrongPassw0rd # 数据库密码Harbor会自动创建PostgreSQL容器这里要注意别用默认值 database: password: YourDBPassw0rd max_idle_conns: 100 max_open_conns: 900 # 所有持久化数据都会放在这个目录务必提前规划磁盘空间 data_volume: /data/harbor # 漏洞扫描相关配置离线环境把skip_update设为true可以跳过漏洞库更新 trivy: ignore_unfixed: true skip_update: false offline_scan: false # 日志保留配置镜像仓库的日志量增长很快建议开启轮转 log: level: info local: rotate_count: 15 rotate_size: 100M location: /var/log/harbor有几个容易让人纠结的点HTTP和HTTPS同时启用其实是允许的但客户端配置会变得混乱同一台机器Docker时不时报证书错误。我这里只保留HTTPS把HTTP完全注释掉这样所有客户端统一走443端口排查问题少一个维度。数据库密码修改要谨慎Harbor在首次部署时会写进自己的配置文件里事后改数据库密码不是改一个配置项就完事还要同步改Docker Compose里的环境变量很容易漏。所以初始密码这一步一定要想好再填我建议把密码存到公司的密码管理工具里。改了harbor.yml之后重新运行install.sh之前Harbor会执行prepare步骤去校验配置。如果改了hostname或者证书路径需要先执行sudo ./install.sh # 或者只重新生成配置不动服务 sudo docker compose up -d3.3 执行install.sh并验证服务配置改好后直接跑安装脚本sudo ./install.sh如果是第一次安装脚本会先导入离线镜像包这一步耗时比较久取决于你的磁盘速度。等脚本执行完看到一系列容器都变成healthy状态就说明基础服务起来了docker ps # 至少看到这几个容器在运行 # harbor-core、harbor-registry、harbor-db、harbor-redis、harbor-nginx、 # harbor-jobservice、harbor-portal、harbor-log、harbor-trivy然后验证服务是否可以访问。浏览器打开https://harbor.internal.example.com如果能正常显示登录页说明Nginx、Core、Portal整套链路是通的。用之前配置的admin账号登录进去第一件事就是修改密码。从命令行验证一下Docker客户端能不能登录# 先把自签CA加入到系统信任链 sudo cp ca.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust # 测试docker login docker login harbor.internal.example.com -u admin -p YourStrongPassw0rd如果这一步报x509证书不可信多数是CA没加到信任链或者证书SAN字段没配好。注意Docker守护进程有自己独立的证书校验逻辑光改系统信任链有时候还不够还得看daemon.json里是否配置了insecure-registries或registry证书路径。3.4 建项目、做第一次push登录Harbor之后首要任务是创建项目。Harbor里的“项目”就是镜像命名空间比如建一个library作为公共镜像库再给不同团队建独立项目。项目访问级别有公开和私有两种我建议默认全部私有只有明确需要跨团队共享的才设成公开。建好项目后本地给镜像打上Harbor的标签再推上去# 假设本地有个nginx镜像 docker tag nginx:1.25 harbor.internal.example.com/library/nginx:1.25 # push到Harbor docker push harbor.internal.example.com/library/nginx:1.25第一次push要特别注意镜像命名规范。Docker Hub的镜像名和Harbor上的命名规则不太一样凡是push到Harbor的镜像完整的名称一定是“Harbor域名/项目名/镜像名:tag”项目名不能省略也不能随意替换。很多同事第一次push时习惯性地写“harbor地址/镜像名:tag”结果报unauthorized原因就是少了项目这一层。4. 让Kubernetes集群真正用上Harbor4.1 容器运行时决定你改哪份配置这一步是Kubernetes与Harbor对接最核心也最容易踩坑的地方。首先搞清楚你的集群节点用的容器运行时是Docker还是containerd。Kubernetes 1.24之后Dockershim被移除但从1.26.0这个版本来看很多用KubeKey装的集群默认还是接了Docker作为运行时也有不少直接用containerd两种情况配置方式完全不同。如果节点用Docker配置在/etc/docker/daemon.json{ insecure-registries: [], registry-mirrors: [] }走HTTPS并且证书配好了的话更优雅的方式是把CA证书放到/etc/docker/certs.d/harbor.internal.example.com/ca.crt这样Docker会自动信任Harbor的证书不用开insecure-registries。如果节点用containerd改的是/etc/containerd/config.toml。注意不同containerd版本配置项写法差异很大新版1.7.x用的是这种结构[plugins.io.containerd.grpc.v1.cri.registry] [plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.harbor.internal.example.com] endpoint [https://harbor.internal.example.com] [plugins.io.containerd.grpc.v1.cri.registry.configs] [plugins.io.containerd.grpc.v1.cri.registry.configs.harbor.internal.example.com.tls] ca_file /etc/containerd/certs/harbor.internal.example.com/ca.crt [plugins.io.containerd.grpc.v1.cri.registry.configs.harbor.internal.example.com.auth] username admin password YourStrongPassw0rd这里有个我反复强调的坑改了config.toml之后一定要执行systemctl restart containerd只reload不生效。而且重启containerd会把集群里正在运行的容器全部杀掉所以这种配置应该在集群初始化之前一次性做好或者挑业务低峰期滚动操作。4.2 给Kubernetes创建镜像拉取凭证镜像仓库配好了还得让Kubernetes在创建Pod时知道用什么账号去拉镜像。这里需要创建docker-registry类型的Secretkubectl create secret docker-registry harbor-registry-secret \ --docker-serverharbor.internal.example.com \ --docker-usernameadmin \ --docker-passwordYourStrongPassw0rd \ --namespacedefault然后在Deployment的模板里引用这个Secretspec: template: spec: imagePullSecrets: - name: harbor-registry-secret containers: - name: my-app image: harbor.internal.example.com/library/my-app:v1.0.0这里有个团队协作层面的建议如果每个namespace都要从这个私有仓库拉镜像最好把Secret复制到所有namespace去或者直接配置在namespace的default service account上这样新创建的Pod默认就带上了imagePullSecrets不用每个YAML都写一遍。# 给默认service account绑定拉取凭证 kubectl patch serviceaccount default -p {imagePullSecrets: [{name: harbor-registry-secret}]}4.3 KubeKey离线包推送到Harbor的完整姿势你在实际环境中经常会遇到这种情况KubeKey下载好的离线安装包里带了Kubernetes组件镜像这些tar.gz需要统一推进Harbor让集群所有节点从Harbor拉取而不是每台机器都手动load一遍。这个操作要分几步走。先把离线包解压找到镜像文件tar -zxvf kubekey-v3.0.7-linux-amd64.tar.gz ls images/ # 这里会看到一堆.tar或.tar.gz的镜像包然后看当前节点用的是什么运行时。Docker运行时用docker loadcontainerd用ctr命令导入# Docker方式 docker load -i images/kubernetes.tar # containerd方式 ctr -n k8s.io images import images/kubernetes.tar镜像导入之后名字通常还是源仓库的形式比如k8s.gcr.io/kube-apiserver:v1.26.0。这时候需要重新打标签再推送到Harbor# 找到导入后的镜像名 docker images | grep kube-apiserver # 打标签Harbor域名/项目名/镜像名:tag docker tag k8s.gcr.io/kube-apiserver:v1.26.0 \ harbor.internal.example.com/library/kube-apiserver:v1.26.0 # 推送 docker push harbor.internal.example.com/library/kube-apiserver:v1.26.0如果镜像数量多一个个打标签很痛苦我写过一个批量处理脚本核心逻辑如下注意容器运行时是Docker的情况#!/bin/bash HARBORharbor.internal.example.com PROJECTlibrary docker images --format {{.Repository}}:{{.Tag}} | grep -v $HARBOR | while read img; do # 去掉仓库前缀只保留镜像名和tag name$(echo $img | awk -F/ {print $NF}) docker tag $img $HARBOR/$PROJECT/$name docker push $HARBOR/$PROJECT/$name echo pushed: $HARBOR/$PROJECT/$name done这里提醒一句批量脚本用起来很爽但会把本地所有非Harbor的镜像全推上去如果你本机有一些乱七八糟的临时镜像会被一起污染到Harbor仓库里。跑之前建议先docker images看一下或者加个白名单过滤。KubeKey这边除了手动推镜像还可以在创建集群时直接指定Harbor作为registry。集群配置文件里的registry段可以做类似这样的配置registry: type: harbor auths: - name: harbor.internal.example.com username: admin password: YourStrongPassw0rd这样KubeKey在初始化节点时会自动把Harbor地址和凭证写到各节点的容器运行时配置里整个集群从初始化开始就认这个私有仓库比装完再改配置要省事一个量级。5. 上线后的日常运维、备份与常见问题5.1 问题速查表从登录失败到push超时实际运行中我整理了一份排查清单平时遇到问题对着查能省不少时间。现象常见原因处理思路docker login提示x509证书不可信CA未加入系统信任链或证书SAN缺少域名检查ca.crt是否在正确位置用openssl x509 -in harbor.crt -noout -text查看SANpush镜像提示denied或unauthorized账号权限不足或镜像名里少了项目名确认Harbor账号对该项目有push权限检查镜像名是否包含项目名push大镜像时卡住或断开网络链路问题或Nginx超时配置过短检查内网链路质量看harbor-nginx日志必要时调大proxy_read_timeout浏览器访问能开但docker login失败Docker守护进程走了代理或DNS解析不一致检查daemon.json是否配了代理环境变量确认节点上域名解析结果一致Kubernetes拉镜像时报ImagePullBackOffSecret缺失或节点上Harbor证书不受信任kubectl describe pod看具体事件补充imagePullSecrets配置正确CA路径Harbor页面显示503 Service Unavailable后端容器健康检查失败或磁盘满了docker ps看容器状态df -h看磁盘空间docker logs看具体报错扫描功能一直停在pendingTrivy漏洞库未更新或离线环境无法下载离线环境设置trivy.skip_updatetrue或者手动导入漏洞库补充一个平时容易忽略的操作Harbor使用过程中如果修改了域名或证书除了改harbor.yml重新install之外Kubernetes节点上的/etc/hosts、/etc/docker/certs.d、/etc/containerd/config.toml这些位置都要同步清理掉旧配置。这种问题最坑的地方在于明明都改了但还报错结果一查是旧证书缓存在某个犄角旮旯没删干净。5.2 磁盘告警与镜像清理Harbor跑起来之后磁盘增长的速度往往超出预期。镜像仓库本身就是存储密集型的服务加上日志、数据库、Trivy扫描缓存数据量上得很快。我遇到过磁盘被写满导致整个Harbor假死的情况几个后端容器全变红页面打不开docker login也超时排查半天才发现是/分区100%了。预防手段是给Harbor的数据目录做单独的监控告警同时配置Harbor自带的垃圾回收。删除镜像的时候Harbor只是把tag标记为删除blob数据还在磁盘上占着空间需要手动触发GC才能真正释放在Harbor的Web界面里进入“系统管理” - “清理”可以设置垃圾回收的时间和保留策略。对于长期运行的仓库建议每周自动执行一次GC。命令行的替代方案是# 先进入harbor目录 cd /opt/harbor # 触发GC任务2.x版本支持 docker compose exec registry /bin/sh -c registry garbage-collect /etc/registry/config.yml注意GC执行时registry处于只读还是正常模式有不同考虑如果仓库处于高频写入状态建议安排在业务低峰期执行。5.3 备份与升级别等出了事才后悔很多团队搭好Harbor之后就不再管它了直到出了事故才发现没有任何备份。Harbor的备份核心是data_volume目录里面包含了数据库文件、镜像存储、配置等所有内容。最直接的备份方式就是整目录打包# 停服务备份最保险不停的话数据库文件可能不一致 docker compose down tar -czf harbor-backup-2025.tar.gz /data/harbor docker compose up -d如果希望不停机备份数据库可以使用PostgreSQL的pg_dump对registry、notary这几个数据库分别导出。不过整目录备份始终是最完整的兜底方案两种方式建议配合使用。升级Harbor的流程相对平滑下载新版本的离线安装包解压后把老版本的harbor.yml复制过去运行./install.sh自动检测已有数据并升级。升级前务必完整备份我曾经因为跨大版本升级没看升级说明结果数据库结构不兼容花了半天时间来回折腾。5.4 对接KubeKey时的几个低级错误用KubeKey装集群的朋友很容易碰到几个衔接问题这里集中提醒一下。第一个是KubeKey的config模板里有个registry配置经常有人把它直接留空结果集群初始化时默认还是从公共仓库拉镜像内网环境必然失败。装之前先确认集群配置文件的registry段已经指向Harbor地址并且各节点都能解析这个域名。第二个是推送离线包镜像时命名不一致。KubeKey离线包里的镜像名有的带k8s.gcr.io前缀有的不带有的tag带build号有的是纯版本号。推送到Harbor之后KubeKey初始化时拉取的名字是固定的如果tag对不上就会一路报“镜像不存在”。这个问题的规避方式是推镜像的时候保留原tag不要自己改成“latest”之类的tag除非你确认KubeKey的配置里也改成了同样的版本。第三个是混合运行时场景下的配置遗漏。如果集群里一部分节点用Docker一部分用containerd两边都需要单独配置Harbor的访问参数。经常有人只配了Docker侧就跑去出问题最后发现拉镜像的kubelet实际走的是containerd。6. 还能怎么玩HTTPS升级、LDAP认证与跨机房复制6.1 从HTTP平滑切到HTTPS如果你图省事先用HTTP搭起来了后面又想切HTTPS操作并不复杂但要注意顺序。先把证书文件准备好修改harbor.yml里的https段并注释掉http段然后./install.sh --with-trivy这里要提醒切换协议之后之前所有配置过HTTP地址的节点包括Docker daemon的insecure-registries、Kubernetes节点的config.toml都要同步改成HTTPS地址。改的过程中会有短暂的不一致期表现为有些节点还能push有些节点连不上。建议准备一个节点维护窗口把集群节点分批配置和重启避免所有节点同时不可用。6.2 对接LDAP告别一堆本地账号团队大了之后每个同事在Harbor上都要单独开账号管理员烦都烦死了。Harbor支持LDAP认证可以把企业现有的账号体系接进来实现“账号统一管理”。配置路径在“系统管理 - 认证设置”把认证模式切换为LDAP填上LDAP地址、Base DN、管理员DN和密码即可。配置完成后前端登录时用员工工号或邮箱就能直接登录权限还是按Harbor里的项目角色来分配。这个功能对超过20个人的团队基本是刚需否则每天都是开账号、重置密码的杂活。6.3 跨机房复制从单点变成多点可用如果公司有两个机房或者多套Kubernetes集群Harbor的镜像复制功能很实用。在“系统管理 - 复制管理”里可以创建复制规则指定源项目和目标Harbor实例Harbor会自动把镜像同步过去。复制模式有push和pull两种push模式主动推到目标仓库pull模式从源拉取。我通常建议在灾备机房配一套Harbor主仓库配push规则业务镜像实时同步到灾备这样主库故障时另一套环境可以直接顶上。复制的时候Harbor只会同步增量层不会每次都全量传输带宽占用比较可控。实际操作中的一点体会这套Harbor搭完之后最直观的感受是Kubernetes集群创建Pod的速度明显快了原来从公共仓库拉镜像经常卡在“pull image”这一步几分钟现在内网秒级完成。但更深的体会是基础设施这块能提前规划的千万不要拖到出事再补救。证书方案、备份策略、监控告警这些刚开始看似麻烦的东西后面都会以“幸好当时做了”的方式回报你。如果你也在搭Kubernetes私有仓库我的建议是第一次部署尽量按官方默认流程走确认跑通之后再按需定制把证书和域名一次性规划好别为了一时省事给后续埋坑上线之后启用GC和监控镜像仓库这玩意运行半年之后的磁盘占用绝对超乎你的预期。