このページでは、Google Kubernetes Engine(GKE)ノードのコンテナ ランタイムとして containerd を使用するノードイメージについて説明します。
containerd について
コンテナ ランタイムは、コンテナの実行と、Kubernetes のコンテナ管理の抽象化を行うソフトウェアです。コンテナにはいくつかの異なるランタイムが存在します。
containerd ランタイムは業界標準のコンテナ ランタイムであり、Kubernetes によってサポートされ、他の多くのプロジェクトで使用されています。containerd ランタイムには、gVisor やイメージ ストリーミングなどの豊富な機能を実装して GKE の機能を拡張できるようにするレイヤ抽象化の機能が用意されています。
containerd ランタイムは、Docker ランタイムよりも効率的で安全なリソースとみなされます。
GKE クラスタでの containerd イメージの使用
新しい GKE クラスタを作成する場合、既存のクラスタに新しいノードプールを作成する場合、または既存のクラスタをアップグレードする場合は、コンテナ化されたノードイメージを使用できます。GKE Autopilot クラスタは、常に containerd とともに Container-Optimized OS を使用します。
次の表に、クラスタモードとノードプール OS ごとに、サポートされている containerd ノードイメージを示します。
クラスタモード | ノードプール OS | ノードイメージ |
---|---|---|
Autopilot | Linux | cos_containerd |
Standard | Linux |
|
Standard | Windows Server |
これらのイメージには、GKE バージョン 1.21.1-gke.2200 以降が必要です。 |
特権 Pod を使用して Docker にアクセスする
ユーザーが特権 Pod を使用してノード上の Docker Engine にアクセスする場合は、Docker に直接依存しないようにそれらのワークロードを更新する必要があります。たとえば、ロギングとモニタリングの抽出プロセスを Docker Engine から GKE システム アドオンに移行することを検討してください。
containerd を使用してコンテナ イメージをビルドする
containerd を使用してコンテナ イメージをビルドすることはできません。containerd 使用した Linux イメージには Docker バイナリが含まれているため、Docker でイメージをビルドして push できます。しかし、個々のコンテナやローカルノードを使用して、イメージをビルドするコマンドを実行することはおすすめしません。
Kubernetes は自身のスコープ外のローカル プロセスで使用されるシステム リソースを認識しないので、Kubernetes コントロール プレーンはリソースを割り当てる際にそれらのプロセスを考慮することができません。その結果、リソース関係の GKE ワークロードが枯渇する可能性があります。また、ノードが不安定になる可能性もあります。
このようなタスクを実施する場合は、個々のコンテナのスコープ外で他のサービス(Cloud Build など)を利用するか、kaniko などのツールを使用して Kubernetes ワークロードの形でイメージをビルドすることを検討してください。
これらの推奨事項を採用できない場合は、リスクを理解したうえで、ローカルノードで Docker によるイメージのビルドを進めてください。イメージは、GKE クラスタで使用する前にレジストリへ push しておく必要があります。containerd を使用する Kubernetes では、Docker を使用してローカルにビルドされたイメージは認識されません。
containerd ノード上のコンテナをデバッグする
Linux ノードでのデバッグやトラブルシューティングのため、Kubernetes コンテナ ランタイム用にビルドされたポータブル コマンドライン ツール crictl
を使用して、containerd と対話できます。crictl
は、コンテナやイメージの表示、ログの読み取り、コンテナでのコマンドの実行などの一般的な機能をサポートします。サポートされている全機能と使用方法については、crictl ユーザーガイドをご覧ください。
Windows Server ノードの場合、containerd デーモンは containerd
という名前の Windows サービスとして実行されます。
ログの利用方法は次のとおりです。
- Windows:
C:\etc\kubernetes\logs\containerd.log
- Linux:
journalctl -u containerd
を実行
LOG NAME: "container-runtime"
のログ エクスプローラで Windows ノードと Linux ノードのログを表示することもできます。
既知の問題とトラブルシューティング
トラブルシューティングと既知の問題の回避策については、コンテナ ランタイムのトラブルシューティングをご覧ください。
次のステップ
- containerd の統合について、Kubernetes 1.11 のリリース情報でさらに詳しい情報を確認する。containerd と CRI プラグインのドキュメントで、さらに詳しい情報を確認する。
- kubernetes.io で Dockershim の情報から移行を確認する。
- Kubernetes による Dockershim の非推奨について確認する。
- containerd の gVisor でアプリを保護する方法を確認する。
- Cloud Build を使用して Google Cloud でイメージを安全確実にビルドし、Docker が必要になる可能性があるカスタム ソリューションを置き換えるメリットについて確認する。