ノードイメージ

このページでは、Google Kubernetes Engine ノードに使用できるノードイメージについて説明します。ノードイメージの選択方法については、ノードイメージの指定を参照してください。

概要

GKE クラスタまたはノードプールを作成するときに、各ノードで実行されるオペレーティング システム イメージを選択できます。異なる種類のノードイメージを使用するように既存のクラスタをアップグレードすることもできます。

使用可能なノードイメージ

GKE のクラスタには、次のノードイメージ オプションが用意されています。

Container-Optimized OS

Container-Optimized OS ノードイメージは、Linux カーネルの新しいバージョンに基づいており、ノードのセキュリティを強化するように最適化されています。Google のサポートにより、セキュリティ パッチが迅速に提供され、機能の開発とテストが繰り返し行われています。コンテナ用に最適化された OS イメージは、サポート、セキュリティ、安定性の面で、他のイメージより優れています。

Ubuntu

Ubuntu ノードイメージは、GKE のノードイメージ要件に照らして検証されています。ノードで XFS、CephFS または Debian パッケージをサポートする必要がある場合は、Ubuntu ノードイメージを使用してください。

containerd ノードのイメージ

containerd は重要なビルディング ブロックであり、Docker のコアランタイム コンポーネントです。containerd をメインコンテナ ランタイムとして使用して Kubernetes に直接統合される OS イメージは、cos_containerdubuntu_containerd の 2 つです。

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

