このページは Cloud Translation API によって翻訳されました。

カスタムブートディスクの構成

Standard

このページでは、Google Kubernetes Engine（GKE）のクラスタまたはノードプールのノードブートディスクをカスタマイズする方法について説明します。

概要

GKE クラスタまたはノードプールを作成するとき、各ノードの Kubernetes ノードファイルシステムのインストール先となる永続ディスクの種類を選択できます。デフォルトでは、GKE はバージョン 1.24 以降のバランス永続ディスクを使用します。標準または SSD などの他の永続ディスクタイプを指定することもできます。詳しくは、ストレージオプションをご覧ください。

バランス永続ディスクと SSD 永続ディスクのディスク割り当ては、標準永続ディスクの割り当てとは異なります。標準永続ディスクからバランス永続ディスクに切り替える場合は、割り当ての増加をリクエストする必要があります。詳細については、リソースの割り当てをご覧ください。

SSD ブートディスクを使用する利点

SSD 永続ディスクをノードのブートディスクとして使用すると、パフォーマンス上の利点がいくつかあります。

ノードの起動時間が速くなります。
コンテナの中のバイナリとファイルを、ノードがより速く使用できるようになります。これにより、静的ファイルをホストするウェブサービスアプリケーションなど I/O 集約型のワークロードや、短時間で実行する I/O 集約型バッチジョブのパフォーマンスが向上します。
ノードのローカルメディアに保存されるファイル（hostPath または emptyDir ボリュームを介して公開）の I/O パフォーマンスを向上できます。

ノードブートディスクの種類の指定

クラスタまたはノードプールを作成するときに、ブートディスクの種類を指定できます。

gcloud

カスタムブートディスクを使用してクラスタを作成するには、次のコマンドを実行します。

[DISK-TYPE] は、次のいずれかの値です。

pd-balanced（バージョン 1.24 以降のデフォルト）
pd-standard（バージョン 1.23 以前のデフォルト）
pd-ssd
hyperdisk-balanced

この選択について詳しくは、Persistent Disk のタイプをご覧ください。

gcloud container clusters create [CLUSTER_NAME] --disk-type [DISK_TYPE]

既存のクラスタにノードプールを作成するには、次のコマンドを実行します。

gcloud container node-pools create [POOL_NAME] --disk-type [DISK_TYPE]

たとえば、次のコマンドは example-cluster クラスタを SSD 永続ディスクタイプ pd-ssd で作成します。

gcloud container clusters create example-cluster --disk-type pd-ssd

コンソール

Google Cloud コンソールでクラスタを作成するときにブートディスクを選択するには:

Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
[作成] をクリックします。
必要に応じてクラスタを構成します。
ナビゲーションパネルで [default-pool] を開き、[ノード] をクリックします。
[ブートディスクの種類] プルダウンリストで、永続ディスクの種類を選択します。
[作成] をクリックします。

既存のクラスタ用のカスタムブートディスクを使用してノードプールを作成する手順は、次のとおりです。

Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[ノードプールを追加] をクリックします。
必要に応じてノードプールを構成します。
ナビゲーションメニューで [ノード] をクリックします。
[ブートディスクの種類] プルダウンリストで、永続ディスクの種類を選択します。
[作成] をクリックします。

ノードブートディスクの保護

ノードブートディスクには、デフォルトで、コンテナイメージ、システムプロセスのログ、Pod のログ、書き込み可能なコンテナレイヤが保存されます。

ワークロードで configMap、emptyDir、hostPath のいずれかのボリュームを使用する場合、Pod はノードブートディスクに追加のデータを書き込むことがあります。emptyDir に関しては、tmpfs を使用するように構成することでこの書き込みを防止できます。この方法について詳しくは、Kubernetes のドキュメントをご覧ください。secret、downwardAPI、projected の各ボリュームは tmpfs を使用するようになっているため、これらを使用する Pod はノードブートディスクにデータを書き込みません。

デフォルトでは、Google Cloud は保存されている顧客コンテンツを暗号化し（ノードブートディスクを含む）、GKE によって暗号化が管理されます。これに関して利用者の操作は不要です。

ただし、ノードブートディスクへの書き込みを行うボリュームを使用する際に、GKE でワークロードデータをどのように保護するかを細かく制御したい場合があります。これを行うには、Pod によるノードブートディスクへの書き込みを防止するか、ノードブートディスク用として顧客管理の暗号鍵（CMEK）を使用します。

Pod によるブートディスクへの書き込みを防止する

Pod がノードブートディスクにデータを直接書き込まないようにするには、次のいずれかの方法を使用します。

Policy Controller

Policy Controller は、フリート内の GKE クラスタ全体でカスタムポリシーを宣言して適用できる GKE クラスタの機能です。

Policy Controller をインストールします。
k8sPspVolumeTypes 制約テンプレートを使用して、次のボリュームタイプを制限する制約を定義します。
- configMap
- emptyDir（tmpfs を使用しない場合）
- hostPath 手順については、Policy Controller のドキュメントで制約テンプレートライブラリを使用するをご覧ください。

次の制約の例では、クラスタ内のすべての Pod で、これらのボリュームタイプを制限します。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
  name: deny-boot-disk-writes
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
    volumes:
    - configMap
    - emptyDir
    - hostPath

PodSecurity アドミッションコントローラ

組み込みの Kubernetes PodSecurity アドミッションコントローラを使用すると、特定の Namespace またはクラスタでさまざまなレベルの Pod Security Standard を適用できます。制限付きポリシーにより、Pod はノードブートディスクに書き込めません。

PodSecurity アドミッションコントローラを使用するには、PodSecurity を使用して事前定義された Pod レベルのセキュリティポリシーを適用するをご覧ください。

顧客管理の暗号化

暗号鍵のローテーションを自身で管理する場合は、顧客管理の暗号鍵（CMEK）を使用できます。これらの鍵は、データを暗号化するデータ暗号鍵を暗号化する際に使用されます。ノードブートディスク用に CMEK を使用する方法については、顧客管理の暗号鍵の使用をご覧ください。

ノードブートディスク用の CMEK の制限として、ノードプールの作成後に変更はできません。この場合は次のようになります。

ノードプールが顧客管理の暗号化を使用して作成された場合、ブートディスク上の暗号化を後で無効にすることはできません。
ノードプールが顧客管理の暗号化を使用せずに作成された場合、ブートディスク上の暗号化を後で有効にすることはできません。ただし、顧客管理の暗号化を有効にして新しいノードプールを作成し、以前のノードプールを削除することは可能です。

制限事項

カスタムブートディスクを構成する前に、次の制限事項を考慮してください。

C3 マシンシリーズと G2 マシンシリーズは、pd-standard ノードのブートディスクタイプをサポートしていません。