Storage

このページでは、VMware の Google Distributed Cloud（ソフトウェアのみ）のストレージ コンセプトについて説明します。

概要

Google Distributed Cloud は、次のものを介して、外部ブロック ストレージまたはファイル ストレージ システムと統合されます。

  • vSphere Container Storage Interface（CSI）ドライバ
  • サードパーティの CSI ドライバ
  • Kubernetes in-tree Volume プラグイン

vSphere データストア

管理クラスタを作成するときに、クラスタの etcd データ用に既存の vSphere データストアを指定します。

ユーザー クラスタを作成するときに、管理クラスタと同じデータストアを使用することも、異なるデータストアを指定することもできます。個々のノードプールのデータストアを指定することもできます。

管理クラスタとユーザー クラスタで使用される vSphere データストアは、外部ストレージ配列などのブロック デバイス上の、NFS、vSAN、VMFS でサポート可能です。マルチホスト環境では、各ブロック デバイスを環境内のすべてのホストに接続し、データストアは Mount Datastore on Additional Hosts のオプション経由の各ホスト上で構成される必要があります。

StorageClass

PersistentVolumeClaim を作成するときに、ストレージをプロビジョニングする方法に関する情報を提供する StorageClass を指定できます。StorageClass を指定しない場合は、デフォルトの StorageClass が使用されます。

管理クラスタの StorageClass

管理クラスタには、standard という名前の StorageClass があり、デフォルトの StorageClass として指定されています。standard StorageClass は、vSphere in-tree volume プラグインをプロビジョナーとして一覧表示します。

standard StorageClass を表示するには:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
    standard --output yaml

出力で、standard がデフォルトの StorageClass で、プロビジョナーが vSphere in-tree ボリューム プラグイン kubernetes.io/vsphere-volume であることがわかります。vSphere データストアの名前を確認することもできます。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  ...
  labels:
    bundle.gke.io/component-name: admin-storage-class
  name: standard
...
parameters:
  datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...

ユーザー クラスタの StorageClasses

ユーザー クラスタには、standard という名前の StorageClass と、standard-rwo という名前の別の StorageClass があります。

standard-rwo StorageClass はデフォルトの StorageClass として指定され、vSphere CSI ドライバがプロビジョナーとして一覧表示されます。

standard-rwo StorageClass を表示するには:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
    standard-rwo --output yaml

出力で、standard-rwo がデフォルトの StorageClass で、プロビジョナーが vSphere CSI ドライバ csi.vsphere.vmware.com であることがわかります。vSphere データストアの URL を確認することもできます。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
    ...
  labels:
    bundle.gke.io/component-name: user-vsphere-csi-driver-addon
    ...
  name: standard-rwo
...
parameters:
  datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...

Kubernetes in-tree Volume プラグイン

Kubernetes には複数の in-tree Volume プラグインが用意されています。ただし、これらの in-tree Volume プラグインのほとんど（vSphere in-tree volume プラグインを含む）は非推奨です。詳細については、CSI 移行プロジェクトをご覧ください。

vSphere ストレージ ドライバの CSI 移行

以前は、in-tree vSphere volume プラグインが、ユーザー クラスタのデフォルトの StorageClass のプロビジョナーでした。ただし、in-tree vSphere Volume プラグインは非推奨になり、vSphere CSI ドライバはユーザー クラスタのデフォルトの StorageClass のプロビジョナーになりました。in-tree volume プラグインの代わりに、vSphere CSI ドライバを使用することをおすすめします。

Google Distributed Cloud のバージョン 1.15 以降では、in-tree vSphere Volume プラグインで Kubernetes CSI 移行機能がデフォルトで有効になります。つまり、ワークロードが in-tree vSphere Volume を使用する場合、すべての内部ストレージ オペレーション呼び出しは、vSphere CSI ドライバに自動的にリダイレクトされます。

たとえば、PersistentVolumeClaim で、vSphere in-tree Volume プラグイン kubernetes.io/vsphere-volume をプロビジョナーとして一覧表示した standard StorageClass を指定するとします。その後、その PersistentVolumeClaim を使用するワークロードでは、ストレージ オペレーションの呼び出しが vSphere CSI ドライバ csi.vsphere.vmware.com にリダイレクトされます。

プリフライト チェック

新しいクラスタを作成する、またはクラスタをアップグレードすると、環境が CSI 移行に適していることを確認するプリフライト チェックが行われます。

