Kubernetes节点不直接配置认证，而是通过容器运行时预置认证和Kubernetes Secret+imagePullSecrets两种机制协同实现私有镜像拉取；前者在宿主机级配置docker或containerd的config.json，后者为原生推荐方案，将凭据存为集群资源并绑定到Pod或ServiceAccount。Kubernetes 节点本身不直接“配置认证”，而是通过两种协同机制让 Pod 能拉取私有镜像：**节点上的容器运行时（Docker 或 containerd）需能访问仓库**，**Kubernetes 层面需提供合法凭据供调度器和 kubelet 使用**。二者缺一不可，但侧重点不同。 下面分两个关键路径说明如何在节点层面支撑私有镜像拉取：
1. 容器运行时预置认证（宿主机级）
这是最底层的保障——确保每个 worker 节点上的 docker 或 containerd 本身知道怎么登录你的私有仓库。
操作本质是把 ~/.docker/config.json（含 base64 编码的 username:password）放到每个节点的指定位置：
- 对 Docker：复制到
/root/.docker/config.json（kubelet 默认以 root 运行，读该路径） - 对 containerd：需额外配置
plugins."io.containerd.grpc.v1.cri".registry.configs段落，或使用auths映射到/etc/containerd/config.toml
典型做法（Docker）：
docker login https://my-registry.example.com -u admin -p 'xxx'<br>scp /root/.docker/config.json node01:/root/.docker/config.json<br>systemctl restart docker
⚠️ 注意：该方式跳过 Kubernetes Secret 管理，适合开发/单集群测试；但凭据明文落盘、无法轮换、不审计，**生产环境不推荐单独使用**。
2. Kubernetes Secret + imagePullSecrets（推荐主线）
这才是 Kubernetes 原生、安全、可审计的方案。它不依赖节点本地配置，而是把凭证存为集群资源，并显式绑定到工作负载。
分三步走：
-
创建 Secret：
kubectl create secret docker-registry regcred \<br> --docker-server=https://my-registry.example.com \<br> --docker-username=admin \<br> --docker-password=xxx \<br> --docker-email=user@example.com
-
绑定到 Pod 或 ServiceAccount：
– 单个 Pod：spec.imagePullSecrets: [{name: regcred}]
– 全局生效（更常用）：kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "regcred"}]}' -
验证是否生效：
部署一个引用私有镜像的 Pod，检查事件：kubectl describe pod xxx | grep -A5 Events。不再出现ErrImagePull或ImagePullBackOff即成功。
3. 补充要点：避免常见坑
即使 Secret 创建正确，仍可能失败，需核对：
-
Registry 地址必须完全一致：Secret 中的
--docker-server必须和镜像 tag 前缀严格匹配（如https://harbor.example.comvsharbor.example.com，协议和端口都不能少） - 命名空间要对齐：Secret 和 Pod 必须在同一 namespace，除非用 ServiceAccount 绑定并确保该 SA 被 Pod 引用
- 时间同步很重要：若用 token 或短期凭证（如 ECR 登录令牌），节点系统时间偏差 >5 分钟会导致认证拒绝
-
非 HTTPS 仓库需额外声明：Docker daemon 需在
/etc/docker/daemon.json加"insecure-registries": ["my-registry.example.com:5000"]并重启
