Azure Kubernetes Services (AKS) でのクラスターの分離に関するベスト プラクティス

Azure Kubernetes Service (AKS) でクラスターを管理する際は、多くの場合、チームとワークロードを分離する必要があります。 AKS では、柔軟にマルチテナント クラスターを実行してリソースを分離することができます。 Kubernetes への投資を最大限に活用するには、AKS のマルチテナントおよび分離機能を理解することが重要です。

このベスト プラクティスの記事では、クラスター オペレーターを対象とした分離に重点を置いています。 この記事では、次のことについて説明します。

  • マルチテナント クラスターとリソースの分離を計画します。
  • AKS クラスターで論理的または物理的な分離を使用します。

マルチ テナント用にクラスターを設計する

Kubernetes では、同じクラスター内のチームとワークロードを論理的に分離できます。 目標は、各チームが必要とするリソースに限定して、最小限の数の特権を提供することです。 Kubernetes の名前空間では、論理的な分離境界が作成されます。 その他の Kubernetes の機能および分離とマルチテナントに関する考慮事項には、次の領域が含まれます。

スケジュール設定

"スケジュール設定" では、リソース クォータやポッドの中断バジェットなどの基本的な機能を使用します。 これらの機能の詳細については、AKS の基本的なスケジューラ機能のベスト プラクティスに関するページを参照してください。

より高度なスケジューラ機能は次のとおりです。

  • テイントと容認。
  • ノード セレクター。
  • ノードとポッドのアフィニティまたは非アフィニティ。

これらの機能の詳細については、AKS の高度なスケジューラ機能のベスト プラクティスに関するページを参照してください。

ネットワーク

"ネットワーク" では、ポッド内外のトラフィックのフローを制御するためのネットワーク ポリシーが使用されます。

認証と権限承認

"認証と認可" では次のものが使用されます。

  • ロール ベースのアクセス制御 (RBAC)。
  • Microsoft Entra 統合。
  • ポッド ID。
  • Azure Key Vault のシークレット。

これらの機能の詳細については、AKS の認証と承認のベスト プラクティスに関するページを参照してください。

Containers

"コンテナー" には次のものが含まれます。

  • ポッド セキュリティを適用するための AKS 用の Azure Policy アドオン。
  • Pod Security Admission。
  • イメージとランタイムの脆弱性のスキャン。
  • 基になるノードへのコンテナー アクセスを制限するための App Armor や Seccomp (セキュア コンピューティング) の使用。

論理的に分離されたクラスター

ベスト プラクティスのガイダンス

"論理的な分離" を使用して、チームとプロジェクトを分離します。 チームまたはアプリケーションを分離するためにデプロイする物理 AKS クラスターの数を最小限にします。

論理的な分離によって、1 つの AKS クラスターを複数のワークロード、チーム、または環境に使用できます。 Kubernetes の名前空間では、ワークロードとリソースの論理的な分離境界を形成します。

Logical isolation of a Kubernetes cluster in AKS

クラスターを論理的に分離すると、通常、物理的に分離されたクラスターよりもポッド密度が高くなり、クラスター内でアイドル状態の過剰なコンピューティング容量が少なくなります。 Kubernetes クラスターの自動スケーラーを組み合わせることで、ノード数をスケール アップまたはスケール ダウンして需要を満たすことできます。 このベスト プラクティスの方法を使用すれば、必要な数のノードのみを実行することでコストが最小限に抑えられます。

Kubernetes 環境は、悪意のあるマルチテナントの使用に対して完全に安全ではありません。 マルチテナント環境では、共有インフラストラクチャ上で複数のテナントが動作します。 すべてのテナントを信頼できない場合は、テナントが他のテナントのセキュリティやサービスに影響を与えることを防ぐために、追加の計画が必要です。

ノード用の Kubernetes RBAC など、その他のセキュリティ機能により、悪用を効率的にブロックします。 悪意のあるマルチテナント ワークロードを実行する場合の真のセキュリティのために、ハイパーバイザーのみを信頼する必要があります。 Kubernetes 用のセキュリティ ドメインはクラスター全体になり、個々のノードにはなりません。

この種の悪意のあるマルチテナント ワークロードでは、物理的に分離されたクラスターを使用する必要があります。

物理的に分離されたクラスター

ベスト プラクティスのガイダンス

個々のチームまたはアプリケーションのデプロイごとの物理的な分離の使用を最小限に抑え、代わりに "論理的な" 分離を使用します。

AKS クラスターを物理的に分離することが、クラスターを分離するための一般的な方法です。 この分離モデルでは、チームまたはワークロードに独自の AKS クラスターが割り当てられます。 物理的な分離は、ワークロードやチームを分離する最も簡単な方法のようですが、管理と財務のオーバーヘッドが増えます。 物理的に分離されたクラスターでは、複数のクラスターを維持し、個別にアクセスを提供してアクセス許可を割り当てる必要があります。 また、個々のノードごとに課金されます。

Physical isolation of individual Kubernetes clusters in AKS

物理的に分離されたクラスターは通常、ポッドの密度が低くなります。 各チームまたはワークロードには独自の AKS クラスターがあるため、クラスターは多くの場合、コンピューティング リソースで過剰にプロビジョニングされます。 多くの場合、ノード上には数個のポッドがスケジュールされます。 ノード上の未使用の容量は、他のチームによって開発中のアプリケーションやサービスで使用することはできません。 これらの過剰なリソースは、物理的に分離されたクラスターで余計なコストの原因になります。

次のステップ

この記事ではクラスターの分離に重点を置きました。 AKS でのクラスター操作の詳細については、次のベスト プラクティス記事を参照してください。