关于 Docker 节点映像弃用

本页面介绍 containerd 容器运行时、Google Kubernetes Engine (GKE) 中 Docker 的支持，以及必须迁移到使用 containerd 的节点映像的原因。如需了解如何迁移到 containerd 节点映像，请参阅从 Docker 迁移到 containerd 节点映像。

概览

Kubernetes 节点使用容器运行时启动、管理和停止 Pod 中运行的容器。Kubernetes 项目将移除对 Kubernetes 1.24 及更高版本中 Docker 运行时的内置支持。为此，Kubernetes 移除了名为 dockershim 的组件，该组件可让 Docker 与 kubelet 等 Kubernetes 组件进行通信。

Containerd 是新的默认运行时，它是 Kubernetes 支持的行业标准容器运行时，许多其他项目都在使用。containerd 运行时提供了分层抽象，可实现 gVisor 和映像流式传输等一组丰富的特征来扩展 GKE 功能。与 Docker 运行时相比，该运行时被认为更省资源且更安全。

由于此更改，GKE 不支持在 GKE 1.24 版及更高版本中使用 Docker 作为运行时的节点映像。如果集群的任何节点池使用基于 Docker 的节点映像，或将节点自动预配与基于 Docker 的默认节点映像类型搭配使用，那么集群会受到影响。

在 2023 年 7 月 31 日（GKE 1.23 版服务终止日期）之前，GKE 会暂停自动升级，并阻止手动升级升级到 1.24 版。如需在此日期之前将集群的控制平面升级到 GKE 1.24 版及更高版本，您必须将节点自动预配配置以及所有节点更新为 containerd 运行时。如需升级节点池，您必须迁移到使用 containerd 运行时的节点映像。

在 1.23 版达到服务终止期限后，对于尚未完成迁移的集群，GKE 会取消阻止控制平面手动升级到 1.24 版，并开始逐步升级集群，以实现安全性和兼容性。如需详细了解 GKE 如何将集群升级到 1.24 版，以及从 Docker 节点映像迁移集群时建议您执行的操作，请参阅 1.23 版达到服务终止期限后的自动迁移。

Docker 和 containerd 节点映像

从 1.19 版（在 Linux 上）和 1.21 版（在 Windows 上）开始，Containerd 一直是所有新 GKE 节点的默认运行时。但是，GKE Standard 集群还会继续支持使用 Docker 作为运行时的节点映像。下表介绍了 GKE 1.24 版及更高版本中不支持的基于 Docker 的节点映像以及 containerd 等效项：

Docker 运行时 containerd 运行时
带有 Docker 的 Container-Optimized OS (cos) 带有 containerd 的 Container-Optimized OS (cos_containerd)
带有 Docker 的 Ubuntu (ubuntu) 带有 containerd 的 Ubuntu (ubuntu_containerd)
带有 Docker 的 Windows Server LTSC (windows_ltsc) 带有 containerd 的 Windows Server LTSC (windows_ltsc_containerd)

带有 Docker 的 Windows Server SAC (windows_sac)

带有 containerd 的 Windows Server SAC (windows_sac_containerd)

时间轴和里程碑

在 GKE 1.23 版中，您无法再执行以下操作：

  • 创建使用基于 Docker 的节点映像的新集群。
  • 将具有基于 Docker 的节点映像的新节点池添加到现有集群中。
  • 通过将 --autoprovisioning-image-type 标志设置为基于 Docker 的节点映像来启用节点自动预配。

如果您要升级到 GKE 1.23 版，则可以使用以下各项继续：

  • 升级前创建的具有基于 Docker 的节点映像的现有节点池。
  • 具有 Docker 节点映像的节点池上的集群自动扩缩器。
  • 升级前启用的节点自动预配功能，并将 --autoprovisioning-image-type 标志设置为基于 Docker 的节点映像。

在 GKE 1.24 版中，您无法再执行以下操作：

  • 如果控制平面运行 1.24 版，当 --autoprovisioning-image-type 标志设置为基于 Docker 的节点映像时，您无法使用节点自动预配功能。
  • 如果节点池运行 1.24 版，则节点无法使用基于 Docker 的节点映像。

下表总结了与即将发布的 GKE 版本交互时预计会发生的变化：

操作 GKE 1.23 版 GKE 1.24 版
使用 Docker 创建新集群 否 否
使用 Docker 创建新节点池 否 否
使用 Docker 启用节点自动预配功能 否 否
使用现有 Docker 节点自动预配配置从先前版本升级 有 否
使用基于 Docker 的节点映像 是 否

1.23 版达到服务终止期限后的自动迁移

如果您在 1.23 版于 2023 年 7 月 31 日达到服务终止前未升级到 1.24 版且未迁移到 containerd 节点映像，GKE 会随时间推移执行以下操作：

  1. 如果您的集群有节点自动预配并使用基于 Docker 的默认节点映像类型，GKE 会更新配置以使用基于 containerd 运行时的等效节点映像。 您无法使用维护排除项来阻止此操作。如需验证这对工作负载没有不利影响，我们建议您在 GKE 自动更新配置之前手动将节点自动预配默认映像类型更新为基于 containerd 的映像。

  2. GKE 将集群的控制平面升级到 1.24 版。

  3. 从 2023 年 9 月 1 日开始，GKE 会将仍在使用 Docker 的所有节点池迁移到 containerd 节点映像。我们建议您在此日期之前手动迁移节点映像。或者，您可以请求 GKE 启动一个操作来迁移集群以使用 containerd 映像。如需发出此请求，请与 Cloud Customer Care 联系。

    如需暂时阻止自动迁移，请将集群升级到 1.24 版或更高版本并配置维护排除项。 如需详细了解此维护排除项，请参阅暂时延迟自动迁移到 containerd 节点映像。

  4. GKE 将 1.23 版（以及任何不受支持的版本）节点池升级到 1.24 版，以确保集群运行状况与开源版本倾斜政策保持一致。如需了解详情，请参阅 GKE 次要版本生命周期。您可以通过维护排除项暂时阻止此升级。

