マルチテナント・ベスト・プラクティス

Kubernetes Engine (OKE)の使用時にテナント間で1つ以上のクラスタを共有するためのベスト・プラクティスをご覧ください。

この項では、マルチテナンシおよびKubernetesエンジンのベスト・プラクティスについて説明します。

Kubernetes Engineでは、マルチテナンシはテナント間の1つ以上のクラスタの共有に指定された名前です。テナントは、ワークロード、複数の関連するワークロード、またはそれらのワークロードを担当するチームです。同じクラスタにすべてアクセスする異なる信頼レベルの複数のテナント、チームまたはユーザーが存在する場合は、別々のクラスタを使用することをお薦めします。

ベスト・プラクティス: 追加のファイングレイン・アクセスにRBAC認可プロバイダを使用

Kubernetes RBAC Authorizerを使用して、Kubernetes RBACロールやclusterroleを介して、特定のクラスタのユーザーに対してファイングレイン・アクセス制御を実施することをお薦めします。

Kubernetes RBACロールは権限のコレクションです。たとえば、ロールにはポッドの読取り権限やポッドのリスト権限が含まれる場合があります。Kubernetes RBAC clusterroleはロールと似ていますが、クラスタ内のどこでも使用できます。Kubernetes RBACロールバインディングは、ロールをユーザーまたはグループにマップし、そのネームスペース内のリソースのユーザーまたはグループにそのロールの権限を付与します。同様に、Kubernetes RBAC clusterrolebindingは、clusterroleをユーザーまたはグループにマップし、そのclusterroleの権限をクラスタ全体のユーザーまたはグループに付与します。

アクセス制御およびKubernetesエンジン(OKE)についてを参照してください。

ベスト・プラクティス: 複数のクラスタがオプションでない場合はネームスペースを使用します。

Kubernetesクラスタが大きく(数百のノードを持つ)場合、クラスタで複数のチームが作業している場合は、チームごとに個別のネームスペースを作成することをお薦めします。たとえば、通常、開発チーム、テスト・チームおよび本番チーム用に異なるネームスペースを作成します。

Kubernetesクラスタは、ネームスペースに編成して、クラスタのリソースを複数のユーザーに分割できます。最初、クラスタには次のネームスペースがあります:

デフォルト(他のネームスペースがないリソースの場合)
kube-system (Kubernetesシステムによって作成されたリソース)
kube-node-lease (ノード可用性の決定に役立てるための、ノードごとに1つのリース・オブジェクトの場合)
kube-public (通常、クラスタ全体でアクセスできる必要があるリソースに使用される)

ネームスペースは、複数のユーザーとチームが同じクラスタで作業している場合にクラスタをセキュアに保つ上で重要な役割を果たします。

Kubernetesドキュメントの「ネームスペース」を参照してください。

ベスト・プラクティス: ネームスペースの命名規則を使用して、複数の環境へのデプロイを容易にします。

複数の環境にまたがって異なるクラスタでホストされるデプロイメントを簡単に作成できるように、ネームスペースの命名規則を作成して使用することをお薦めします。

たとえば、ネームスペース名に環境名を含めることは避けてください。かわりに、すべての環境で同じネームスペース名を使用してください。同じネームスペース名を使用することで、すべての環境で同じ構成ファイルを使用でき、各環境に固有の構成ファイルを作成する必要がなくなります。

Kubernetesドキュメントの「ネームスペース」を参照してください。

ベスト・プラクティス: 専用ノード・プール内のワークロードの分離

専用ノード・プールを使用してテナントを分離することで、強力なインフラストラクチャ分離を実装することをお薦めします。たとえば、ノード・プールで区切られた専用コンピュート・リソース上で各テナントを実行するマルチテナント・アプリケーションの場合です。

多くのマルチテナントSaaSアプリケーションでは、テナントは専用コンピュート・リソースで実行する必要があり、テナント当たりのセキュリティ・リストを介してネットワーク・トラフィックを制御する機能が必要です。このようなSaaSアプリケーション・テナンシ・モデルで最も一般的な2つの方法は次のとおりです。

ネームスペースとネットワーク・ポリシーを利用してテナントを分離します。
専用のコンピュート/セキュリティ・リストを利用して、テナントを分離します。

ベスト・プラクティス: リソース割当ての強制

クラスタを共有するすべてのテナントがクラスタ・リソースに公平にアクセスできるように、Kubernetesリソース割当てを作成して強制することをお薦めします。

各テナントによってデプロイされたポッドの数、および各ポッドに必要なメモリーおよびCPUの量に基づいて、ネームスペースごとにリソース割当てを作成します。

たとえば、次のResourceQuota構成です。

tenant-aネームスペース内のポッドが最大16個のCPUおよび最大64 GBのメモリーをリクエストできるようにします
CPUの最大数を32に制限し、最大メモリーを72 GBに制限します。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Kubernetesドキュメントのリソース割当てを参照してください。

ベスト・プラクティス: ワーカー・ノードとポッドの自動スケーリング

クラスタ内のノード・プールおよびポッドを自動的にスケーリングして、テナントの需要に対応するように自動スケーリングを有効にすることをお薦めします。

自動スケーリングにより、異なるテナントが独自のネームスペースに大量のワークロードをデプロイしても、システムが応答性と健全性を維持します。自動スケーリングも、システムが停止に対応するのに役立ちます。

Kubernetes Cluster Autoscalerの使用、Kubernetes Horizontal Pod Autoscalerの使用を参照してください。

ベスト・プラクティス: フレキシブル・ロード・バランサの使用

テナントの需要に対応するために、Oracle Cloud Infrastructureロード・バランサにフレキシブル・シェイプを指定することをお薦めします。

Kubernetes EngineがタイプLoadBalancerのKubernetesサービスにプロビジョニングするOCIロード・バランサにフレキシブル・シェイプを使用すると、次のことができます。

最小値と最大値を指定してロード・バランサの帯域幅シェイプの上限と下限のサイズ範囲を作成できるため、固定帯域幅ロード・バランサ・シェイプに関連する制限を回避します。
一般的なトラフィック・パターンのみに基づくスケーリングに関連する制限を回避します。

フレキシブルLoad Balancerシェイプの指定を参照してください。

ベスト・プラクティス: ネットワーク制御の一元化(オプション)

動的ルーティング・ゲートウェイ(DRG)および(オプションで)ハブVCNを使用して、ネットワーク・リソースを集中管理することをお薦めします。

DRGを使用すると、一元化されたネットワーク仮想アプライアンスを介してトラフィックをルーティングできます。

オプションでハブVCNを作成すると、メイン・ルーティングおよびファイアウォールを構成できます。ハブVCN内のリソースは、内部IPを使用して他のVCNと安全かつ効率的に通信できます。ハブVCNおよびIAMを使用すると、集中管理されたVCNにアクセスできるのはネットワーク管理者のみです。この分離は、最小特権の原則を実装するのに役立ちます。

例:

集中管理されたネットワーク・チームは、Kubernetesクラスタ(スポークVCNに存在する)にアクセスする権限を持たずにネットワークを管理できます。
Kubernetes Engine管理者は、共有ネットワークを操作する権限を持たずにクラスタを管理できます。

中央ネットワーク仮想アプライアンスを介したトラフィックのルーティングを参照してください。

Oracle Cloud Infrastructureドキュメント