ノードイメージ

このページでは、Google Kubernetes Engine（GKE）ノードに使用できるノードイメージについて説明します。

GKE Autopilot ノードは常に、推奨されるノード オペレーティング システムである containerd（cos_containerd）を含む Container-Optimized OS を使用します。GKE Standard を使用する場合は、クラスタまたはノードプールの作成中に、各ノードで実行するオペレーティング システム イメージを選択できます。異なる種類のノードイメージ タイプを使用するように既存の Standard クラスタをアップグレードすることもできます。ノードイメージの設定手順については、ノードイメージの指定をご覧ください。

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

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

OS ノードイメージ
Container-Optimized OS
Ubuntu
Windows Server

Container-Optimized OS

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

イメージ プロジェクトとファミリーの詳細については、ノードイメージのソース プロジェクトをご覧ください。

Container-Optimized OS のバリアント

Container-Optimized OS には 2 種類のコンテナ ランタイムが用意されています。コンテナ ランタイムの違いを除き、イメージは同じです。

  • containerd を含む Container-Optimized OS（cos_containerd）: cos_containerd イメージでは、Kubernetes と直接統合されたコンテナ ランタイムとして containerd が使用されます。GKE Autopilot クラスタは常にこのイメージを使用します。詳細については、containerd ノードイメージをご覧ください。
  • Docker を含む Container-Optimized OS（cos）: cos イメージでは、Docker コンテナ ランタイムが使用されます。

Ubuntu

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

イメージ プロジェクトとファミリーの詳細については、オペレーティング システム別の機能サポートをご覧ください。

Ubuntu のバリエーション

Ubuntu には 2 種類のコンテナ ランタイムが用意されています。コンテナ ランタイムの違いを除き、イメージは同じです。

  • containerd を含む Ubuntu（ubuntu_containerd）: ubuntu_containerd イメージでは、containerd がコンテナ ランタイムとして使用されます。詳細については、containerd ノードイメージをご覧ください。

  • Docker を含む Ubuntu（ubuntu）: ubuntu イメージでは、Docker がコンテナ ランタイムとして使用されます。

Windows Server

Windows Server ノードプールを使用したクラスタの作成時に、Windows Server Semi-Annual Channel（SAC）または Windows Server Long-Term Servicing Channel（LTSC）を使用できます。Windows ノードイメージはすべて Windows Server Datacenter Core イメージです。1 つのクラスタで、異なる Windows Server バージョンを使用する複数の Windows Server ノードプールを使用できますが、各ノードプールで使用できる Windows Server のバージョンは 1 つのみです。詳しくは、Windows ノードイメージを選択するをご覧ください。

Docker と containerd の 2 つのコンテナ ランタイムが Windows Server LTSC と SAC ノードイメージに用意されています。コンテナ ランタイムの違いを除き、イメージは同じです。

  • containerd ランタイム イメージ（GKE バージョン 1.21 以降で使用可能）:

    • containerd を含む Windows Server LTSC（windows_ltsc_containerd）: windows_ltsc_containerd イメージでは、containerd がコンテナ ランタイムとして使用されます。現在、このイメージタイプは、Windows Server 2022 と Windows Server 2019 の 2 つのノードイメージにマッピングされています。Windows LTSC2022 ノードプールを作成するには、CLI コマンドで windows-os-version フラグを指定します。

      Windows Server 2022 ノードプールの作成の詳細については、Windows ノードプールを作成するをご覧ください。

      containerd ノードイメージの詳細については、containerd ノードイメージをご覧ください。

    • containerd を含む Windows Server SAC（windows_sac_containerd）: windows_sac_containerd イメージでは、containerd がコンテナ ランタイムとして使用されます。

      詳細については、containerd ノードイメージをご覧ください。

  • Docker ランタイム イメージ（GKE バージョン 1.16 以降で使用可能）:

    • Docker を含む Windows Server LTSC（windows_ltsc）: windows_ltsc イメージでは、Docker がコンテナ ランタイムとして使用されます。
    • Docker を含む Windows Server SAC（windows_sac）: windows_sac イメージでは、Docker がコンテナ ランタイムとして使用されます。

イメージ プロジェクトとファミリーの詳細については、オペレーティング システム別の機能サポートをご覧ください。

Linux ノードイメージの比較

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

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

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

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

