containerd でノードイメージを使用する

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

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

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

containerd ノードでの docker コマンドの実行

Docker は各 containerd ノードで引き続き使用できますが、Kubernetes では containerd をコンテナ ランタイムとして使用します。Docker はノード上の Kubernetes コンテナを管理しません。このため、Docker コマンドまたは Docker API を使用して、コンテナの表示や操作を行うことはできません。

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

コンテナの検査またはトラブルシューティングを行うには、プリインストールされている crictl を使用します。 は、Container Runtime Interface(CRI)仕様に準拠しているすべてのランタイムに移植できます。containerd Docker Engine とやり取りする場合は、crictl の使用をおすすめします。詳細については、crictl ユーザーガイドをご覧ください。

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

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

イメージをビルドする

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

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

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

次のステップ

Kubernetes 1.11 のリリース情報で、containerd の統合の詳細を確認する。 containerdCRI プラグイン のドキュメントで、さらに詳しい情報を確認する。

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

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

Kubernetes Engine のドキュメント