|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
VMware vSphere ストレージ
VMware vSphere ストレージをステートフルワークロードに提供するために、vSphereVolume ストレージクラスを作成することをお勧めします。この手法は、ワークロードが PersistentVolumeClaim を通じてボリュームを要求する際に、vSphere ストレージを動的にプロビジョニングします。
vSphere でストレージを動的にプロビジョニングするためには、vSphere プロバイダーを有効にする必要があります。詳細については、次のページを参照してください: アウトオブツリー vSphere および インツリー vSphere。
前提条件
RKE2 で作成されたクラスターに vSphere ボリュームをプロビジョニングするためには、 vSphere クラウドプロバイダー を クラスターオプション で明示的に有効にする必要があります。
StorageClassの作成
|
次の手順は、 |
-
*☰ > クラスター管理*をクリックします。
-
vSphere ストレージを提供したいクラスターを選択し、探索 をクリックします。
-
左側のナビゲーションバーで、 を選択します。
-
［作成］をクリックします。
-
ストレージクラスの 名称 を入力してください。
-
プロビジョナー の下で、VMWare vSphere ボリューム を選択します。
-
オプションで、このストレージクラスの追加プロパティを パラメーター の下に指定します。詳細については、 vSphere ストレージのドキュメント を参照してください。
-
［作成］をクリックします。
VMware vSphere ボリュームを使用したワークロードの作成
-
左のナビゲーションバーで*ワークロード*をクリックします。
-
［作成］をクリックします。
-
ステートフルセット をクリックします。
-
ボリュームクレームテンプレート タブで、クレームテンプレートを追加 をクリックします。
-
永続ボリューム名を入力してください。
-
ストレージクラスフィールドで、作成した vSphere ストレージクラスを選択します。
-
ボリュームの必要な 容量 を入力してください。次に、*定義*をクリックします。
-
*マウントポイント*フィールドにパスを割り当てます。これは、ボリュームがコンテナファイルシステムにマウントされる完全なパスです。例：
/persistent。 -
［作成］をクリックします。
ボリュームの永続性を確認する
-
左のナビゲーションバーでをクリックします。
-
作成したワークロードに移動し、*⋮ > シェルを実行*をクリックします。
-
ボリュームがマウントされているルートのディレクトリをメモしてください（この場合は`/persistent`）。
-
コマンド`touch /<volumeMountPoint>/data.txt`を実行してボリューム内にファイルを作成します。
-
シェルウィンドウを閉じます。
-
ワークロードの名前をクリックして詳細情報を表示します。
-
*⋮ > 削除*をクリックします。
-
ポッドが削除されることを確認します。その後、新しいポッドがスケジュールされて、ワークロードが構成されたスケールの単一のステートフルポッドを維持します。
-
置き換えポッドが実行中になったら、*シェルを実行*をクリックします。
-
`ls -l /<volumeMountPoint>`を入力して、ボリュームがマウントされているディレクトリの内容を確認します。以前に作成したファイルがまだ存在することに注意してください。
なぜデプロイメントの代わりにステートフルセットを使用するのか
vSphereストレージを消費するワークロードには、常に ステートフルセットを使用すべきです。このリソースタイプは、VMDKブロックストレージの注意点に対処するために設計されています。
vSphereボリュームはVMDKブロックストレージによってバックアップされているため、 アクセスモードは`ReadWriteOnce`のみをサポートします。この設定により、ボリュームは同時に単一のポッドにのみマウントできるよう制限されます。ただし、そのボリュームを利用するすべてのポッドが同じノード上に配置されている場合は例外となります。この動作は、vSphereボリュームを消費する場合、デプロイメントリソースが単一のレプリカを超えてスケーリングできなくなることを意味します。
単一のレプリカのみのデプロイメントリソースを使用しても、デプロイメントの更新中にデッドロック状態が発生する可能性があります。更新されたポッドが既存のポッドが存在するノードとは異なるノードにスケジュールされると、VMDKが他のノードにまだアタッチされているため、起動に失敗します。