コンテナ用に最適化された OS 上の containerd(cos_containerd

cos_containerd は、コンテナ用に最適化された OS イメージのバリアントの 1 つであり、コンテナ ランタイムとして containerd が Kubernetes と直接統合されています。

cos_containerd では Kubernetes バージョン 1.14.3 以降が必要です。

詳細については、containerd が含まれるコンテナ用に最適化された OS の使用をご覧ください。

Ubuntu 上の containerd(ubuntu_containerd

ubuntu_containerd は、Ubuntu イメージのバリアントであり、containerd をコンテナ ランタイムとして使用します。

ubuntu_containerd では Kubernetes バージョン 1.14.3 以降が必要です。

ノードイメージの比較

以降のセクションでは、Container-Optimized OS および Ubuntu ノードイメージを次のようなオペレーションの観点から比較します。

  • ソフトウェア パッケージの管理
  • システムの初期化
  • ログの収集
  • ファイル システムのレイアウト
  • ストレージ ドライバのサポート

ソフトウェア パッケージ マネージャ

cos および cos_containerd のノードイメージでは、Docker(containerd)コンテナ ランタイムのサポートが組み込まれている最小限のルートファイル システムが使用されます。これは、ソフトウェアをホストにインストールするためのソフトウェア パッケージ マネージャーとしても使用されます。Ubuntu イメージでは Aptitude パッケージ マネージャーが使用されます。

コンテナ用に最適化された OS 上のソフトウェアを管理する

コンテナ用に最適化された OS イメージには、apt-get などのパッケージ管理ソフトウェアは含まれていません。従来のメカニズムを使用して任意のソフトウェアをノードにインストールすることはできません。代わりに、必要なソフトウェアが格納されるコンテナ イメージを作成します。

コンテナ用に最適化された OS には、デバッグ専用として、pingpsmiscpstree などの一般的なデバッグツールをインストールして実行するための CoreOS Toolbox が存在します。

コンテナ用に最適化された OS ノードのデバッグについて詳しくは、コンテナ用に最適化された OS 入門ガイドをご覧ください。

Ubuntu 上のソフトウェアを管理する

Ubuntu イメージには、Aptitude パッケージ マネージャーがあらかじめインストールされています。apt-get コマンドを使用して、これらのイメージにパッケージをインストールできます。たとえば、ceph パッケージをインストールするには、次のコマンドを実行します。

sudo apt-get update
sudo apt-get install ceph

システムの初期化

Container-Optimized OS ノードイメージと Ubuntu ノードイメージは、システム初期化プロセス中に systemd を使用してシステムのリソースとサービスを管理します。

これら 2 つのノードイメージは、systemd.service ファイルを使用してノード上の services と、依存関係を介してブート ターゲットをグループ化する systemd.targets を定義します。

ログの収集

コンテナ用に最適化された OS ノードイメージと Ubuntu ノードイメージは、systemd-journald を使用してシステム全体のログを収集します。

Container-Optimized OS と Ubuntu のログを表示する

コンテナ用に最適化された OS ノードイメージまたは Ubuntu ノードイメージを含むノードでログを表示するには、journalctl コマンドを使用する必要があります。たとえば、Docker デーモンのログを表示するには次のコマンドを使用します。

sudo journalctl -u docker

kubelet のログを表示するには次のコマンドを使用します。

sudo journalctl -u kubelet

ファイル システムのレイアウト

Ubuntu ノードイメージは、Linux の標準ファイル システム レイアウトを使用します。

Container-Optimized OS ノードイメージのファイル システム レイアウトは、ノード セキュリティを強化するように最適化されています。ブートディスク領域は次の 3 種類のパーティションに分割されます。

  • ルート パーティション: 読み取り専用としてマウントされます。
  • ステートフル パーティション: 書き込み可能でステートフルです。
  • ステートレス パーティション: 書き込み可能ですが、リブート時に内容が保存されません。

Container-Optimized OS の使用中にコンテナ外の特定のファイルシステム レイアウトを想定する独自のサービスを実行する場合は、パーティショニングに注意してください。

Container-Optimized OS ファイル システムを使用する

以下に Container-Optimized OS ノードイメージのファイル システムのパスの一覧を示し、その特性や推奨される使用方法を説明します。

パス 特性 目的
/
  • 読み取り専用
  • 実行可能
整合性を維持するため、ルート ファイルシステムは読み取り専用としてマウントされます。カーネルによって、整合性のあるルート ファイルシステムが起動時に確認され、エラー時にはブートが拒否されます。
/home
/var
  • 書き込み可能
  • 実行不可能
  • ステートフル
これらのパスは、ブートディスクの存続期間にわたって保存されるようにデータを格納するためのものです。/mnt/stateful_partition からマウントされます。
/var/lib/google
/var/lib/cloud
/var/lib/docker
/var/lib/kubelet
/var/lib/toolbox
  • 書き込み可能
  • 実行可能
  • ステートフル
これらのパスは、それぞれ Compute Engine パッケージ(アカウント マネージャ サービスなど)、cloud-init、Docker、Kubelet、Toolbox の作業ディレクトリです。
/etc
  • 書き込み可能
  • 実行不可能
  • ステートレス
  • tmpfs
通常、/etc には構成(cloud-init によって定義される systemd サービスなど)が保存されます。インスタンスを新規作成するときやインスタンスを再起動するときに cloud-init が適用されるため、インスタンスの望ましい状態を cloud-init にキャプチャすることをおすすめします。
/tmp
  • 書き込み可能
  • 実行不可能
  • ステートレス
  • tmpfs
通常、/tmp は一時的な領域として使用され、永続的なデータの格納には使用できません。
/mnt/disks
  • 書き込み可能
  • 実行可能
  • ステートレス
  • tmpfs
/mnt/disks 内のディレクトリには永続ディスクをマウントできます。

ストレージ ドライバのサポート

各ノードイメージは、サポートするストレージ プラグインの種類が異なります。下の表では、ノードイメージのストレージ ドライバのサポート状況が次のいずれかに分類されています。

  • はい - 完全なテスト / サポート: このストレージ プラグインは、そのノードイメージで完全にサポートおよびテストされています。
  • はい - 限定的なテスト: このストレージ プラグインはそのノードイメージで使用できますが、十分なテストが行われていないため、予期しない動作が発生する可能性があります。Container-Optimized OS では、これらのプラグインは最終的には完全にテストおよびサポートされる予定です。
  • 未対応: このストレージ プラグインはそのノードイメージでテストまたは使用されておらず、正常に機能する保証はありません。テストの予定もありません。
  • いいえ: このストレージ プラグインは、ノードの OS または Google Cloud Platform に固有の制限により、そのノードイメージでは使用できません。

次の表は、各 GKE ノードイメージの、一般的なストレージ プラグインのサポート状況を示しています。

ボリュームのタイプ Container-Optimized OS(cos)で使用できるか Ubuntu で使用できるか
Google Compute Engine
永続ディスク(EXT4 または XFS)
はい - 完全なテスト / サポート
(XFS はサポートされません。)
はい - 完全なテスト / サポート
NFSv3 はい - 完全なテスト / サポート はい - 完全なテスト / サポート
NFSv4 はい - 完全なテスト / サポート はい - 完全なテスト / サポート
CephFS いいえ はい - 限定的なテスト
(ドライバはデフォルトではインストールされません。ceph クライアントを、できれば DaemonSet でインストールしてください。)
Cinder いいえ いいえ
Fibre Channel いいえ いいえ
Flocker 未対応 未対応
iSCSI いいえ いいえ
RBD いいえ いいえ

ノード VM の変更

ノード VM のブートディスクに加えた変更は、ノードの再作成が行われると存続しません。ノードは、手動アップグレード自動アップグレード自動修復自動スケーリングの際に再作成されます。さらにノードは、GKE Sandboxノード間の可視化シールドノードなど、ノードの再作成を必要とする機能を有効にすると、再作成されます。

ノードの再作成後も変更を維持するには、DaemonSet を使用します。

カーネルやコンテナ ランタイム(containerd または docker)など、ノードイメージによって提供される重要なソフトウェアを管理することはおすすめできません。ノードイメージは幅広くテストされ、ノードイメージで提供される重要なソフトウェアを変更すると、ノードはテスト不可能な未知の状態になります。

ノードイメージ リリースノート

Container-Optimized OS

Google では、Container-Optimized OS の包括的なドキュメントを提供しています。

Ubuntu

定期的に Google がアップデートする Ubuntu イメージを、クラスタのノードでご使用になれます。このアップデートに関する情報(デフォルトでインストールされるパッケージの一覧を示すマニフェストへのリンクなど)については、GKE のリリースノートを参照してください。

次のステップ