Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ボリュームアクセスグループ

共同作成者 netapp-aruldeepa

Tridentがどのように活用されているかについて詳しくは "ボリュームアクセスグループ"

メモ CHAP を使用している場合は、管理を簡素化し、以下で説明するスケーリング制限を回避するためにこのセクションを無視することをお勧めします。なお、 Trident をCSI モードで使用している場合は、このセクションは無視できます。 Trident は、拡張 CSI プロビジョナーとしてインストールされる場合、CHAP を使用します。

ボリュームアクセスグループについて学ぶ

Trident はボリューム アクセス グループを使用して、プロビジョニングするボリュームへのアクセスを制御できます。 CHAPが無効になっている場合は、次のアクセスグループが見つかると予想されます。 `trident`構成で 1 つ以上のアクセス グループ ID を指定しない限り、これは実行されません。

Trident は新しいボリュームを構成されたアクセス グループに関連付けますが、アクセス グループ自体は作成したり管理したりしません。アクセス グループは、ストレージ バックエンドがTridentに追加される前に存在している必要があり、そのバックエンドによってプロビジョニングされたボリュームをマウントする可能性のある Kubernetes クラスター内のすべてのノードからの iSCSI IQN が含まれている必要があります。ほとんどのインストールでは、クラスター内のすべてのワーカーノードが含まれます。

64 を超えるノードを持つ Kubernetes クラスターの場合は、複数のアクセス グループを使用する必要があります。各アクセス グループには最大 64 個の IQN を含めることができ、各ボリュームは 4 つのアクセス グループに属することができます。最大 4 つのアクセス グループを構成すると、最大 256 ノードのクラスター内の任意のノードが任意のボリュームにアクセスできるようになります。ボリュームアクセスグループの最新の制限については、以下を参照してください。 "ここをクリックしてください。"

デフォルトを使用している構成から変更する場合 `trident`アクセスグループを他のグループも使用するグループに変更する場合は、 `trident`リスト内のアクセス グループ。