たとえば、プリフライト チェックでは:

  • vCenter と ESXI のバージョンが適切であることを確認します。
  • in-tree vSphere PersistentVolume がある場合は、vSphere CSI ドライバが有効になっていることを確認します。
  • vSphere StorageClasses には、CSI 移行後に無視される特定のパラメータがないことを確認します。
  • 静的に作成された in-tree PersistentVolumes と CSI 移行に必要な PersistentVolumeClaims のアノテーションを検証します。
  • vSphere CSI ドライバによってプロビジョニングされた CSI ボリュームを使用して、クラスタがワークロードを正常に実行できることを確認します。

詳細については、プリフライト チェックの実行をご覧ください。

既知の問題

vSphere CSI ドライバに関連する既知の問題がいくつかあります。詳細と回避策については、VMWare vSphere CSI Driver 3.0 リリースノートの既知の問題のセクションをご覧ください。

CSI への移行を完了する

1.15 で Kubernetes CSI 移行機能がデフォルトで有効になっているため、in-tree vSphere ボリューム プラグインを基盤とする PersistentVolume は、CSI のみの環境で引き続き機能します。in-tree プラグインのオペレーション呼び出しを CSI プラグインにリダイレクトするだけです。PersistentVolume の仕様は不変であるため、仕様は in-tree Volume プラグインと同じです。

このため、ボリューム拡張やボリューム スナップショット機能などの CSI の完全な機能セットは、このようなボリュームでは使用できません。これらの機能を利用するには、CSI フィールドを使用して Kubernetes リソース仕様を再作成し、ステートフル ワークロードを CSI に完全に移行する必要があります。Google は、アプリケーション ダウンタイムなしでステートフル ワークロードを CSI に移行するための自動ツールを開発しました。これにより、完全な CSI 機能セットを使用できます。

サードパーティ ドライバの使用

vSphere データストア以外のストレージ ボリュームをプロビジョニングする場合は、別のストレージ ドライバを使用するクラスタに新しい StorageClass を作成できます。次に、StorageClass をクラスタのデフォルトとして設定するか、StorageClass を使用するようにワークロードを構成します（StatefulSet の例）。

ストレージ パートナー

多くのストレージ ベンダーと提携して、Google Distributed Cloud でストレージ システムを認定しています。認定ストレージ パートナーの一覧をご覧ください。

ボリュームの拡張

プロビジョニング後に永続ボリュームのサイズを拡張するには、PersistentVolumeClaim の容量リクエストを編集します。ボリュームが Pod で使用されている間はオンラインで拡張することも、ボリュームが使用されていないときにオフライン拡張を行うこともできます。

vSphere CSI ドライバの場合、オフライン拡張は vSphere バージョン 7.0 以降で利用でき、オンライン拡張は vSphere バージョン 7.0 Update 2 以上で使用できます。

standard-rwo StorageClass は、vSphere 7.0 以降で実行されている新しく作成されたクラスタに対して、デフォルトで allowVolumeExpansion を true に設定します。この StorageClass を使用すると、ボリュームにオンラインとオフラインの両方の拡張を使用できます。アップグレードされたクラスタでは、クラスタのアップグレード時に StorageClasses が変更されないため、クラスタが 1.7 から 1.8 にアップグレードされても、standard-rwo の allowVolumeExpansion の設定が未設定のままとなり、ボリュームの拡張が許可されません。

ボリューム拡張の詳細については、ボリューム拡張の使用をご覧ください。

CSI ボリューム スナップショット

永続ストレージのスナップショットは、VolumeSnapshot リソースと VolumeSnapshotClass リソースを使用して作成できます。CSI ボリュームでこの機能を使用するには、CSI ドライバがボリューム スナップショットをサポートして、external-snapshotter サイドカー コンテナが CSI ドライバのデプロイメントに含まれている必要があります。

ボリューム スナップショットの詳細については、ボリューム スナップショットの使用をご覧ください。

クラスタを作成すると、CSI スナップショット コントローラが自動的にデプロイされます。

ボリュームのクリーンアップ

ユーザー クラスタを削除しても、vSphere CSI ドライバによってプロビジョニングされたボリュームは削除されません。クラスタを削除する前に、すべてのボリューム、PersistentVolumeClaims、StatefulSet を削除する必要があります。

トラブルシューティング

ストレージのトラブル シューティングをご覧ください。

関連情報