ローカル SSD を使用する raw ブロック ストレージをプロビジョニングして使用する

このページでは、Google Kubernetes Engine（GKE）クラスタにローカル SSD ストレージをプロビジョニングする方法と、クラスタ内のノードにアタッチされたローカル SSD を使用する raw ブロック ストレージのデータを消費するようにワークロードを構成する方法について説明します。

このローカル SSD オプションを使用すると、基盤となるストレージをより詳細に管理でき、Pod 用の独自のノードレベルのキャッシュを構築して、アプリケーションのパフォーマンスを向上させることができます。このオプションはカスタマイズすることも可能で、その場合は必要に応じて DaemonSet を実行して RAID を構成し、ディスクをフォーマットして、ローカル SSD ディスクにファイル システムをインストールします。

GKE での raw ブロック アクセスに対するローカル SSD のサポートの詳細については、ローカル SSD についてをご覧ください。

準備

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

ローカル SSD を使用する raw ブロック ストレージを持つクラスタまたはノードプールを作成する

--local-nvme-ssd-block オプションを指定して gcloud CLI を使用し、ローカル SSD を使用する raw ブロック ストレージを持つクラスタを作成します。

クラスタまたはノードプールを作成するために実行する gcloud CLI コマンドは、使用しているマシンタイプが属しているマシンシリーズの世代によって異なります。たとえば、N1 マシンタイプと N2 マシンタイプはそれぞれ第 1 世代と第 2 世代のマシンシリーズに属していますが、C3 マシンタイプは第 3 世代のマシンシリーズに属しています。

ローカル SSD を使用するクラスタを作成する

gcloud container clusters create CLUSTER_NAME \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --cluster-version CLUSTER_VERSION \
    --local-nvme-ssd-block

ローカル SSD でノードプールを作成する

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-version NODE_VERSION \
    --local-nvme-ssd-block

ノードプール内のノードは cloud.google.com/gke-local-nvme-ssd=true ラベル付きで作成されます。ラベルは、次のコマンドを実行して確認できます。

kubectl describe node NODE_NAME

ノードプールにアタッチされたローカル SSD ごとに、ホスト OS は、順序を表すフォルダの下のディスクにアクセスするためのシンボリック リンク（シムリンク）とユニバーサリー ユニーク アイデンティファイア（UUID）を使用するシンボリック リンクを作成します。たとえば、--local-nvme-ssd-block オプションを使用して 3 つのローカル SSD を使用するノードプールを作成する場合、ホスト OS はディスクに次のシンボリック リンクを作成します。

• /dev/disk/by-id/google-local-ssd-block0
• /dev/disk/by-id/google-local-ssd-block1
• /dev/disk/by-id/google-local-ssd-block2

それに応じて、ホスト OS はディスク用の UUID を使用して次のシンボリック リンクも作成します。

• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID1
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID2
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID3

これにより、一意の ID を使用してディスクに確実にアクセスできるようになります。

ローカル SSD ボリュームにアクセスする

次の例は、ローカル SSD を使用する raw ブロック ストレージにアクセスする方法を示しています。

ローカル PersistentVolumes

ローカル SSD ボリュームは、PersistentVolume を使用して Pod としてマウントできます。

ローカル SSD から PersistentVolume を作成するには、PersistentVolume を手動で作成するか、ローカル Volume の静的プロビジョナーを実行します。

ローカル PersistentVolumes の制限事項

• ローカル PersistentVolumes では、クラスタの自動スケーリングと動的プロビジョニングはサポートされていません。

• GKE クラスタのアップグレードやノードの修復を行うと Compute Engine インスタンスが削除され、これによってローカル SSD ディスクのデータもすべて削除されます。

• ローカル SSD を永続データに使用するクラスタやノードプールでは、ノードの自動アップグレードやノードの自動修復を有効にしないでください。まずアプリケーション データをバックアップしてから、データを新しいクラスタやノードプールに復元する必要があります。

• ノードの削除、アップグレード、修復、スケールダウンが行われても、ローカル PersistentVolume オブジェクトは自動的にクリーンアップされません。削除されたノードに関連付けられている古いローカル PersistentVolume オブジェクトを定期的にスキャンし、削除することをおすすめします。

PersistentVolume を手動で作成する

クラスタ内の各ノードで、ローカル SSD ごとに PersistentVolume を手動で作成できます。

特定ノードのローカル SSD を参照するには、PersistentVolume オブジェクトの nodeAffinity フィールドを使用します。次の例は、Linux を実行するノードのローカル SSD の PersistentVolume 仕様を示しています。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "gke-test-cluster-default-pool-926ddf80-f166"

