512. 【kubernetes】解决registry私有仓库-pull-镜像失败问题

文章描述了在CentOS和Ubuntu环境下,Kubernetes集群内部拉取私有仓库镜像时遇到的证书错误。问题在于Kubernetes无法自动识别私有仓库的证书。解决方案包括将证书导入系统信任存储,并重启containerd服务。在CentOS中,需要更新CA信任并重启containerd,而在Ubuntu中,需将证书复制到`/usr/local/share/ca-certificates`,更新CA证书,然后重启containerd。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

环境说明:

我registry搭建的环境在centos7上,在出现报错之前,已经在将registry的证书放在了/etc/containerd/certs.d/registry.xxxxxxxxx.cn/registry.xxxxxxxxx.cn.crt目录下,结果在kubernetes集群内部 pull 镜像时,还是出现了下面的报错:

Failed to pull image "registry.xxxxxxxxx.cn/xxxxxxxxx-server:0.0.11": rpc error: code = Unknown desc = failed to pull and unpack image "registry.xxxxxxxxx.cn/xxxxxxxxx-server:0.0.11": failed to resolve reference "registry.xxxxxxxxx.cn/xxxxxxxxx-server:0.0.11": failed to do request: Head "https://registry.xxxxxxxxx.cn/v2/xxxxxxxxx-server/manifests/0.0.11": x509: certificate signed by unknown authority
  • 在 kubernetes 集群外部用 nerdctl pull 镜像时没问题的,能读取 /etc/containerd/certs.d/domin/domain.crt证书,并认证成功

这里猜测是kubernetes不会去自动读取镜像私有仓库的证书

解决步骤

cp /etc/containerd/certs.d/registry.xxxxxxxxx.cn/registry.xxxxxxxxx.cn.crt /etc/pki/ca-trust/source/anchors/
ln -s /etc/pki/ca-trust/source/anchors/registry.xxxxxxxxx.cn.crt /etc/ssl/certs/registry.xxxxxxxxx.cn.crt
update-ca-trust 
systemctl restart containerd #  可能只需要这一步就可以了
  • 先是按照centos 导入证书的操作,导入 domain.crt
  • 再是重启 containerd。(这里我就没有继续细化去验证了,我觉得不导入domain.crt ,直接重启 containerd 也能解决问题。)

OK。
[2022-12-07验证]:确实需要导入 domain.crt,直接重启 containerd 是不行的。ubuntu 证书导入步骤如下:

