カスタム ブートディスク

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

概要

GKE クラスタまたはノードプールを作成するとき、各ノードの Kubernetes ノードファイル システムのインストール先となる永続ディスクの種類を選択できます。デフォルトでは、GKE は標準永続ディスクを使用します。SSD 永続ディスクを指定することもできます。

SSD 永続ディスクは、特定のワークロードについてノードのパフォーマンスを向上させることができます。ただし、SSD 永続ディスクをノード ブートディスクに選ぶと、追加の費用が発生します。詳しくは、ストレージ オプションをご覧ください。

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

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

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

標準永続ディスクと比較した SSD 永続ディスクのパフォーマンスについて詳しくは、ブロック ストレージのパフォーマンスの比較をご覧ください。

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

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

gcloud

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

[DISK-TYPE] は、以下のいずれかです。

  • pd-standard: 標準の永続ディスク(デフォルト)
  • pd-ssd: SSD 永続ディスク
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

Console

Google Cloud Console でクラスタを作成するときにブートディスクを選択するには、次の手順を実行します。

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] をクリックします。

  3. [標準クラスタ] テンプレートを選択するか、ワークロードに適切なテンプレートを選択します。

  4. 必要に応じてクラスタを構成します。

  5. デフォルトのノードプールの [高度な編集] をクリックします。[ブートディスクの種類] プルダウン メニューで、[標準永続ディスク] か [SSD 永続ディスク] を選択します。

  6. [保存] をクリックして [高度な編集] オーバーレイを閉じます。

  7. [作成] をクリックします。指定された種類のブートディスクがクラスタのデフォルト ノードプールに使用されます。

カスタム ブートディスクを使用してノードプールを作成するには:

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. 目的のクラスタを選択します。

  3. [ノードプール] メニューから、[ノードプールを追加] をクリックします。

  4. 必要に応じてノードプールを構成します。

  5. [ブートディスクの種類] プルダウン メニューで、[標準永続ディスク] か [SSD 永続ディスク] を選択します。

  6. [作成] をクリックします。

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

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

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

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

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

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

ポッドからノード ブートディスクへのデータの直接書き込みを回避して、接続されたディスクのみに書き込むように制限することができます。ポッドがブートディスクに書き込まないように制限するには、PodSecurityPolicyvolumes フィールドから次のボリュームを除外します。

  • configMap
  • emptyDir(tmpfs を使用しない場合)
  • hostPath

次の PodSecurityPolicy の preventWritingToBootDisk.yaml の例では、ブートディスクへの書き込みが防止されます。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: preventWritingToBootDisk
spec:
  Volumes: # Exclude configMap, emptyDir (if not backed by tmpfs), and hostPath.
           # Include all other desired volumes.
     - 'persistentVolumeClaim'
  # Required fields.
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

顧客管理の暗号化

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

ノード ブートディスク用に CMEK を使用する場合、次の制限があります。

  • 既存のクラスタまたはノードプール内のブートディスクでは、顧客管理の暗号化の有効 / 無効を切り替えることはできません。
  • CMEK は、pd-standardpd-ssd の永続ディスクにのみ使用できます。

次のステップ