この例では、ローカル SSD ディスクが RAID 用に手動で構成され、フォーマットされて、ノード gke-test-cluster-default-pool-926ddf80-f166 の /mnt/disks/ssd0 にマウントされます。nodeAffinity フィールドは、ローカル SSD が RAID 用に手動で構成されているノードにワークロードを割り当てるために使用されます。クラスタにノードが 1 つしかない場合、またはすべてのノードで RAID を構成している場合、nodeAffinity フィールドは必要ありません。

対応する PersistenVolumeClaim の仕様は次のようになります。

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: ssd-local-claim
  spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: local-storage
    resources:
      requests:
        storage: 37Gi

PersistentVolume を削除する場合は、手動でディスクからデータを消去する必要があります。

ローカル Volume の静的プロビジョナーを実行する

ローカル ボリュームの静的プロビジョナーを使用して、ローカル SSD の PersistentVolume を自動的に作成できます。プロビジョナーは、各ノードのローカル SSD ディスクの管理、それらの PersistentVolume の作成と削除、PersistentVolume の消去時のローカル SSD ディスク上のデータのクリーンアップを行う DaemonSet です。

ローカル ボリュームの静的プロビジョナーを実行する手順は次のとおりです。

1. DaemonSet を使用して RAID を構成し、ディスクをフォーマットします。

   1. gke-daemonset-raid-disks.yaml 仕様をダウンロードします。

   2. RAID ディスクの DaemonSet をデプロイします。DaemonSet は、すべてのローカル SSD ディスクに RAID 0 アレイを設定し、デバイスを ext4 ファイルシステムにフォーマットします。

      kubectl create -f gke-daemonset-raid-disks.yaml
      

2. gke-nvme-ssd-block-raid.yaml 仕様をダウンロードし、必要に応じて仕様の namespace フィールドを変更します。

   この仕様には、次のリソースが含まれています。

   • プロビジョナーの ServiceAccount
   • 次を行う権限の ClusterRole と ClusterRoleBindings
     • PersistentVolume オブジェクトの作成と削除
     • Node オブジェクトの取得
   • GKE のプロビジョナー設定の ConfigMap
   • プロビジョナーを実行するための DaemonSet

3. プロビジョナーをデプロイします。

   kubectl create -f gke-nvme-ssd-block-raid.yaml
   

   プロビジョナーが正常に実行されると、クラスタ内の RAID ローカル SSD デバイスに PersistentVolume オブジェクトが作成されます。

4. 次の PersistentVolumeClaim マニフェストを provisioner-pvc-example.yaml として保存します。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: PVC_NAME
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 50Gi
     storageClassName: nvme-ssd-block
   

   PVC_NAME は、PersistentVolumeClaim の名前に置き換えます。

5. PersistentVolumeClaim を作成します。

   kubectl create -f provisioner-pvc-example.yaml
   

6. 次の Pod マニフェストを provisioner-pod-example.yaml として保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
   spec:
     containers:
     - name: "shell"
       image: "ubuntu:14.04"
       command: ["/bin/sh", "-c"]
       args: ["echo 'hello world' > /cache/test.txt && sleep 1 && cat /cache/test.txt && sleep 3600"]
       volumeMounts:
       - mountPath: /cache
         name: local-ssd-storage
     volumes:
     - name: local-ssd-storage
       persistentVolumeClaim:
         claimName: PVC_NAME
   

   POD_NAME は、Pod の名前に置き換えます。

7. Pod を作成します。

   kubectl create -f provisioner-pod-example.yaml
   

遅延ボリューム バインディングを有効にする

スケジューリングを改善するには、volumeBindingMode: WaitForFirstConsumer を使用して StorageClass を作成することもおすすめします。これにより、Pod のスケジューリング時点まで PersistentVolumeClaim バインディングが遅延され、Pod を実行できる適切なノードからローカル SSD が選択されるようになります。この強化されたスケジューリング動作により、実行可能な Pod 用のノードの選択時に、どのノードに使用可能なローカル SSD があるかを踏まえて、Pod の CPU とメモリのリクエスト、ノード アフィニティ、Pod アフィニティと反アフィニティ、複数の PersistentVolumeClaim リクエストが考慮されます。

次の例では、遅延ボリュームのバインディング モードを使用します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-nvme"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

遅延バインディングを使用して StorageClass を作成するには、YAML マニフェストをローカル ファイルに保存して、次のコマンドを使用してクラスタに適用します。

kubectl apply -f filename

トラブルシューティング

トラブルシューティングの手順については、GKE のストレージのトラブルシューティングをご覧ください。

次のステップ

• ノードプールの詳細を理解する。