root@OpenStack:~#  cp /etc/containerd/certs.d/registry.xxxxxxxxx.cn/registry.xxxxxxxxx.cn.crt /usr/local/share/ca-certificates/
root@OpenStack:~#  update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
root@OpenStack:~#  systemctl restart containerd.service 
<think>嗯,用户问的是如何检查Docker私有仓库10.8.3.219上的镜像crm-web:master的完整性。首先,我需要理解用户的需求。他们可能是在部署应用时,想要确保从私有仓库拉取的镜像没有被篡改或者损坏,特别是在生产环境中,镜像的完整性非常重要。 首先,我需要回忆Docker的相关知识。Docker镜像的完整性通常可以通过验证镜像的摘要(digest)来确保。每个镜像在推送到支持摘要的仓库时,都会生成一个唯一的哈希值。拉取镜像时,如果使用digest,就能确保获取的是特定版本的镜像,即使标签被更新,digest也不会变。 不过,用户提到的是私有仓库,地址是10.8.3.219,可能是一个本地或内部搭建的Registry。这时候需要考虑这个私有仓库是否配置了HTTPS,因为默认情况下,Docker要求使用HTTPS与仓库通信,除非特别设置了不安全注册表。如果用户遇到证书问题,可能需要先配置Docker信任该仓库的证书。 接下来,步骤应该是先拉取镜像,然后检查其digest。用户已经给出了pull命令,但可能需要先登录到私有仓库。所以第一步是docker login 10.8.3.219,输入凭证。之后执行docker pull,但为了获取digest,可能需要先拉取镜像,或者使用docker manifest inspect命令,但私有仓库可能不支持manifest命令,特别是v2版本。可能需要启用实验性功能。 另外,用户可能没有启用Docker的实验性功能,所以需要指导他们如何开启,比如在docker配置文件中设置experimental为enabled。然后使用docker manifest inspect来查看镜像的digest。但这个方法可能比较复杂,或者仓库不支持的话,可能需要其他方式。 另一种方法是拉取镜像后,使用docker images --digests来查看本地镜像的digest。但这样需要确保本地镜像的digest与仓库中的一致。这时候可能需要通过仓库的API来获取digest信息,比如访问/v2/<repo>/manifests/<tag>的接口,并带上合适的认证头,获取镜像的digest,然后与本地的对比。 此外,镜像签名也是验证完整性的一种方式,比如使用Docker Content Trust(DCT),但需要私有仓库支持Notary服务。如果私有仓库没有配置Notary,这种方法可能不可行,所以可能需要考虑其他方法。 总结下来,步骤大致分为: 1. 确保能够访问私有仓库,处理登录和证书问题。 2. 拉取镜像,获取digest。 3. 对比本地和仓库中的digest是否一致。 4. 或者使用镜像签名(如果支持)。 需要详细说明每一步的具体操作,比如如何配置不安全的注册表,如何启用实验性功能,如何通过API获取digest等。同时,要提醒用户如果私有仓库不支持某些功能(如manifest或DCT),可能需要其他方法,比如手动记录digest或在构建时生成校验和。 另外,用户可能对Docker命令不太熟悉,需要给出具体的命令示例,比如docker pull、docker images --digests、使用curl访问API等。还需要注意权限问题,比如访问API可能需要认证,如何获取token等。 最后,确保回答结构清晰,分步骤说明,并指出可能的注意事项,比如仓库是否支持HTTPS,是否需要配置Docker守护进程等。可能还需要提到如果digest不一致时的处理方法,比如重新拉取或联系管理员检查仓库状态。</think>检查私有仓库中Docker镜像完整性的步骤如下,分阶段执行以确保可靠性: --- ### **1. 配置Docker信任私有仓库(如未配置)** - **问题背景**:若仓库使用HTTP而非HTTPS,需在Docker配置中标记为安全。 - **操作步骤**: 1. 编辑Docker配置文件: ```bash sudo vi /etc/docker/daemon.json ``` 2. 添加仓库地址到`insecure-registries`: ```json { "insecure-registries": ["10.8.3.219"] } ``` 3. 重启Docker服务: ```bash sudo systemctl restart docker ``` --- ### **2. 拉取镜像并验证基础信息** - **操作命令**: ```bash docker pull 10.8.3.219/crm/crm-web:master ``` - **验证拉取结果**: ```bash docker images --digests | grep '10.8.3.219/crm/crm-web' ``` - 输出示例: ``` REPOSITORY TAG DIGEST SIZE 10.8.3.219/crm/crm-web master sha256:5d9c6a6c8e7d... 1.2GB ``` --- ### **3. 通过仓库API获取原始Digest** - **步骤说明**:通过Registry API直接查询仓库中镜像的原始摘要。 1. 获取仓库认证Token: ```bash TOKEN=$(curl -u <用户名>:<密码> "http://10.8.3.219/v2/token?service=registry.docker.io&scope=repository:crm/crm-web:pull" | jq -r '.token') ``` 2. 查询镜像Manifest及Digest: ```bash curl -H "Authorization: Bearer $TOKEN" -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \ http://10.8.3.219/v2/crm/crm-web/manifests/master | jq ``` - **关键输出**:记录`config.digest`和`layers`的哈希值。 --- ### **4. 对比本地与仓库Digest** - **对比方法**: - 本地镜像Digest(通过`docker images --digests`获取) - 仓库原始Digest(通过API获取的`config.digest`) - **结果判断**: - 若两者一致 → 镜像未被篡改 - 若不一致 → 镜像可能被修改或传输损坏 --- ### **5. 高级验证(可选)** #### **5.1 镜像签名验证** - 要求仓库启用Docker Content Trust (DCT): ```bash export DOCKER_CONTENT_TRUST=1 docker pull 10.8.3.219/crm/crm-web:master ``` - 若报错`no trust data available`,说明仓库未启用签名。 #### **5.2 本地镜像哈希计算** - 导出镜像并计算哈希: ```bash docker save 10.8.3.219/crm/crm-web:master -o crm-web.tar sha256sum crm-web.tar ``` - 与仓库记录的原始哈希对比。 --- ### **故障排查** - **常见问题1**:`Error response from daemon: Get "https://10.8.3.219/v2/": http: server gave HTTP response to HTTPS client` - 原因:未正确配置`insecure-registries` - 解决:复查`daemon.json`并重启Docker - **常见问题2**:`manifest unknown`或`unauthorized` - 原因:镜像标签不存在或认证失败 - 解决:检查标签名称或重新`docker login` --- ### **结论** 通过对比本地镜像的`Digest`与仓库API返回的原始哈希值,可确保镜像完整性。若需更高安全性,建议为私有仓库配置HTTPS证书及镜像签名机制。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值