containerd が含まれている Container-Optimized OS の使用

このページでは、Google Kubernetes Engine(GKE)ノード上で containerd(cos_containerd)が含まれている Container-Optimized OS を使用するための追加情報を説明します。cos_containerd イメージは、containerd CRI ランタイム環境へのアクセスを提供します。

GKE クラスタにおいて cos_containerd イメージを使用する

cos_containerd OS イメージは、GKE v1.11 以降でベータ版として提供されます。cos_containerd をイメージタイプとして選択できるのは、新しい GKE クラスタを作成するとき、既存のクラスタに新しいノードプールを作成するとき、または既存の GKE クラスタを v1.11 以降にアップグレードするときです。

ベータ期間中、Google はお客様からのフィードバックを収集しています。

現在のところ、cos_containerd は、Container-Optimized OS(COS)イメージでのみ利用できます。

GKE ノード上で docker コマンドを実行する

GKE v1.11 以降では、ノードごとに Docker が提供されますが、containerd がデフォルトのランタイムと位置付けられています。しかし、Docker ではノード上の Kubernetes コンテナは管理されないので、Docker のコマンドや Docker API を使用してもコンテナを表示したり操作したりすることはできません。

GKE ノード上でコンテナの問題を解決する

コンテナの検査やトラブルシューティングには、プリインストール済みの crictl を使用してください。crictl は Container Runtime Interface(CRI)仕様に準拠するすべてのランタイムで使用できます。GKE v1.11 以降で、crictlcontainerd と Docker Engine を操作する推奨ツールとされています。詳細については、crictl ユーザーガイドをご覧ください。

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

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

イメージをビルドする

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

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

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

次のステップ

containerd 統合の詳細については、Kubernetes 1.11 のリリース情報をご覧ください。さらに詳しい情報については、containerd および CRI プラグインに関するドキュメントをご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント