containerd イメージ

このページでは、Containerd(cos_containerd)が含まれている Container-Optimized OSContainerd(ubuntu_containerd)が含まれている Ubuntu を Google Kubernetes Engine(GKE)ノード上で使用するための追加情報を説明します。cos_containerd および ubuntu_containerd イメージを使用すると、GKE クラスタで Containerd をコンテナ ランタイムとして使用できます。

Containerd について

コンテナ ランタイムは、コンテナの実行や、Kubernetes のコンテナ管理の抽象化を行うソフトウェアです。コンテナにはいくつかのランタイムがあります。Containerd は業界標準のコンテナ ランタイムで、Kubernetes によってサポートされ、他の多くのプロジェクトで使用されています。Containerd は、Kubernetes 機能を拡張する gVisor のような豊富な機能を実装するためのレイヤの抽象化を提供します。Containerd は、Docker ランタイムと比較して、より効率的で安全なリソースとみなされます。

GKE クラスタでの Containerd イメージの使用

新しい GKE クラスタの作成、既存クラスタでの新しいノードプールの作成、または既存のクラスタのアップグレードを行うときに、cos_containerd または ubuntu_containerd をイメージタイプとして選択できます。どちらも Containerd イメージには GKE バージョン 1.14.3 以降が必要です。

ノードイメージの種類を確認する

既存のノードに使用されているイメージタイプを確認するには、Google Cloud Console、gcloud ツールまたは kubectl を使用します。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine ページに移動

  2. クラスタリストで、確認するクラスタの名前をクリックします。

  3. [ノード] タブを選択します。

  4. [ノードプール] セクションで、[イメージの種類] 列の値を確認します。

gcloud

次のコマンドを実行します。NODEPOOL_NAME はノードプールの名前に置き換えてください。sh gcloud container node-pools list --cluster CLUSTER_NAME --format="table(name,version,config.imageType)"

出力は次のようになります。

NAME          NODE_VERSION    IMAGE_TYPE
default-pool  1.19.6-gke.600  UBUNTU_CONTAINERD

詳細については、gcloud container node-pools list API ドキュメントをご覧ください。

kubectl

kubectl get nodes コマンドを次のように使用します。

kubectl get nodes -o wide

出力は次のようになります。

# For Docker runtime
NAME         STATUS   VERSION             OS-IMAGE                             CONTAINER-RUNTIME
gke-node-1   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
gke-node-2   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
gke-node-3   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
# For Containerd runtime
NAME         STATUS   VERSION           OS-IMAGE                             CONTAINER-RUNTIME
gke-node-1   Ready    v1.19.6-gke.600   Container-Optimized OS from Google   containerd://1.4.1
gke-node-2   Ready    v1.19.6-gke.600   Container-Optimized OS from Google   containerd://1.4.1
gke-node-3   Ready    v1.19.6-gke.600   Container-Optimized OS from Google   containerd://1.4.1

CONTAINER-RUNTIME がランタイムとそのバージョンを出力します。

Docker ランタイムから Containerd ランタイムへの移行

ほとんどのユーザー ワークロードは、コンテナ ランタイムに依存しません。コンテナ ランタイムはポッド内でコンテナを実行するものであり、Docker ランタイムは実際には内部で Containerd を使用するため、どちらのランタイムも同じように動作します。

デベロッパー マシンで Docker を使用する場合や、クラスタ外部で実行され、イメージのビルドと push を行うビルド パイプラインの一部として Docker を使用する場合も、それ自体は Docker ランタイムに依存しません(これらのアクションはクラスタの外部で発生するため)。

Docker に対して依存関係がある場合には、いくつかのケースが考えられます。たとえば、Docker コマンドを実行する特権 Pod の実行、Kubernetes インフラストラクチャ外のノードでのスクリプトの実行(ssh を使用した問題のトラブルシューティングなど)、同様の権限が付与されているサードパーティ製ツールの使用などです。また、モニタリング ツール内の Docker 固有のログメッセージに応答するように一部のツールが構成されている場合、Docker に間接的な依存関係が存在することがあります。

Docker ランタイムに存在する可能性のある依存関係については、dockershim からの移行をご覧ください。Containerd との互換性を確認するには、クラスタにデプロイするロギングとモニタリング、セキュリティ、継続的インテグレーションツールを提供しているベンダーに相談することもできます。

まず、Containerd を使用してテストノードプールにワークロードをデプロイし、すべてが想定どおりに実行されることを確認することをおすすめします。カナリア クラスタまたはステージング クラスタがある場合は、最初に移行することをおすすめします。異なるマシンタイプへのワークロードの移行に記載されているアプローチを使用して、ノードを段階的に移行することもできます。

ノードイメージの更新

ノードプールを更新して別のイメージを設定することで、Docker ランタイム イメージから Containerd イメージにノードを移行できます。この移行は、Google Cloud Console または gcloud ツールを使用して行うことが可能です。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. クラスタの横の [ アクション] をクリックし、[編集] をクリックします。

  3. [ノードプール] セクションで、目的のノードプールを選択します。

  4. [ノードプールの詳細] ページで、[編集] をクリックします。

  5. [イメージの種類] セクションで [変更] をクリックします。

  6. オペレーティング システム用の Containerd イメージ バリアントの 1 つを選択します。

  7. [変更] をクリックします。

  8. ノードがアップグレードされるのを待ちます。

gcloud

gcloud ツールでノードプールを更新するには、gcloud container clusters upgrade コマンドを使用して --image-type パラメータを指定します。

たとえば、Containerd を使用してノードプールのイメージを Container-Optimized OS に変更するには、次のコマンドを実行します。

gcloud container clusters upgrade CLUSTER_NAME --image-type COS_CONTAINERD \
    --node-pool POOL_NAME

ノードイメージを更新した後で問題があり、Docker イメージ バリアントに戻す必要がある場合は、同じコマンドを使用して、Docker イメージ バリアントを選択します。

詳細については、gcloud container clusters upgrade API ドキュメントをご覧ください。

Containerd ノードで Docker コマンドを実行する

Docker バイナリは現在 Containerd ノードで使用できますが、Containerd への移行後には使用しないことをおすすめします。Docker では、Kubernetes が Containerd ノードで実行するコンテナを管理しません。このため、Docker コマンドや Docker API を使用して、実行中の Kubernetes コンテナの表示や操作を行うことはできません。

Containerd ノードのコンテナで発生した問題のトラブルシューティング

ノードでのデバッグやトラブルシューティングのため、Kubernetes コンテナ ランタイム用にビルドされたポータブル コマンドライン ツール crictl を使用して、Containerd とやりとりできます。crictl は、コンテナやイメージの表示、ログの読み取り、コンテナでのコマンドの実行などの一般的な機能をサポートします。サポートされている全機能と使用方法については、crictl ユーザーガイドをご覧ください。

権限のあるポッドから Docker Engine にアクセスする

現在、権限のある Pod 内からノード上の Docker Engine にアクセスしているユーザーが一部存在します。そのため、ユーザーが Docker に直接依存することがないようにお客様のワークロードを更新することをおすすめします。たとえば、現在 Docker Engine からアプリケーション ログやモニタリング データを抽出している場合は、代わりに GKE システムのアドオンを利用してロギングやモニタリングを行うことをご検討ください。

イメージをビルドする

Containerd はイメージのビルドをサポートしていません。Kubernetes 自体がこの機能に対応していないためです。

Kubernetes は自身のスコープ外のローカル プロセスで使用されるシステム リソースを認識しないので、Kubernetes コントロール プレーンはリソースを割り当てる際にそれらのプロセスを考慮することができません。その結果、リソース関係の GKE ワークロードが枯渇する可能性があります。また、ノードが不安定になる可能性もあります。こうした理由から、ローカルノード上でコマンドを実行することはおすすめしません。このようなタスクを実施する場合は、個々のコンテナのスコープ外でその他のサービス(Cloud Build など)を利用するか kaniko などのツールを使用して Kubernetes ワークロードの形でイメージをビルドすることをご検討ください。

これらの推奨事項を採用できない場合は、このリスクをご理解のうえ、Docker によるイメージのビルドを進めてください。GKE クラスタでイメージを使用する場合は、その前にイメージをレジストリに push する必要があります。Kubernetes はローカルでビルドされたイメージを認識しないからです。

既知の問題

172.17/16 との競合

影響を受ける GKE のバージョン: 1.14、1.15、1.16、1.17、1.18.0 ~ 1.18.14、1.19.0 ~ 1.19.6-gke.1100

172.17/16 の IP 範囲は、Containerd が有効なノード VM の docker0 インターフェースが占有します。その範囲から送受信されたトラフィックは正しくルーティングされない可能性があります(たとえば、172.17/16 内の IP を持つ VPN 接続ホストには、ポッドが接続できない可能性があります)。

Containerd ノードで Docker デーモンが停止している

影響を受ける GKE のバージョン: 1.19.0 ~ 1.19.6

影響を受ける GKE バージョンを実行しているクラスタの場合、Containerd(cos_containerd)が含まれている Container-Optimized OSノードイメージの dockerd(Docker Daemon)は起動時に実行されません。手動で開始する必要があります。詳細については、リリースノートをご覧ください。

56 個を超えるレイヤがある画像は Containerd では使用できない

影響を受ける GKE のバージョン: 1.14、1.15、1.16、1.17

画像のレイヤが 56 個を超える場合、画像をダウンロードできません。次のエラーが発生します。

info.Labels: label key and value greater than maximum size (4096 bytes), key: containerd: invalid argument

詳細については、https://github.com/containerd/containerd/issues/4684 をご覧ください。

この問題は Containerd 1.4.2 で修正されています。Container-Optimized OS 85 にはこの修正が含まれています

GPU 指標が収集されない

影響を受ける GKE のバージョン: 1.14、1.15、1.16、1.17、1.18、1.19.0 ~ 1.19.4

1.19 より前の GKE バージョンでランタイムとして containerd を使用している場合、GPU 使用状況の指標は収集されません。

画像指標にラベルがない

影響を受ける GKE のバージョン: すべて

画像指標 container_fs_usage_bytescontainer_tasks_state には、imagecontainer_name、名前 namespace などのラベルは表示されません。

ボリュームが noexec オプションによってマウントされる

影響を受ける GKE バージョン: 1.14、1.15.0 ~ 1.15.12-gke.17、1.16.0 ~ 1.16.13-gke.400、1.17.0 ~ 1.17.8、1.18.0 ~ 1.18.5

/var/lib/containerd にマウントされたボリュームは、no-exec オプションを指定してマウントされます。これにより、ボリュームからの実行可能ファイルの実行が拒否されます。

containerd のファイル記述子のリーク

影響を受ける GKE のバージョン: 1.14、1.15、1.16、1.17.0 ~ 1.17.12

containerd は、v1.3.0 以降で eventfd の問題が発生していましたが、v1.3.3 で修正されました。詳細については、https://github.com/containerd/containerd/issues/3949 をご覧ください。

次のステップ