dockershim
から containerd
に移行する
Kubernetes では dockershim
サポートは終了しています。Kubernetes チームは Kubernetes バージョン 1.24
でランタイムを削除しました。詳細については、「[.noloc]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 で「Detector for Docker Socket (DDS)1.24
より前のバージョンの Kubernetes を実行する Amazon EKS AMI は、Docker をデフォルトのランタイムとして使用します。ただし、これらの Amazon EKS AMI には、containerd
を使用してサポートされているクラスターでワークロードをテストに使用できるブートストラップフラグオプションがあります。詳細については、「containerd-bootstrap.title」を参照してください。
既存の Kubernetes バージョン向け AMI の公開は、そのサポート終了日まで継続します。詳細については、「Amazon EKS Kubernetes リリースカレンダー」を参照してください。containerd
でのワークロードのテストにさらに時間が必要な場合は、1.24
より前のサポートされているバージョンをご利用いただけます。しかし、公式の Amazon EKS AMI をそのバージョン 1.24
以降にアップグレードする場合は、ワークロードが containerd
で実行可能なことを検証するようにしてください。
containerd
ランタイムは、より信頼性の高いパフォーマンスとセキュリティを提供します。containerd
は Amazon EKS 全体で標準化されているランタイムです。Fargate と Bottlerocket はすでに containerd
のみを使用しています。containerd
は、dockershim
一般的な脆弱性と露出dockershim
は内部では containerd
を既に使用しているため、変更を加える必要がない場合があります。ただし、次のように変更が必要な状況があります。これには、変更が必要な可能性がある状況も含まれます。
-
Docker ソケットをマウントしているアプリケーションを変更する必要があります。例えば、コンテナで構築されたコンテナイメージが影響を受けます。多くのモニタリングツールも、Docker ソケットをマウントしています。ランタイムのモニタリング用のワークロードについては、その更新を待つか、再デプロイする必要がある場合があります。
-
特定の Docker 設定に依存するアプリケーションでは、場合により変更が必要です。例えば、
HTTPS_PROXY
プロトコルのサポートが終了しているなどです。このプロトコルを使用するアプリケーションを更新する必要があります。詳細については、「[.noloc]Docker
のドキュメント」の「dockerd」を参照してください。 -
Amazon ECR 認証情報ヘルパーを使用してイメージをプルする場合は、
kubelet
イメージ認証情報プロバイダーへの切り替えが必要です。詳細については、Kubernetes ドキュメントの「Configure a kubelet image credential provider」(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
という名前のファイルを作成します。各サンプル値
は独自の値に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。ami-
の最適化された AMI ID を取得するには、「推奨 Amazon Linux AMI ID を取得する」を参照してください。1234567890abcdef0
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