docker-registry Secret 里面是什么
这类 Secret（类型 kubernetes.io/dockerconfigjson）的内容与 docker 客户端的 config.json 同构：auths 下按仓库地址分组，每项里的 auth 是「用户名:密码」再做 base64 得到的字符串。kubelet 拉取私有镜像时读取它完成认证。也正因结构透明，排障方式很直接：取出 .dockerconfigjson 字段、base64 解码，核对仓库地址、用户名与密码是否正确。
基本信息
| Secret 类型 | kubernetes.io/dockerconfigjson |
|---|---|
| 数据键 | .dockerconfigjson，值是 base64 编码的 JSON |
| 内容结构 | auths → 仓库地址 → auth（base64 的 用户名:密码） |
| 创建方式 | kubectl create secret docker-registry，或用 --from-file=.dockerconfigjson 导入 |
| 权限建议 | 只授权能拉取的目标仓库，避免使用个人账号 |
典型使用场景
- 拉取私有镜像：为工作负载提供仓库认证凭据
- 多仓库支持：一份 config.json 里包含多个仓库的认证信息
- 凭据轮换：仓库密码更新后同步替换 Secret 内容
- 故障定位：解码核对内容，判断是凭据问题还是网络问题
- 权限收敛：为 CI 或运维单独创建只读拉取权限的机器人账号
解码核对
解码核对
kubectl get secret regcred -n prod -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d
kubectl get secret regcred -n prod -o jsonpath='{.type}'
kubectl describe pod web-x -n prod | grep -i -A2 'Failed to pull' # 拉取失败的具体报错
kubectl get events -n prod --field-selector reason=Failed --sort-by=.lastTimestamp | tail从现有文件创建
从现有文件创建
kubectl create secret generic regcred -n prod \
--from-file=.dockerconfigjson=$HOME/.docker/config.json \
--type=kubernetes.io/dockerconfigjson
kubectl create secret docker-registry regcred -n prod \
--docker-server=registry.example.com \
--docker-username=robot$pull --docker-password=<密码> --docker-email=ops@example.com内容字段与排错提示
| 字段 | 含义 | 排错提示 |
|---|---|---|
| auths | 按仓库地址分组的认证项 | 地址必须与镜像引用中的仓库完全一致，含端口 |
| auth | base64 后的用户名与密码 | 手工拼接容易漏补结尾等号或混入换行 |
| 多仓库项 | 一份文件可包含多个仓库 | 整体导入时确认目标仓库都在其中 |
手工拼 JSON 时常见错误是 base64 少写结尾的等号或带入换行：这类问题会让认证失败，而 kubelet 的报错比较笼统，容易把方向引向网络排查。
这类 Secret 等价于仓库密码：排查凭据泄漏时先确认哪些主体能读取它，并尽量使用只具备拉取权限的机器人账号而不是个人账号。
排查顺序建议固定为：先看 Pod 事件里的拉取报错文本，再解码核对 Secret 内容，最后才怀疑仓库或网络；多数拉取失败在第二步就能定位，能省下大量无效尝试。