K8s集群中containerd配置HTTP私服（Harbor）完整指南：从配置文件修改到镜像拉取

在Kubernetes集群中为containerd配置HTTP私有镜像仓库：一份面向生产环境的深度实践指南

如果你正在管理一个基于Kubernetes的生产环境，并且已经完成了从Docker到containerd的运行时迁移，那么配置私有镜像仓库很可能是你接下来要面对的关键任务之一。尤其是在企业内部，出于安全、网络隔离和镜像管理效率的考虑，搭建像Harbor这样的私有仓库几乎是标准操作。然而，当你的私有仓库暂时只支持HTTP协议（这在某些内部测试或隔离环境中很常见），而containerd默认却只“信任”HTTPS时，问题就来了——你会发现那些精心构建的镜像死活拉不下来，Pod卡在ImagePullBackOff的状态，日志里满是令人困惑的TLS握手错误。

这篇文章就是为你准备的。我们将彻底绕开那些浅尝辄止的教程，深入containerd的配置核心，不仅告诉你如何修改一个配置文件，更会剖析其背后的工作原理，解释crictl和ctr这两个关键工具的行为差异，并提供一套从诊断、配置到验证的完整操作流程。无论你是负责集群稳定的运维工程师，还是需要频繁部署应用的开发者，掌握这些内容都将让你在应对镜像仓库相关问题时更加游刃有余。

1. 理解核心：为什么containerd对HTTP“说不”？

在直接动手修改配置文件之前，花几分钟理解背后的原理至关重要。这能帮助你在遇到问题时，不再盲目尝试，而是能够精准定位。

简单来说，安全性是这一切的起点。互联网上的公共镜像仓库（如Docker Hub）早已全面转向HTTPS，通过TLS/SSL加密来确保镜像在传输过程中不被篡改，并验证服务器的身份。因此，现代容器运行时默认将HTTPS视为标准协议。当你提供一个使用http://开头的镜像地址时，containerd的CRI（容器运行时接口）插件会认为这是一个不安全的连接，并出于安全考虑拒绝操作。

然而，在企业内网环境中，情况有所不同：

• 简化部署：在完全可控的内网，有时会先部署一个纯HTTP的仓库用于快速验证流程，尤其是像Harbor这类复杂系统，配置HTTPS涉及证书颁发和管理，是一个相对独立的步骤。
• 开发与测试：在开发或测试集群中，团队可能更关注功能迭代速度，而非传输层安全。
• 历史遗留系统：一些旧的私有仓库系统可能尚未升级支持HTTPS。

关键点在于：containerd并非不能使用HTTP，而是需要你显式地告知它：“我明白风险，并且我信任这个特定的地址”。这个“告知”的过程，就是通过修改config.toml文件来完成的。

注意：在生产环境最终落地时，强烈建议为私有仓库配置有效的HTTPS证书（可以是内部CA签发的）。长期使用HTTP会引入中间人攻击的风险，可能导致镜像被恶意替换。

2. 实战配置：一步步修改containerd的config.toml

我们的操作将集中在Kubernetes集群的**各个工作节点（Worker Node）**上。因为每个节点上的containerd都需要知道如何访问你的私有仓库。假设你的Harbor私有仓库地址是 http://my-harbor.example.com:8080，仓库中有一个项目叫 myapp，里面存放着镜像 backend:v1.0。

2.1 定位与备份配置文件

首先，通过SSH登录到目标工作节点。containerd的主配置文件通常位于 /etc/containerd/config.toml。如果该文件不存在（例如在一些使用默认配置的系统中），你可以通过命令生成一个：

sudo containerd config default | sudo tee /etc/containerd/config.toml

在进行任何修改前，务必备份！ 这是一个好习惯。

sudo cp /etc/containerd/config.toml /etc/containerd/config.toml.bak.$(date +%Y%m%d)

2.2 编辑配置文件，添加私有仓