暂时延迟自动迁移到 containerd 节点镜像

集群的控制平面升级到 1.24 版或更高版本后，您可以配置维护排除项以暂时阻止节点迁移，直到 2024 年 2 月 29 日 1.25 版终止服务为止。 您的集群必须在发布渠道中注册，才有资格使用此维护排除项。 使用“无次要版本或节点升级”范围配置维护排除项，并将 --add-maintenance-exclusion-end 标志设置为 2024-02-29T00:00:00Z 或更早版本。我们建议您尽快取消阻止迁移，并允许节点升级到 1.24 版。已终止服务的次要版本不会再收到安全补丁和 bug 修复。

从 Docker 迁移到 containerd 节点映像

请参阅从 Docker 迁移到 containerd 节点映像，以确定使用基于 Docker 的节点映像的集群和节点池，并将这些节点池迁移到 containerd 节点映像。

作为 GKE 共担责任模型的一部分，客户责任包括维护工作负载的健康状况，Google 责任包括确保集群保持正常运行，其中包括运行受支持的版本。我们强烈建议您在 GKE 自动执行之前测试工作负载并迁移集群。

1.23 版服务终止之前，对于具有使用 Docker 节点映像的节点池的集群，GKE 会阻止自动或手动升级到 1.24 版。将集群迁移为仅使用 containerd 映像后，自动升级可在一天内恢复（根据 GKE 发布时间表），或者您也可以手动升级集群。

1.23 版服务终止后，GKE 会恢复到 1.24 版的自动或手动升级，并执行自动迁移过程。

迁移的影响

迁移到 containerd 节点映像时的主要变化是，Docker 不再管理容器的生命周期（例如启动和停止容器）。因此，您无法使用 Docker 命令或 Docker API 查看在使用 containerd 映像的节点上运行的 GKE 容器或与之交互。

大多数用户工作负载都不依赖于容器运行时。Docker 运行时还会实现 containerd，因此您的工作负载在 containerd 节点映像上的行为类似。

如果符合以下情况，您可能会受到影响：

  • 运行具有特权的 Pod 来执行 Docker 命令。
  • 在 Kubernetes 基础架构之外的节点上运行脚本（例如，使用 ssh 排查问题）。
  • 运行第三方工具来执行类似具有特权的操作。
  • 某些工具响应监控系统中特定于 Docker 的日志。
  • 您可以将外部供应商提供的日志记录、监控、安全性或持续集成工具部署到您的 GKE 集群中。请与这些供应商联系来确认影响。

在以下情况下，您不会受到影响：

  • 您在 GKE 集群之外有一个构建流水线，该流水线使用 Docker 构建和推送容器映像。
  • 在 GKE 集群中使用 docker build 和 docker push 命令。具有 containerd 的 Linux 节点映像包含 Docker 二进制文件，并支持这些命令。

使用具有特权的 Pod 访问 Docker

如果您的用户使用具有特权的 Pod 访问节点上的 Docker Engine，则应更新工作负载，以确保不直接依赖于 Docker。例如，考虑将日志记录和监控提取过程从 Docker Engine 迁移到 GKE 系统插件。

使用 containerd 构建容器映像

您不能使用 containerd 来构建容器映像。带有 containerd 的 Linux 映像包含 Docker 二进制文件，以便您可以使用 Docker 构建和推送映像。但是，我们不建议使用单个容器和本地节点运行命令来构建映像。

Kubernetes 无法感知 Kubernetes 范围之外的本地进程使用的系统资源，并且 Kubernetes 控制平面在分配资源时无法解释那些进程。这可能会导致您的工作负载缺乏 GKE 资源，或者导致节点不稳定。

请考虑使用单个容器范围之外的其他服务（例如 Cloud Build）完成这些任务，或者使用 kaniko 等工具将映像构建为 Kubernetes 工作负载。

如果这些建议都不适合您，并且您了解风险，则可以继续使用本地节点上的 Docker 来构建映像。您必须先将映像推送到注册表，然后才能在 GKE 集群中使用这些映像。具有 containerd 的 Kubernetes 无法感知使用 Docker 在本地构建的映像。

在 containerd 节点上调试容器

对于 Linux 节点上的调试或问题排查，您可以使用为 Kubernetes 容器运行时构建的可移植命令行工具 crictl 与 containerd 进行交互。crictl 支持查看容器和映像、读取日志以及在容器中执行命令的常用功能。如需了解整套受支持的功能和使用信息，请参阅 crictl 用户指南。

对于 Windows Server 节点，containerd 守护程序作为名为 containerd 的 Windows 服务运行。

可用的日志如下所示：

  • Windows：C:\etc\kubernetes\logs\containerd.log
  • Linux：运行 journalctl -u containerd

您还可以在日志浏览器中的 LOG NAME: "container-runtime" 下查看 Windows 和 Linux 节点的日志。

问题排查

如需进行问题排查，请转到排查 containerd 运行时的问题。

后续步骤