Amazon EKS は Dockershim のサポートを終了しました

Kubernetes では Dockershim サポートは終了しています。Kubernetes チームは Kubernetes バージョン 1.24 でランタイムを削除しました。詳細については、Kubernetes ブログの「Kubernetes は Dockershim から移行しています: コミットメントと次のステップ」を参照してください。

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 を使用してサポートされているクラスターでワークロードをテストに使用できるブートストラップフラグオプションがあります。詳細については、「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」を参照してください。