Freigeben über


Best Practices für Clusterisolierung in Azure Kubernetes Service (AKS)

Beim Verwalten von Clustern in Azure Kubernetes Service (AKS) müssen Sie oft Teams oder Workloads isolieren. AKS ermöglicht Flexibilität beim Ausführen von mehrinstanzenfähigen Clustern und Isolieren von Ressourcen. Um den Nutzen Ihrer Investition in Kubernetes zu maximieren, ist es wichtig, dass Sie die AKS-Funktionen für Mehrinstanzenfähigkeit und Isolation verstehen.

Dieser Best Practices-Artikel konzentriert sich auf die Isolierung für Clusteroperator. In diesem Artikel werden folgende Vorgehensweisen behandelt:

  • Planen für mehrinstanzenfähige Cluster und Trennung von Ressourcen
  • Verwenden der logischen oder physischen Isolierung in Ihren AKS-Clustern

Entwerfen von Clustern für die Mehrinstanzenfähigkeit

Mit Kubernetes können Sie Teams und Workloads im selben Cluster logisch isolieren. Das Ziel ist, die geringste Anzahl von Berechtigungen bereitzustellen, die auf die von den einzelnen Teams benötigten Ressourcen beschränkt sind. Ein Kubernetes-Namespace erstellt eine logische Isolationsgrenze. Weitere Kubernetes-Funktionen und Überlegungen zu Isolierung und Mehrinstanzenfähigkeit umfassen die folgenden Bereiche:

Scheduling

Bei der Planung werden grundlegende Funktionen wie Ressourcenkontingente und Budgets für die Unterbrechung von Pods verwendet. Weitere Informationen zu diesen Features finden Sie unter Best Practices für grundlegende Schedulerfunktionen in Azure Kubernetes Service (AKS).

Zu den erweiterten Schedulerfunktionen gehören:

  • Taints und Toleranzen
  • Knotenselektoren
  • Knoten- und Podaffinität oder Antiaffinität

Weitere Informationen zu diesen Features finden Sie unter Best Practices für erweiterte Schedulerfunktionen in Azure Kubernetes Service (AKS).

Netzwerk

Für das Netzwerk werden Netzwerkrichtlinien verwendet, um den ein- und ausgehenden Datenverkehr des Pods zu steuern.

Weitere Informationen finden Sie unter Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service (AKS).

Authentifizierung und Autorisierung

Zur Authentifizierung und Autorisierung wird Folgendes verwendet:

  • Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC)
  • Microsoft Entra-Integration.
  • Podidentitäten
  • Geheimnisse in Azure Key Vault

Weitere Informationen zu diesen Features finden Sie unter Best Practices für die Authentifizierung und Autorisierung in Azure Kubernetes Service (AKS).

Container

Container umfassen Folgendes:

  • Azure Policy-Add-On für AKS zum Erzwingen der Podsicherheit
  • Pod Security Admission
  • Überprüfung von Images und Runtime auf Sicherheitsrisiken
  • Verwendung von App Armor oder Seccomp (Secure Computing, sicheres Computing) zum Einschränken des Containerzugriffs auf den zugrunde liegenden Knoten

Logisch isolierte Cluster

Best Practices-Leitfaden

Trennen Sie Teams und Projekte mithilfe einer logischen Isolation. Minimieren Sie die Anzahl der physischen AKS-Cluster, die Sie bereitstellen, um Teams oder Anwendungen zu isolieren.

Mit logischer Isolierung können Sie einen einzelnen AKS-Cluster für mehrere Workloads, Teams oder Umgebungen verwenden. Kubernetes-Namespaces bilden die logische Isolationsgrenze für Workloads und Ressourcen.

Logische Isolierung eines Kubernetes-Clusters in AKS

Die logische Trennung von Clustern bietet in der Regel eine höhere Poddichte als physisch isolierte Cluster, wodurch weniger überschüssige Computekapazität im Cluster ungenutzt bleibt. In Kombination mit der automatischen Clusterskalierung in Kubernetes können Sie die Anzahl von Knoten gemäß der Anforderungen nach oben oder unten skalieren. Dieser Best Practice-Ansatz minimiert die Kosten, da nur die erforderliche Anzahl von Knoten ausgeführt wird.

Kubernetes-Umgebungen sind nicht völlig sicher vor einer feindlichen Verwendung mit mehreren Mandanten. In einer Umgebung mit mehreren Mandanten arbeiten mehrere Mandanten in einer freigegebenen Infrastruktur. Wenn alle Mandanten nicht vertrauenswürdig sind, benötigen Sie eine zusätzliche Planung, um zu verhindern, dass Mandanten die Sicherheit und den Dienst anderer beeinträchtigen.

Mithilfe weiterer Sicherheitsfeatures wie Kubernetes RBAC für Knoten können Exploits effizient blockiert werden. Um echte Sicherheit bei der Ausführung feindlicher Workloads mit mehreren Mandanten zu erzielen, sollten Sie nur einem Hypervisor vertrauen. Die Sicherheitsdomäne für Kubernetes wird zum gesamten Cluster und nicht zu einem einzelnen Knoten.

Für diese Art von feindlichen Workloads mit mehreren Mandanten sollten Sie physisch isolierte Cluster verwenden.

Physisch isolierte Cluster

Best Practices-Leitfaden

Minimieren Sie die Verwendung der physischen Isolierung für jedes einzelne Team oder jede einzelne Anwendungsbereitstellung, und verwenden Sie stattdessen die logische Isolierung.

Die physische Trennung von AKS-Clustern ist eine gängige Methode der Clusterisolation. In diesem Isolationsmodell werden Teams oder Workloads ihre eigenen AKS-Cluster zugewiesen. Obwohl die physische Isolation als die einfachste Möglichkeit zum Isolieren von Workloads oder Teams erscheint, erhöht sie den Verwaltungs- und Finanzaufwand. Bei physisch isolierten Clustern müssen Sie mehrere Cluster verwalten und einzeln den Zugriff gewähren und Berechtigungen zuweisen. Ihnen wird außerdem jeder einzelne Knoten in Rechnung gestellt.

Physische Isolierung einzelner Kubernetes-Cluster in AKS

Physisch isolierte Cluster verfügen in der Regel über eine geringe Poddichte. Da jedes Team oder jede Workload einen eigenen AKS-Cluster hat, wird dem Cluster häufig ein Übermaß an Computeressourcen bereitgestellt. Häufig sind einige Pods auf diesen Knoten eingeplant. Nicht beanspruchte Knotenkapazität kann nicht für Anwendungen oder Dienste verwendet werden, die von anderen Teams entwickelt werden. Diese überschüssigen Ressourcen tragen zu den zusätzlichen Kosten in physisch isolierten Clustern bei.

Nächste Schritte

Dieser Artikel konzentriert sich auf Clusterisolierung. Weitere Informationen zu Clustervorgängen in AKS finden Sie in den folgenden Artikeln zu Best Practices: