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

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

概要

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

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

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

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

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

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

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

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

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

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

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

ノード ブートディスクには、デフォルトで、コンテナ イメージ、システム プロセスのログ、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 クラスタの機能です。

1. Policy Controller をインストールします。
2. 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 ノードのブートディスク タイプをサポートしていません。

次のステップ

• 最小 CPU プラットフォームの指定方法を確認する。
• 顧客管理の暗号化について確認する。
• GKE で顧客管理の暗号鍵を使用する方法について確認する。