从 dockershim 迁移到 containerd - Amazon EKS
测试迁移

帮助改进此页面

想为本用户指南做出贡献？ 滚动到页面底部，然后选择在 GitHub 上编辑此页面。您的贡献有助于我们的用户指南为每个人提供更充分的参考。

从 dockershim 迁移到 containerd

Kubernetes 不再支持 dockershim。Kubernetes 团队移除了 Kubernetes 版本 1.24 中的运行时。有关更多信息，请参阅《Kubernetes 博客》上的 Kubernetes is Moving on From Dockershim: Commitments and Next Steps。

Amazon EKS 还将从 Kubernetes 版本 1.24 发布起，结束对 dockershim 的支持。从 1.24 版开始，正式发布的 Amazon EKS AMI 将 containerd 作为唯一运行时。此主题涵盖了一些细节，有关更多信息请参见 迁移到 Amazon EKS 上的 containerd 详解。

您可以使用 kubectl 插件查看您的哪些 Kubernetes 工作负载挂载了 Docker 套接字卷。有关更多信息，请参阅 GitHub 上的 Detector for Docker Socket (DDS)。如果 Amazon EKS AMI 运行的 Kubernetes 版本早于 1.24，则使用 Docker 作为默认运行时。但是，这些 Amazon EKS AMI 有一个引导标志选项，您可以使用该选项在任何受支持的集群上通过 containerd 测试工作负载。有关更多信息，请参阅 测试将 Amazon Linux 2 从 Docker 迁移到 containerd。

我们将继续在现有 Kubernetes 版本上发布 AMI，直到支持日期结束。有关更多信息，请参阅 Amazon EKS Kubernetes 发布日历。如果需要更多时间在 containerd 上测试工作负载，请使用 1.24 版之前的支持版本。但是，当您想将官方 Amazon EKS AMI 升级到版本 1.24 或更高版本时，请确保验证您的工作负载可以在 containerd 上运行。

containerd 运行时提供更可靠的性能和安全性。containerd 是整个 Amazon EKS 标准化的运行时。Fargate 和 Bottlerocket 已经只能使用 containerd。containerd 有助于最大程度地减少 dockershim 常见漏洞和风险（CVE）所需的 Amazon EKS AMI 发布次数。由于 dockershim 已经在内部使用 containerd，您可能无需进行任何更改。但是，在某些情况下可能需要或必须要进行更改：

  • 您必须对挂载 Docker 套接字的应用程序进行更改。例如，使用容器构建的容器映像将受到影响。许多监控工具也挂载了 Docker 套接字。您可能需要等待更新或重新部署工作负载才能进行运行时监控。

  • 您可能需要对依赖特定 Docker 设置的应用程序进行更改。例如，不再支持 HTTPS_PROXY 协议。您必须更新使用此协议的应用程序。有关更多信息，请参阅 Docker 文档中的 dockerd。

  • 如果您使用 Amazon ECR 凭证助手提取映像，则必须切换到 kubelet 映像凭证提供程序。有关更多信息，请参阅 Kubernetes 文档中的配置 kubelet 映像凭证提供程序。

  • 由于 Amazon EKS 1.24 不再支持 Docker，因此不再支持 Amazon EKS 引导脚本 以前支持的某些标志。在迁移到 Amazon EKS 1.24 或更高版本之前，您必须删除任何引用现在不支持的标志的内容：

    • --container-runtime dockerd（containerd 是唯一受支持的值）

    • --enable-docker-bridge

    • --docker-config-json

  • 如果您已经为 Container Insights 进行了 Fluentd 配置，则必须先将 Fluentd 迁移到 Fluent Bit，然后才能更改为 containerd。Fluentd 解析器配置为仅解析 JSON 格式的日志消息。与 dockerd 不同的是，containerd 容器运行时系统的日志消息不是 JSON 格式的。如果您不迁移到 Fluent Bit，一些配置的 Fluentd's 解析器将在 Fluentd 容器内生成大量错误。有关迁移的更多信息，请参阅将 Fluent Bit 设置为 DaemonSet 以将日志发送到 CloudWatch Logs。

  • 如果您使用自定义 AMI 并且要升级到 Amazon EKS 1.24，则必须确保为您的  Worker 节点启用 IP 转发。Docker 不需要此设置，但 containerd 需要。需要对 Pod 到 Pod、Pod 到外部或 Pod 到 apiserver 的网络连接进行故障排除。

    要在 Worker 节点上验证此设置，请运行以下任一命令：

    • sysctl net.ipv4.ip_forward

    • cat /proc/sys/net/ipv4/ip_forward

    如果输出为 0，则运行以下任一命令来激活 net.ipv4.ip_forward 内核变量：

    • sysctl -w net.ipv4.ip_forward=1

    • echo 1 > /proc/sys/net/ipv4/ip_forward

    有关在 containerd 运行时系统中的 Amazon EKS AMI 上激活该设置的情况，请参阅 GitHub 上的 install-worker.sh。

测试将 Amazon Linux 2 从 Docker 迁移到 containerd

对于 Kubernetes 版本 1.23，您可以使用可选的引导标志，为 Amazon EKS 优化版 AL2 AMI 启用 containerd 运行时系统。在更新到版本 1.24 或更高版本时，该功能提供迁移到 containerd 的清晰路径。Amazon EKS 将从 Kubernetes 版本 1.24 发布起，结束对 Docker 的支持。已在 Kubernetes 社群中广泛采用 containerd 运行时，是 CNCF 的一个分级项目。您可以通过将节点组添加到新集群或现有集群来对其进行测试。

您可以通过创建以下类型的节点组之一来启用引导标记。

自行管理

按照 创建自行管理的 Amazon Linux 节点 中的说明创建节点组。为 BootstrapArguments 参数指定 Amazon EKS 优化版 AMI 和以下文本。

--container-runtime containerd
托管式

如果使用 eksctl，请创建一个名为 my-nodegroup.yaml 的文件，其中包含以下内容。请将每个 example value 替换为您自己的值。节点组名称的长度不能超过 63 个字符。它必须以字母或数字开头，但也可以包括其余字符的连字符和下划线。要检索 ami-1234567890abcdef0 的优化版 AMI ID，请参阅 检索建议的 Amazon Linux AMI ID。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
注意

如果同时启动多个节点，您还可以为 --apiserver-endpoint、--b64-cluster-ca 和 --dns-cluster-ip 引导参数指定值以避免错误。有关更多信息，请参阅 指定 AMI。

运行以下命令以创建节点组。

eksctl create nodegroup -f my-nodegroup.yaml

如果您希望使用其他工具来创建托管节点组，则必须使用启动模板部署节点组。在启动模板中，指定 Amazon EKS 优化版 AMI ID，然后使用启动模板部署节点组，并提供以下用户数据。此用户数据会将实际参数传递到 bootstrap.sh 文件中。有关引导文件的更多信息，请参阅 GitHub 上的 bootstrap.sh。

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd