Azure Kubernetes Services (AKS) でのクラスターの分離に関するベスト プラクティスBest practices for cluster isolation in Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) でクラスターを管理する際は、多くの場合、チームとワークロードを分離する必要があります。As you manage clusters in Azure Kubernetes Service (AKS), you often need to isolate teams and workloads. AKS では、柔軟にマルチ テナント クラスターを実行してリソースを分離することができます。AKS provides flexibility in how you can run multi-tenant clusters and isolate resources. Kubernetes への投資を最大限に活用するには、これらのマルチ テナントおよび分離機能を理解して実装する必要があります。To maximize your investment in Kubernetes, these multi-tenancy and isolation features should be understood and implemented.

このベスト プラクティスの記事では、クラスター オペレーターを対象とした分離に重点を置いています。This best practices article focuses on isolation for cluster operators. この記事では、次のことについて説明します。In this article, you learn how to:

  • マルチ テナント クラスターとリソースの分離の計画Plan for multi-tenant clusters and separation of resources
  • AKS クラスターでの論理的または物理的な分離の使用Use logical or physical isolation in your AKS clusters

マルチ テナント用にクラスターを設計するDesign clusters for multi-tenancy

Kubernetes では、同じクラスター内のチームとワークロードを論理的に分離できる機能が提供されます。Kubernetes provides features that let you logically isolate teams and workloads in the same cluster. 各チームで必要なリソースをスコープとする、最小限の数の特権を提供することを目標にする必要があります。The goal should be to provide the least number of privileges, scoped to the resources each team needs. Kubernetes の名前空間では、論理的な分離境界が作成されます。A Namespace in Kubernetes creates a logical isolation boundary. その他の Kubernetes の機能および分離とマルチテナントに関する考慮事項には、次の領域が含まれます。Additional kubernetes features and considerations for isolation and multi-tenancy include the following areas:

  • スケジューリングには、リソース クォータやポッドの中断バジェットなどの基本的な機能の使用が含まれます。Scheduling includes the use of basic features such as resource quotas and pod disruption budgets. これらの機能の詳細については、AKS の基本的なスケジューラ機能のベスト プラクティスに関するページを参照してください。For more information about these features, see Best practices for basic scheduler features in AKS.
  • ネットワークには、ポッド内外のトラフィックのフローを制御するためのネットワーク ポリシーの使用が含まれます。Networking includes the use of network policies to control the flow of traffic in and out of pods.
  • 認証と承認には、ロールベースのアクセス制御 (RBAC) と Azure Active Directory (AD) の統合、ポッド ID、および Azure Key Vault のシークレットの使用が含まれます。Authentication and authorization include the user of role-based access control (RBAC) and Azure Active Directory (AD) integration, pod identities, and secrets in Azure Key Vault. これらの機能の詳細については、AKS の認証と承認のベスト プラクティスに関するページを参照してください。For more information about these features, see Best practices for authentication and authorization in AKS.
  • コンテナーには、ポッドのセキュリティ ポリシー、ポッドのセキュリティ コンテキスト、脆弱性に関するイメージとランタイムのスキャンが含まれます。Containers include pod security policies, pod security contexts, scanning images and runtimes for vulnerabilities. また、基になるノードへのコンテナー アクセスを制限するための App Armor や Seccomp (セキュア コンピューティング) の使用も含まれます。Also involves using App Armor or Seccomp (Secure Computing) to restrict container access to the underlying node.

クラスターを論理的に分離するLogically isolate clusters

ベスト プラクティス ガイダンス - 論理的な分離を使用して、チームとプロジェクトを分離します。Best practice guidance - Use logical isolation to separate teams and projects. チームまたはアプリケーションを分離するためにデプロイする物理 AKS クラスターの数を最小限にしてみます。Try to minimize the number of physical AKS clusters you deploy to isolate teams or applications.

論理的な分離では、1 つの AKS クラスターを、複数のワークロード、チーム、環境で使用できます。With logical isolation, a single AKS cluster can be used for multiple workloads, teams, or environments. Kubernetes の名前空間では、ワークロードとリソースの論理的な分離境界を形成します。Kubernetes Namespaces form the logical isolation boundary for workloads and resources.

AKS での Kubernetes クラスターの論理的な分離

クラスターの論理的な分離では、通常、物理的に分離されたクラスターよりも高いポッド密度が提供されます。Logical separation of clusters usually provides a higher pod density than physically isolated clusters. クラスターでアイドル状態の過剰なコンピューティング容量が少なくなります。There's less excess compute capacity that sits idle in the cluster. Kubernetes クラスターの自動スケーラーを組み合わせることで、ノード数をスケール アップまたはスケール ダウンして需要を満たすことできます。When combined with the Kubernetes cluster autoscaler, you can scale the number of nodes up or down to meet demands. 自動スケールのためのこのベスト プラクティスの方法を使用すれば、必要な数のノードのみを実行でき、コストが最小限に抑えられます。This best practice approach to autoscaling lets you run only the number of nodes required and minimizes costs.

AKS などでは、Kubernetes 環境は、悪意のあるマルチテナント使用に対しては完全に安全ではありません。Kubernetes environments, in AKS or elsewhere, aren't completely safe for hostile multi-tenant usage. ノードに対して Pod Security Policy やより高度なロール ベースのアクセス制御 (RBAC) などの追加のセキュリティ機能を使用すると、セキュリティ上の弱点を悪用されにくくなります。Additional security features such as Pod Security Policy and more fine-grained role-based access controls (RBAC) for nodes make exploits more difficult. ただし、悪意のあるマルチテナント ワークロードの実行に対して真のセキュリティを実現するために信頼できる唯一のセキュリティ レベルはハイパーバイザーです。However, for true security when running hostile multi-tenant workloads, a hypervisor is the only level of security that you should trust. Kubernetes 用のセキュリティ ドメインは、個々のノードではなく、クラスター全体になります。The security domain for Kubernetes becomes the entire cluster, not an individual node. この種の悪意のあるマルチテナント ワークロードでは、物理的に分離されたクラスターを使用する必要があります。For these types of hostile multi-tenant workloads, you should use physically isolated clusters.

クラスターを物理的に分離するPhysically isolate clusters

ベスト プラクティス ガイダンス - 個々のチームまたはアプリケーションのデプロイごとの物理的な分離の使用を最小限に抑えます。Best practice guidance - Minimize the use of physical isolation for each separate team or application deployment. 代わりに、前のセクションで説明したように、論理的な 分離を使用します。Instead, use logical isolation, as discussed in the previous section.

クラスターを分離するための一般的な方法は、個々の AKS クラスターを物理的に使用することです。A common approach to cluster isolation is to use physically separate AKS clusters. この分離モデルでは、チームまたはワークロードに独自の AKS クラスターが割り当てられます。In this isolation model, teams or workloads are assigned their own AKS cluster. この方法は、多くの場合、ワークロードやチームを分離する最も簡単な方法のようですが、管理および財務のオーバーヘッドがさらに増えます。This approach often looks like the easiest way to isolate workloads or teams, but adds additional management and financial overhead. ここでこれらの複数のクラスターを維持し、個別にアクセスを提供してアクセス許可を割り当てる必要があります。You now have to maintain these multiple clusters, and have to individually provide access and assign permissions. また、個々のすべてのノードについて課金されます。You're also billed for all the individual nodes.

AKS での個々の Kubernetes クラスターの物理的な分離

物理的に分離されたクラスターのポッドの密度は通常、低くなります。Physically separate clusters usually have a low pod density. 各チームまたはワークロードには独自の AKS クラスターがあるため、クラスターは多くの場合、コンピューティング リソースで過剰にプロビジョニングされます。As each team or workload has their own AKS cluster, the cluster is often over-provisioned with compute resources. 多くの場合、ノード上には少数のポッドがスケジュールされます。Often, a small number of pods is scheduled on those nodes. ノード上の未使用の容量は、他のチームによって開発中のアプリケーションやサービスで使用することはできません。Unused capacity on the nodes can't be used for applications or services in development by other teams. これらの過剰なリソースは、物理的に分離されたクラスターでの追加コストの原因となります。These excess resources contribute to the additional costs in physically separate clusters.

次の手順Next steps

この記事ではクラスターの分離に重点を置きました。This article focused on cluster isolation. AKS でのクラスター操作の詳細については、次のベスト プラクティスを参照してください。For more information about cluster operations in AKS, see the following best practices: