ノードイメージ

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

概要

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

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

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

Container-Optimized OS

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

containerd(cos_containerd)が含まれている Container-Optimized OS

containerd は重要なビルディング ブロックであり、Docker のコアランタイム コンポーネントです。 cos_containerd は、Kubernetes と直接統合されているメインコンテナ ランタイムとして containerd が含まれる Container-Optimized OS イメージのバリアントです。

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

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

詳細については、containerd が含まれている Container-Optimized OS の使用をご覧ください。

Ubuntu

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

ノードイメージの比較

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

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

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

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

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

ソフトウェア パッケージを Container-Optimized OS イメージがあるホスト(つまりコンテナ外)にインストールしたり、ソフトウェア パッケージを個別にアップグレードしたりすることはできません。ただし、Container-Optimized OS ノードイメージには一般的なデバッグツールが含まれており、任意のデバッグツールを実行するための toolbox ラッパーが提供されます。いくつかの例を以下に示します。

sudo toolbox ping www.google.com
sudo toolbox apt-get install psmisc
sudo toolbox pstree -p

ラッパーを使用して cos ノードイメージを使用しているホストに追加のソフトウェアをインストールする方法の例については、Container-Optimized 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 を使用して依存関係経由でブート ターゲットをグループ化します。

ログの収集

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

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

Container-Optimized 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 はサポートされません。)
はい - 完全なテスト / サポート
GlusterFS はい - 完全なテスト / サポート
(XFS はサポートされません。)
はい - 完全なテスト / サポート
NFSv3 はい - 完全なテスト / サポート はい - 完全なテスト / サポート
NFSv4 はい - 完全なテスト / サポート はい - 完全なテスト / サポート
CephFS いいえ はい - 限定的なテスト
(ドライバはデフォルトではインストールされません。ceph クライアントを、できれば DaemonSet でインストールしてください。)
Cinder いいえ いいえ
Fibre Channel いいえ いいえ
Flocker 未対応 未対応
iSCSI いいえ いいえ
RBD いいえ いいえ

ノード VM の変更

ノード VM のブートディスクに加えた変更は、ノードの再作成により無効となります。ノードは、[手動アップグレード]、[自動アップグレード]、[自動修復]、[自動スケーリング] の間に再作成されます。ノードの再作成後も変更を維持するには、DaemonSet を使用します。

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

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

Container-Optimized OS

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

Ubuntu

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

次のステップ

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

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

Kubernetes Engine のドキュメント