1. 为什么非得自己搭私有仓库？——从“镜像拉取失败”说起
上周五下午三点，某跨平台系统上线前的最后一次集成测试突然卡住。CI流水线在docker pull阶段持续超时，日志里反复刷着Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection。团队立刻切到公网镜像源排查，发现 Docker Hub 正在对未登录用户限流——每6小时仅允许200次匿名拉取。而我们的构建流程单次触发就要拉取 base 镜像、golang 编译环境、alpine 运行时、prometheus exporter 等7个镜像。200次？连一轮完整构建都撑不过去。
那一刻我才真正意识到：所谓“Docker开箱即用”，只适用于玩具项目。一旦进入真实交付场景，依赖公共仓库=把生产命脉交到别人手里。你无法控制镜像版本生命周期（Docker Hub 上golang:1.21-alpine昨天还是 SHA256:a1f…，今天就可能被覆盖成 SHA256:b3c…）；你无法审计镜像内容（某次更新悄悄引入了非官方编译的curl二进制）；你更无法保障可用性（去年某次 Docker Hub 全球性故障导致连续47分钟无法拉取任何镜像）。而私有仓库不是“锦上添花”的选配项，它是服务可重复部署、安全可追溯、交付可预期的基础设施底线。
这和 Go 服务部署天然耦合。Go 的静态编译特性让二进制体积小、依赖少，但恰恰因此，它对运行环境的“纯净度”要求更高——一个被污染的基础镜像，会把漏洞直接焊进最终二进制里。我们曾遇到过这样的情况：开发本地go build出来的二进制，在测试环境跑得好好的，一上生产就 panic，最后发现是 CI 构建机上的glibc版本比生产容器高了0.3个补丁号，而某个第三方 Cgo 包恰好踩中了这个 ABI 变更点。私有仓库在这里扮演的是“可信锚点”角色：所有镜像必须经由统一构建流水线生成、签名、推送到私有仓库，再由 K8s 或 docker-compose 拉取。整个链路里，只有私有仓库这一个可信出口。
所以，搭建私有仓库这件事，本质不是“我会不会用docker run registry”，而是“我能否建立一套不依赖外部网络、版本可控、安全可验的交付闭环”。它解决的从来不是技术问题，而是工程确定性问题。接下来要做的，不是复制粘贴几条命令，而是亲手把这套闭环的每个齿轮都装紧、调准、上油。
2. Registry 服务选型：别被“一行命令启动”骗了
很多人第一次接触私有仓库，看到官方文档里docker run -d -p 5000:5000 --restart=always --name registry registry:2这行命令，就以为万事大吉。我试过，真的只用了37秒就跑起来了。然后第38秒，我就开始改配置——因为默认配置连最基础的生产需求都满足不了。
Registry 官方镜像（registry:2）本身是个极简内核，它只负责存储和分发镜像层（blob）与清单（manifest），其他一切功能都靠配置文件驱动。而生产环境需要的，远不止“存和取”这么简单：
- 认证：不能让任何人
docker login your-registry:5000后就拥有全部权限； - HTTPS：Docker 客户端默认拒绝向 HTTP 仓库推送镜像（
insecure-registries是临时方案，不是解法）； - 存储后端：默认用本地文件系统
/var/lib/registry，这在单机测试没问题，但集群化、高可用、备份恢复全抓瞎； - 垃圾回收：没人清理的镜像会无限膨胀，磁盘爆满是常态；
- 可观测性：没有日志、没有指标、没有健康检查，出问题只能靠猜。
于是我们做了三轮对比测试，覆盖了三种主流方案：
| 方案 | 核心组件 | 认证方式 | 存储后端 | HTTPS 支持 | 垃圾回收 | 部署复杂度 | 适合场景 |
|---|---|---|---|---|---|---|---|
| Registry + nginx + htpasswd | registry:2 + nginx:alpine | Basic Auth (htpasswd) | 本地文件 / NFS / S3 | ✅ (nginx 终止 TLS) | ✅ (需手动触发) | 中等（需配 nginx 和证书） | 小团队、快速验证、预算有限 |
| Harbor | harbor-core + harbor-registry + clair/trivy | RBAC + LDAP/AD + OIDC | 本地 / NFS / S3 / OSS | ✅ (内置 nginx) | ✅ (UI 一键触发) | 高（需管理 7+ 个容器） | 中大型团队、需合规审计、多租户 |
| Nexus Repository 3 | nexus:3 | RBAC + LDAP/AD | 本地 / S3 / Azure Blob | ✅ (内置 Jetty) | ✅ (策略驱动) | 高（Java 应用，内存占用大） | 已有 Nexus 生态、需统一管理 Maven/Docker/Helm |
最终我们选了第一种：Registry + nginx + htpasswd。不是因为它最好，而是因为它最可控、最透明、最易调试。Harbor 功能强大，但它的 7 个容器之间通过 Redis、PostgreSQL、RabbitMQ 多重通信，一旦harbor-core报failed to get project info，你得先查 PostgreSQL 日志，再看 Redis 连接池，最后翻 Harbor 自己的日志格式——三层抽象叠在一起，定位问题的时间成本远高于解决问题本身。而 nginx + registry 的组合，所有日志都在明处：nginx access.log 记录谁在什么时候拉取了哪个镜像，registry 的 loglevel=debug 能直接看到 blob 是否存在、manifest 是否校验通过。当你的目标是“快速建立一条确定性的交付链路”，而不是“建设一个企业级制品中心”，轻量就是正义。
提示：不要用
htpasswd -c重复创建密码文件。-c参数会清空原有用户。新增用户务必去掉-c，否则你会在凌晨三点发现运维账号被删了，而备份脚本还没写完。
3. Go 服务镜像构建：为什么不用FROM golang:1.21直接编译？
这是新手最容易踩的坑：看到 Go 官方镜像有golang:1.21-alpine，就理所当然地FROM golang:1.21-alpine，然后COPY . /app，RUN go build -o /app/server /app/main.go，最后CMD ["/app/server"]。镜像能跑，但隐患埋得极深。
问题出在构建环境与运行环境的割裂。golang:1.21-alpine镜像里装的是 Alpine Linux 的musl libc，而你的 Go 代码如果用了net包（几乎必然用），它在编译时会链接musl的 DNS 解析逻辑。但生产环境的 Kubernetes 集群，很可能运行在 Ubuntu/CentOS 主机上，其容器运行时（containerd）底层用的是glibc。虽然 Go 的静态编译能打包大部分依赖，但 DNS 解析这种需要调用系统库的功能，依然会受宿主机libc影响。我们曾在线上遇到过一种诡异现象：服务在测试集群（Ubuntu）里能正常解析redis.default.svc.cluster.local，一上生产（CentOS）就超时，strace一看，getaddrinfo系统调用卡在connect上，根本没发出去——根源就是 musl 和 glibc 对nsswitch.conf的处理逻辑不同。
真正的生产级构建，必须遵循“构建即运行”原则：构建阶段用的镜像，和最终运行的镜像，底层 OS 和 libc 必须一致。我们采用的是多阶段构建（Multi-stage Build），但关键在于两个阶段的基座要严格对齐：
# 构建阶段：使用与运行时完全一致的 alpine 镜像 FROM alpine:3.19 AS builder # 安装 go 构建工具链（注意：不是 golang 镜像！） RUN apk add --no-cache go=1.21.6-r0 git make WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . # 关键：显式指定 CGO_ENABLED=0，强制纯静态链接 RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o server . # 运行阶段：复用同一份 alpine 基础镜像 FROM alpine:3.19 RUN apk --no-cache add ca-certificates WORKDIR /root/ # 仅拷贝构建好的二进制，不带任何构建依赖 COPY --from=builder /app/server . CMD ["./server"]这个写法有三个硬性要求：
alpine:3.19必须精确指定。不能写alpine:latest，因为latest会变，今天是 3.19，明天可能是 3.20，而go=1.21.6-r0这个包名只存在于 3.19 的 apk 仓库里。版本漂移是生产环境的大敌。CGO_ENABLED=0是铁律。只要你的 Go 代码不调用 C 代码（比如sqlite3、openssl），就必须关掉 CGO。它能确保生成的二进制不依赖任何动态库，真正做到“扔哪都能跑”。-ldflags '-extldflags "-static"'是保险丝。即使某些间接依赖偷偷启用了 CGO，这个参数也会强制链接器把所有东西都打进去，避免运行时找不到libgcc_s.so.1这类幽灵库。
实测下来，这样构建出的镜像大小只有 12MB（含 CA 证书），启动时间 < 80ms，且在 Ubuntu、CentOS、Rocky Linux 三种发行版的 K8s 集群里表现完全一致。这才是 Go “一次编译，到处运行”的正确打开方式。
4. 私有仓库与 Go 服务的深度集成：从推送、拉取到自动部署
光有仓库和镜像还不够，必须把它们串成一条自动化的流水线。我们设计的集成路径是：代码提交 → CI 构建 → 推送至私有仓库 → K8s 自动拉取并滚动更新。其中，推送和拉取这两个动作，藏着大量容易被忽略的细节。
4.1 推送环节：认证、命名、标签的三位一体
推送不是docker push your-registry:5000/myapp:v1.0.0就完事。它涉及三个强耦合环节：
- 认证：
docker login your-registry:5000输入的用户名密码，必须和 nginx 配置的htpasswd文件完全一致。我们给每个服务分配独立账号（如myapp-ci），密码用openssl rand -base64 32生成，绝不复用。 - 命名：仓库地址必须带端口（
your-registry:5000），且myapp这部分叫repository name，它对应 Registry 内部的一个命名空间。我们约定：<team>/<service>，比如backend/user-service。这样在 Harbor 里能天然形成项目结构，即使现在用轻量方案，也为未来升级留了接口。 - 标签：
v1.0.0这种语义化版本是必须的，但绝不能只打一个标签。我们强制要求每次构建打三个标签：v1.0.0（语义化版本，用于人工回滚）sha-<commit-hash>（Git 提交哈希，用于精准溯源）latest（仅用于开发分支，主干分支禁用）
为什么？因为latest标签是“活”的，它永远指向最新构建。如果 CI 流水线没做隔离，A 分支的构建覆盖了latest，B 分支的部署就会拉到错误的镜像。而sha-<hash>标签是“死”的，它永远绑定那次构建，git bisect时可以直接kubectl set image deploy/user-service user-service=your-registry:5000/backend/user-service:sha-abc123。
4.2 拉取环节：K8s 的imagePullSecrets与imagePullPolicy
K8s Pod 拉取私有仓库镜像，核心是两个字段：
apiVersion: v1 kind: Pod metadata: name: user-service spec: containers: - name: user-service image: your-registry:5000/backend/user-service:v1.0.0 # 关键：告诉 K8s 用哪个 Secret 去认证 imagePullSecrets: - name: regcred # 关键：避免 K8s 自作聪明去拉 latest imagePullPolicy: IfNotPresentregcred这个 Secret 怎么来？不是手动生成，而是用kubectl create secret docker-registry命令：
kubectl create secret docker-registry regcred \ --docker-server=your-registry:5000 \ --docker-username=myapp-ci \ --docker-password='your-generated-password' \ --docker-email=not@used.com这个命令会把用户名密码 Base64 编码后存入 Secret。注意：--docker-server的值必须和image字段里的仓库地址完全一致，包括协议（这里没写https://，因为 K8s 默认走 HTTP，而我们的 nginx 配置了 301 重定向到 HTTPS，所以实际走的是 HTTPS）。如果写成https://your-registry:5000，K8s 会尝试用 HTTPS 直连，而我们的 nginx 没开 443 端口，结果就是ImagePullBackOff。
imagePullPolicy: IfNotPresent是另一个关键。默认值是Always，它会让 K8s 每次启动 Pod 都去仓库校验镜像是否更新。但在私有仓库场景下，这毫无意义——你推送的镜像是不可变的（v1.0.0永远是那个 SHA256），校验只是徒增网络开销和失败风险。IfNotPresent表示“本地有就用本地的”，配合 CI 流水线的docker pull && docker build && docker push三步，能确保节点上永远有最新镜像，又避免了无谓的网络请求。
4.3 自动部署：用kubectl set image实现零停机发布
我们不用 Helm 或 ArgoCD 做初始部署，而是用最原始的kubectl apply -f deployment.yaml创建 Deployment，然后用kubectl set image触发滚动更新。原因很简单：它最透明、最可控、最易审计。
kubectl set image deploy/user-service user-service=your-registry:5000/backend/user-service:v1.0.1这条命令，背后发生的是：
- K8s API Server 接收请求，更新 Deployment 的
.spec.template.spec.containers[0].image字段； - Deployment Controller 检测到模板变更，生成一个新的 ReplicaSet；
- 新 ReplicaSet 按
maxSurge=25%、maxUnavailable=25%策略，逐个创建新 Pod，同时销毁旧 Pod； - 整个过程，Service 的 Endpoints 列表实时更新，流量平滑切换。
全程无需重启 Deployment，无需删除重建，kubectl rollout status deploy/user-service就能看到实时进度。更重要的是，所有操作都记录在 K8s audit log 里，谁在什么时间更新了哪个镜像，一查便知。这比任何 GUI 界面都可靠。
注意：
kubectl set image更新的是 Deployment 的 Pod 模板，它会触发滚动更新，但不会更新 ConfigMap 或 Secret。如果你的服务配置也随版本变化，必须同步执行kubectl rollout restart deploy/user-service，强制所有 Pod 重新加载挂载的配置。
5. 安全加固：从 TLS 证书到镜像签名，一条都不能少
私有仓库一旦暴露在内网，就不再是“自家后院”，而是整个交付链路的咽喉。我们花了整整两周时间做安全加固，核心是三个层次：
5.1 传输层：Nginx 终止 TLS，强制 HTTPS
Registry 官方不直接支持 HTTPS，必须用反向代理（nginx）来终止 TLS。我们用的是 Let's Encrypt 的certbot自动生成证书：
# 在 nginx 宿主机上执行 certbot certonly --standalone -d your-registry.your-domain.com # 证书生成在 /etc/letsencrypt/live/your-registry.your-domain.com/nginx 配置的关键片段：
upstream docker-registry { server localhost:5000; } server { listen 443 ssl http2; server_name your-registry.your-domain.com; ssl_certificate /etc/letsencrypt/live/your-registry.your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-registry.your-domain.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; location / { proxy_pass http://docker-registry; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键：透传认证头，让 registry 能拿到用户信息 proxy_set_header Authorization $http_authorization; proxy_pass_request_headers on; } }这里有个致命陷阱：proxy_set_header Authorization $http_authorization;这行必须加上。否则，nginx 作为反向代理，会把客户端的Authorization: Basic xxx头过滤掉，registry 收不到认证信息，所有请求都会返回401 Unauthorized。我们为此调试了 6 小时，最后在 nginx error.log 里看到client sent no required SSL certificate才恍然大悟——不是证书问题，是头被吃了。
5.2 镜像层：用cosign实现不可篡改签名
有了 HTTPS，传输安全了，但镜像内容本身还是裸奔。谁能保证your-registry:5000/backend/user-service:v1.0.0这个镜像，真的是 CI 流水线构建出来的，而不是被中间人替换成带后门的版本？答案是数字签名。
我们选用 CNCF 毕业项目cosign，它基于 Sigstore 体系，用公钥密码学为镜像生成签名：
# 1. 生成密钥对（私钥本地保管，公钥上传到 K8s） cosign generate-key-pair # 2. 构建并推送镜像后，立即签名 docker push your-registry:5000/backend/user-service:v1.0.0 cosign sign --key cosign.key your-registry:5000/backend/user-service:v1.0.0 # 3. 在 K8s 节点上，用公钥验证 cosign verify --key cosign.pub your-registry:5000/backend/user-service:v1.0.0cosign的签名不是存在镜像里，而是作为一个独立的 artifact，推送到同一个仓库的your-registry:5000/backend/user-service:v1.0.0.sig路径下。K8s 的ImagePolicyWebhook或 OPA Gatekeeper 可以在 Pod 创建前，调用cosign verify命令检查签名有效性。如果签名无效或公钥不匹配，Pod 创建直接被拒绝。这相当于给每个镜像加了一把“数字指纹锁”。
5.3 运行时：podSecurityContext与securityContext的双重防护
最后，是容器运行时的安全。Go 服务默认以 root 用户运行，这是巨大风险。我们在 Deployment 的 Pod 模板里强制添加：
securityContext: runAsNonRoot: true runAsUser: 65532 runAsGroup: 65532 fsGroup: 65532 seccompProfile: type: RuntimeDefaultrunAsNonRoot: true是开关，它让 K8s 在创建 Pod 时检查：如果容器镜像的USER指令不是 root（UID 0），才允许启动。runAsUser: 65532是一个非特权 UID，我们把它写死在 Dockerfile 里：
# 在构建阶段末尾添加 USER 65532:65532seccompProfile: type: RuntimeDefault是另一道锁。它启用容器运行时（containerd）的默认 seccomp 过滤规则，禁止容器调用ptrace、mount、setuid等危险系统调用。即使 Go 服务被攻破，攻击者也无法利用这些 syscall 进行提权或逃逸。
这三重防护——TLS 加密传输、cosign 签名验证、seccomp 运行时限制——构成了我们私有仓库与 Go 服务的完整安全基线。它不追求“绝对安全”，而是确保每一次部署，都经过可验证、可审计、可约束的确定性流程。
6. 故障排查实战：从unauthorized到invalid manifest的完整链路
再完美的设计，也会遇到报错。我把过去三个月遇到的 7 类高频故障，按排查顺序整理成一张表，并附上根因和修复命令。这不是理论，是凌晨两点盯着 terminal 一行行grep出来的血泪经验。
| 报错现象 | 日志关键词 | 根因定位步骤 | 修复方案 | 修复命令示例 |
|---|---|---|---|---|
unauthorized: authentication required | 401 Unauthorized | 1.kubectl get secret regcred -o yaml看docker-server是否匹配2. echo "xxx" | base64 -d解码密码，确认是否正确3. curl -v https://your-registry:5000/v2/看 nginx 是否返回 401 | nginx 未透传 Authorization 头 | proxy_set_header Authorization $http_authorization;加入 nginx 配置，nginx -s reload |
no basic auth credentials | Error response from daemon: Get https://.../v2/: no basic auth credentials | 1.docker info | grep -i 'insecure-registries'看是否配置了不安全仓库2. cat ~/.docker/config.json看auths字段是否有对应 registry 条目 | Docker 客户端未登录该 registry | docker login your-registry:5000 -u myapp-ci -p 'password' |
invalid manifest: manifest invalid | manifest invalid | 1.curl -X GET https://your-registry:5000/v2/backend/user-service/manifests/sha-abc123看返回2. docker manifest inspect your-registry:5000/backend/user-service:sha-abc123 | 镜像推送时网络中断，manifest 未完整写入 | docker push your-registry:5000/backend/user-service:sha-abc123重推 |
failed to register layer: devmapper | devmapper | 1.df -h /var/lib/docker看磁盘是否满2. docker system df看镜像、容器、卷占用 | Registry 存储目录磁盘满，GC 未触发 | docker exec registry /bin/registry garbage-collect /etc/docker/registry/config.yml |
x509: certificate signed by unknown authority | x509 | 1.openssl s_client -connect your-registry:5000 -servername your-registry.your-domain.com看证书链2. curl -v https://your-registry.your-domain.com/v2/看是否返回 200 | K8s 节点缺少 Let's Encrypt 根证书 | apk add --no-cache ca-certificates并update-ca-certificates |
context deadline exceeded | context deadline exceeded | 1.ping your-registry.your-domain.com看网络连通性2. telnet your-registry.your-domain.com 443看端口是否开放 | nginx 配置了listen 443 ssl，但防火墙未放行 443 | ufw allow 443或云厂商安全组放行 |
rpc error: code = Unknown desc = failed to pull and unpack image | failed to pull and unpack | 1.crictl pull your-registry:5000/backend/user-service:v1.0.0在节点上直连测试2. journalctl -u containerd -n 100看 containerd 日志 | containerd 配置未添加私有仓库为 insecure-registries（仅限 HTTP 测试） | sed -i '/\[plugins."io.containerd.grpc.v1.cri".registry.configs\]/a \ \ \ \ \"your-registry:5000\": {\"skip_tls_verify\": true}' /etc/containerd/config.toml |
这张表的核心逻辑是：永远从客户端（Docker/K8s）开始，逐层向服务端（nginx/registry）推进。不要一上来就怀疑 registry 配置错了，先确认docker login能成功，再确认curl能拿到 200，最后才查 registry 的日志。每一层都有明确的验证命令，把模糊的“报错”变成具体的“哪一层断了”。
比如invalid manifest这个错误，新手常以为是 Go 构建的问题，其实是推送中断导致的。curl直接请求 manifest 接口，如果返回{"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown"}，说明 registry 根本没存这个 manifest，那肯定是推送环节的事，和 Go 代码无关。
排查的本质，是把一个混沌的错误，分解成若干个可验证的原子命题。而这张表，就是我们团队内部的“原子命题清单”。
7. 运维与监控：让私有仓库自己开口说话
仓库搭好了，服务跑起来了，但没人盯着，它就是一颗定时炸弹。我们给私有仓库加了三层监控：日志、指标、健康检查。目标不是“出了问题再修”，而是“问题发生前就预警”。
7.1 日志：用rsyslog统一收集，grep就是生产力
Registry 默认日志输出到 stdout，但生产环境必须落盘并集中。我们没上 ELK，而是用最朴素的rsyslog：
# /etc/rsyslog.d/registry.conf if $programname == 'registry' then /var/log/registry/registry.log & stop然后写了个简单的日志分析脚本，每天凌晨 2 点执行：
#!/bin/bash # /usr/local/bin/registry-log-check.sh LOG="/var/log/registry/registry.log" # 统计过去24小时 401 错误次数 UNAUTH=$(grep "$(date -d '24 hours ago' '+%Y-%m-%d %H')" $LOG \| grep '401' \| wc -l) # 统计过去24小时 500 错误次数 ERROR500=$(grep "$(date -d '24 hours ago' '+%Y-%m-%d %H')" $LOG \| grep '500' \| wc -l) if [ $UNAUTH -gt 100 ]; then echo "ALERT: Too many 401 errors ($UNAUTH) in last 24h" \| mail -s "Registry Alert" ops@team.com fi if [ $ERROR500 -gt 10 ]; then echo "ALERT: Too many 500 errors ($ERROR500) in last 24h" \| mail -s "Registry Alert" ops@team.com fi为什么不用 Prometheus？因为 Registry 的原生 metrics 端点（/metrics）只暴露了极少数指标（如registry_http_in_flight_requests），对业务无感。而日志里的401是认证失败，500是内部错误，200的GET /v2/是健康心跳——这些才是运维真正关心的信号。grep虽土，但足够快、足够准、足够直接。
7.2 指标：用registry自带的/metrics做基础水位监控
虽然原生指标少，但registry的/metrics端点还是有价值的。我们用node_exporter的textfile_collector抓取它：
# /var/lib/node_exporter/textfile_collector/registry.prom # HELP registry_storage_cache_size_bytes Cache size in bytes # TYPE registry_storage_cache_size_bytes gauge registry_storage_cache_size_bytes{instance="registry"} 123456789 # HELP registry_http_in_flight_requests Current number of in-flight requests # TYPE registry_http_in_flight_requests gauge registry_http_in_flight_requests{instance="registry"} 3然后在 Prometheus 里设告警规则：
- alert: RegistryHighInFlightRequests expr: registry_http_in_flight_requests > 10 for: 5m labels: severity: warning annotations: summary: "Registry has too many in-flight requests" description: "Current value is {{ $value }}. Check if there's a client loop or network issue."in_flight_requests > 10持续 5 分钟，基本可以判定是某个客户端（比如 CI 流水线）在疯狂重试，或者网络抖动导致请求堆积。这时就要去看日志里是不是有大量context deadline exceeded。
7.3 健康检查：/healthz不是摆设，是救命稻草
Registry 官方没提供/healthz，但我们用 nginx 加了一层：
location /healthz { return 200 'OK'; add_header Content-Type text/plain; }然后在 K8s 的 livenessProbe 里调用它：
livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3这个探针的意义在于：它不检查 registry 是否能存取镜像，只检查 nginx 是否活着。因为 registry 进程挂了，nginx 会 502；nginx 配置错了，会 500；只有 nginx 和 registry 都正常，/healthz才返回 200。K8s 一旦探测失败三次，就会自动重启 Pod，把故障隔离在单个实例内，避免影响全局。
注意：
/healthz必须是 HTTP，不能是 HTTPS。因为 livenessProbe 默认不校验证书，如果配成https://localhost/healthz，会报x509: certificate signed by unknown authority。所以 nginx 的 healthz 端点，我们只监听 80 端口，不走 TLS。
这三层监控，日志是“事后诸葛亮”，指标是“事中雷达”，健康检查是“事前保险丝”。它们共同作用，让私有仓库从一个黑盒，变成一个会呼吸、会报警、会自愈的活体系统。
8. 我的个人体会：私有仓库不是终点，而是交付确定性的起点
写完这篇长文，我重新翻了一遍我们第一个 Go 服务上线时的 Slack 记录。那是 2022 年 3 月，凌晨一点，A 同学发了一条消息：“docker push卡住了，Docker Hub 限流了，CI 流水线红了。” B 同学回：“先docker tag成localhost:5000/myapp，然后docker push到本地 registry。” C 同学说：“本地 registry 没配 HTTPS，K8s 拒绝拉取。” 最后，我们手忙脚乱地用--insecure-registry参数重启了所有节点的 Docker daemon，才勉强把服务推上去。
现在回头看，那不是技术问题，而是认知问题。我们当时把私有仓库当成一个“替代 Docker Hub 的存储桶”，却没意识到，它真正的价值在于把交付过程从“概率事件”变成“确定性事件”。每一次docker push，都是对构建产物的一次固化；每一次kubectl set image，都是对部署动作的一次原子化；每一次cosign verify，都是对供应链安全的一次确认。
所以，如果你正在读这篇文章，准备动手搭建自己的私有仓库，请记住：不要追求“最快跑起来”，而要追求“最稳跑下去”。多花两小时配好 nginx 的 TLS，能省下未来三个月排查x509错误的时间；多写五行CGO_ENABLED=0，能避免线上出现无法复现的 DNS 解析故障；多建一个sha-<hash>标签，能让一次回滚从“祈祷别出错”变成“复制粘贴就搞定”。
技术本身没有魔法，魔法在于你如何用它消除不确定性。当你的 Go 服务镜像，从开发机