Container-Optimized OS 上のソフトウェアを管理する

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

標準クラスタでのデバッグ専用に、Container-Optimized OS には ping、psmisc、pstree などの一般的なデバッグツールをインストールして実行するための CoreOS Toolbox が存在します。Container-Optimized OS ノードのデバッグについて詳しくは、Container-Optimized OS 入門ガイドをご覧ください。

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

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

sudo apt-get update
sudo apt-get install ceph

システムの初期化

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

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

ログの収集

Container-Optimized OS ノードイメージと Ubuntu ノードイメージは、systemd-journald を使用してシステム全体のログを収集します。

Container-Optimized OS と Ubuntu のログの表示

Container-Optimized OS ノードイメージまたは Ubuntu ノードイメージを含むノードでログを表示するには、journalctl コマンドを使用する必要があります。たとえば、containerd デーモンのログを表示するには次のコマンドを使用します。

sudo journalctl -u containerd

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/docker
/var/lib/toolbox
  • 書き込み可能
  • 実行可能
  • ステートフル
 これらのパスはそれぞれ、Compute Engine パッケージ（アカウント マネージャー サービスなど）、Docker、Toolbox の作業ディレクトリです。
/var/lib/cloud
  • 書き込み可能
  • 実行可能
  • ステートレス
  • tmpfs
 このパスは、cloud-init パッケージの作業ディレクトリです。
/etc
  • 書き込み可能
  • 実行可能
  • ステートレス
  • tmpfs
 通常、構成（cloud-init によって定義される systemd サービスなど）が保存されます。インスタンスを新規作成するときやインスタンスを再起動するときに cloud-init が適用されるため、インスタンスの望ましい状態を cloud-init にキャプチャすることをおすすめします。
/tmp
  • 書き込み可能
  • 実行不可能
  • ステートレス
  • tmpfs
 通常、一時的な領域として使用され、永続的なデータの格納には使用できません。
/mnt/disks
  • 書き込み可能
  • 実行可能
  • ステートレス
  • tmpfs
 /mnt/disks 内のディレクトリには永続ディスクをマウントできます。

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

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

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

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

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

ノード VM の変更

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

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

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

Container-Optimized OS ノードイメージのバージョンを GKE パッチ バージョンにマッピングする

GKE は、GKE パッチ バージョンの Container-Optimized OS ノードイメージ バージョンへの JSON マッピングを公開します。

このマッピングを使用して、特定のバージョンの GKE にアップグレードし、特定のイメージ バージョンを取得できます。たとえば、クラスタにイメージ バージョンの特定の機能や修正が必要な場合は、マッピングを見つけて、クラスタを特定の GKE バージョンにアップグレードし、変更を加えた Container-Optimized OS イメージ バージョンを取得できます。Container-Optimized OS イメージ リリースの詳細については、Container-Optimized OS リリースノートをご覧ください。

このリストは、おおよそ 1 週間ごとに更新されます。情報の鮮度を確認するには、JSON ファイルの creation_time フィールドを参照してください。

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

Container-Optimized OS

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

Ubuntu

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

既知の問題

Docker ランタイムを含む Container-Optimized OS を使用する GKE ノードでのランダム接続リセット

同じノード上の 2 つの Pod が Kubernetes ClusterIP Service を使用して通信する場合、Docker を含む Container-Optimized OS（cos）を使用する GKE ノードで、TCP 接続がランダムにリセットされる可能性があります。

次の GKE バージョンが影響を受けます。

  • 1.20.5-gke.100 以降

この問題を回避するには、次のいずれかの方法を使用します。

ノードイメージのソース プロジェクト

GKE クラスタで使用可能なノードイメージは、次のソース プロジェクトに含まれています。

  • Container-Optimized OS のイメージ: gke-node-images
  • Ubuntu のイメージ: ubuntu-os-gke-cloud
  • Windows Server のイメージ: gke-windows-node-images

上記のソース プロジェクトに加えて、GKE は GKE チーム専用の次のソース プロジェクトも使用します。

  • ubuntu-os-gke-cloud-private（GKE チーム専用に予約）
  • ubuntu-os-gke-cloud-devel（GKE チーム専用に予約）

安全性の高いクラスタを設定する場合は、ソース プロジェクト名を把握しておく必要があります。リストにあるソース プロジェクトは変更される場合があります。

次のステップ