從移轉dockershim到 containerd - Amazon EKS
測試遷移

協助改善此頁面

想要為此使用者指南做出貢獻？ 捲動至此頁面底部，然後在 上選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合所有人。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

從移轉dockershim到 containerd

Kubernetes 不再支援 dockershim。Kubernetes 團隊已移除 Kubernetes 1.24 版中的執行階段。如需詳細資訊，請參閱KubernetesKubernetes部落格上的「承諾與後續步驟」。Dockershim

Amazon EKS 還結束了對Kubernetes版本1.24發布dockershim開始的支持。正式發布的 Amazon containerd 作為唯EKSAMIs一以版本開始的運行時間1.24。本主題涵蓋了一些詳細信息，但有關在 Amazon 上移至 containerd 的所有信息，請參閱所有您需要了解的信息。EKS

您可以使用 kubectl 外掛程式來查看哪些 Kubernetes 工作負載已掛載 Docker 通訊端磁碟區。如需詳細資訊，請參閱開啟的 Docker Socket (DDS) 偵測器GitHub。Amazon 運行EKSAMIs的Kubernetes版本比1.24用Docker作默認運行時更早的版本。但是，這些 Amazon EKS AMIs 具有啟動程序旗標選項，您可以使用它來測試任何受支援叢集上的工作負載containerd。如需詳細資訊，請參閱測試 Amazon Linux 2 從遷移Docker到 containerd。

我們將繼續AMIs針對現有Kubernetes版本發佈，直到支援日期結束為止。如需詳細資訊，請參閱Amazon EKS Kubernetes 發行行事曆。若您需要更多時間在 containerd 上測試工作負載，則可繼續使用 1.24 之前的支援版本。但是，當您要將官方 Amazon 升級EKSAMIs到版本1.24或更高版本時，請確保驗證您的工作負載是否在上運行containerd。

containerd執行階段提供更可靠的效能和安全性。 containerd是橫跨 Amazon 正在標準化的運行時EKS。Fargate 和Bottlerocket已經containerd只使用。 containerd有助於將解決dockershim常見漏洞和暴露所需的 Amazon EKS AMI 版本數量減至最少 (CVEs)。由於 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與containerd容器執行階段不同的是dockerd，具有不是JSON格式的記錄訊息。如果您未遷移到 Fluent Bit，則某些已設定的 Fluentd's 剖析器將在 Fluentd 容器內生成大量錯誤。如需有關移轉的詳細資訊，請參閱設定Fluent Bit為將記錄檔傳送 DaemonSet 至 CloudWatch 記錄檔。

  • 如果您使用自訂AMI且要升級至 Amazon EKS1.24，則必須確定已為工作者節點啟用 IP 轉送。Docker 不需要此設定，但對 containerd 而言，這是必要設定。需針對 Pod 對 Pod、Pod 對外部或 Pod 對 apiserver 網路連線進行疑難排解。

    若要在工作節點上驗證此設定，請執行下列其中一個命令：

    • 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運行時EKSAMIs在 Amazon 上激活該設置的信息，請參閱install-worker.sh（詳見）GitHub。

測試 Amazon Linux 2 從遷移Docker到 containerd

對於Kubernetes版本1.23，您可以使用可選的啟動程序標誌來啟用 Amazon EKS 優化的containerd執行階段AL2AMIs。此功能為您在更新至 1.24 版或更新版本時遷移至 containerd 的操作提供清晰的路徑。Amazon EKS 結束了對Kubernetes版本1.24啟動Docker開始的支持。containerd執行階段在Kubernetes社群中得到廣泛採用，而且是CNCF. 您可以將節點群組新增至新叢集或現有叢集來進行測試。

您可以建立下列其中一種節點群組類型，以啟用引導旗標。

自我管理

使用 建立自我管理的 Amazon Linux 節點 中的指示建立節點群組。為BootstrapArguments參數指定 Amazon EKS 最佳化AMI和下列文字。

--container-runtime containerd
受管

如果您使用 eksctl，請建立名為 my-nodegroup.yaml 的檔案並包含下列內容。使用您自己的值取代每一個 ‭example value‬。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。若要擷取的最佳化 AMI IDami-1234567890abcdef0，請參閱擷取建議的 Amazon Linux AMI IDs。

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