アーキテクチャ
変更を提案
PDF
NetApp ONTAPに裏打ちされた Red Hat OpenShift とTridentは、デフォルトではワークロード間の分離を提供しませんが、マルチテナンシーを構成するために使用できる幅広い機能を提供します。 NetApp ONTAPに裏打ちされたTridentを使用した Red Hat OpenShift クラスターでのマルチテナント ソリューションの設計をより深く理解するために、一連の要件を含む例を検討し、その構成の概要を説明します。
ある組織が、2 つの異なるチームが取り組んでいる 2 つのプロジェクトの一環として、Red Hat OpenShift クラスター上で 2 つのワークロードを実行しているとします。これらのワークロードのデータは、 NetApp ONTAP NAS バックエンドでTridentによって動的にプロビジョニングされる PVC 上に存在します。組織では、これら 2 つのワークロード用のマルチテナント ソリューションを設計し、これらのプロジェクトに使用されるリソースを分離して、主にこれらのアプリケーションに役立つデータに重点を置き、セキュリティとパフォーマンスが維持されるようにする必要があります。
次の図は、 NetApp ONTAPを搭載したTridentを搭載した Red Hat OpenShift クラスター上のマルチテナント ソリューションを示しています。
技術要件
-
NetApp ONTAPストレージ クラスタ
-
Red Hat OpenShift クラスター
-
Trident
Red Hat OpenShift – クラスターリソース
Red Hat OpenShift クラスターの観点から見ると、最初に開始する最上位のリソースはプロジェクトです。 OpenShift プロジェクトは、OpenShift クラスター全体を複数の仮想クラスターに分割するクラスター リソースとして考えることができます。したがって、プロジェクト レベルでの分離は、マルチテナントを構成するための基盤となります。
次は、クラスタ内でRBACを設定することです。ベストプラクティスとしては、単一のプロジェクトまたはワークロードに取り組むすべての開発者を、IDプロバイダー（IdP）内の単一のユーザーグループに構成することです。Red Hat OpenShiftはIdP統合とユーザーグループの同期をサポートしており、IdPのユーザーとグループをクラスターにインポートできます。これにより、クラスター管理者は、プロジェクト専用のクラスターリソースへのアクセスを、そのプロジェクトに取り組むユーザーグループまたは複数のユーザーグループに分離することができ、クラスターリソースへの不正アクセスを制限できます。Red Hat OpenShiftとのIdP統合の詳細については、"IDプロバイダーについて"を参照してください。
NetApp ONTAP
Red Hat OpenShift クラスターの永続ストレージプロバイダーとして機能する共有ストレージを分離して、各プロジェクトのストレージ上に作成されたボリュームが、ホストに対して個別のストレージ上に作成されたかのように見えるようにすることが重要です。これを行うには、 NetApp ONTAP上にプロジェクトまたはワークロードと同じ数の SVM (ストレージ仮想マシン) を作成し、各 SVM をワークロード専用にします。
Trident
異なるプロジェクト用に異なる SVM が NetApp ONTAP 上に作成されたら、各 SVM を異なる Trident バックエンドにマッピングする必要があります。Trident のバックエンド構成は、OpenShift クラスタリソースへの永続ストレージの割り当てを制御するものであり、マッピング先の SVM の詳細が必要です。最低限、バックエンドのプロトコルドライバを指定する必要があります。オプションとして、ストレージ上でボリュームがどのようにプロビジョニングされるかを定義したり、ボリュームのサイズやアグリゲートの使用量などの制限を設定したりすることができます。Trident バックエンドの定義に関する詳細は、"バックエンドを設定" を参照してください。
Red Hat OpenShift – ストレージリソース
Trident バックエンドを設定したら、次のステップは StorageClasses の設定です。バックエンドと同じ数だけストレージクラスを設定し、各ストレージクラスが1つのバックエンド上でのみボリュームを起動できるようにアクセスを制限します。ストレージクラスを定義する際に storagePools パラメータを使用することで、StorageClass を特定の Trident バックエンドにマッピングできます。ストレージクラスを定義するための詳細については、"ストレージクラスを作成する"を参照してください。これにより、StorageClass から Trident バックエンドへの1対1のマッピングが確立され、それが1つの SVM を指すようになります。これにより、そのプロジェクトに割り当てられた StorageClass を介したすべてのストレージ要求が、そのプロジェクト専用の SVM のみから提供されるようになります。
ストレージクラスは名前空間リソースではないため、別の名前空間またはプロジェクトのポッドが、あるプロジェクトのストレージクラスに対してストレージ要求を行った場合に、その要求が拒否されるようにするにはどうすればよいでしょうか？答えは ResourceQuotas を使用することです。ResourceQuotas は、プロジェクトごとのリソースの総使用量を制御するオブジェクトです。これにより、プロジェクト内のオブジェクトが消費できるリソースの数と総量を制限できます。プロジェクトのほぼすべてのリソースは ResourceQuotas を使用して制限でき、これを効率的に活用することで、組織はリソースの過剰供給や過剰消費によるコストや障害を削減できます。詳細については、"プロジェクトごとにリソース割り当てを設定する" を参照してください。
このユースケースでは、特定のプロジェクト内のポッドが、そのプロジェクト専用ではないストレージ クラスからストレージを要求することを制限する必要があります。そのためには、他のストレージクラスの永続ボリュームの要求を制限する必要があります。 <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims 0 にします。さらに、クラスター管理者は、プロジェクト内の開発者が ResourceQuotas を変更するアクセス権を持たないようにする必要があります。