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 に移行するにあたり知っておくべきこと」を参照してください。

Docker ソケットボリュームをマウントする Kubernetes ワークロードを表示するために使用できる kubectl プラグインがあります。詳細については、GitHub の「Docker ソケット (DDS) の検出器」を参照してください。1.24 より前のバージョンの Kubernetes を実行する Amazon EKS AMI は、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 Docs」の「dockerd」を参照してください。

  • Amazon ECR 認証情報ヘルパーを使用してイメージをプルする場合は、kubelet イメージ認証情報プロバイダーへの切り替えが必要です。詳細については、「Kubernetes ドキュメント」の「kubelet イメージ認証情報プロバイダーを設定する」を参照してください。

  • Amazon EKS 1.24 は Docker をサポートしなくなったため、「Amazon EKS bootstrap script」(Amazon EKS ブートストラップスクリプト) が以前サポートしていた一部のフラグはサポートされなくなりました。Amazon EKS 1.24 以降に移行する前に、現在サポートされていないフラグへの参照をすべて削除する必要があります。

    • --container-runtime dockerd (containerd はサポートされる唯一の値です)

    • --enable-docker-bridge

    • --docker-config-json

  • Fluentd がすでに Container Insights 用に構成されている場合、containerd に変更する前に Fluentd を Fluent Bit に移行する必要があります。Fluentd パーサーは JSON 形式のログメッセージのみを解析するように構成されています。dockerd とは異なり、containerd コンテナランタイムには JSON 形式ではないログメッセージがあります。Fluent Bit に移行しないと、構成された Fluentd's パーサーの一部が Fluentd コンテナー内で大量のエラーを生成します。移行の詳細については、「CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する」を参照してください。

  • カスタム AMI を使用して Amazon EKS 1.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 ランタイムの 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 のサポートを終了しました。containerd ランタイムは Kubernetes コミュニティで広く導入されていて、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