Cluster-Mehrinstanzenfähigkeit

Auf dieser Seite wird die Cluster-Mehrmandantenfähigkeit in Google Kubernetes Engine (GKE) erläutert. Hierzu zählen Cluster, die innerhalb einer Organisation für mehrere Nutzer freigegeben sind, sowie Cluster, die von den pro Kunde verwendeten Instanzen einer Software-as-a-Service-Anwendung (SaaS) gemeinsam genutzt werden. Statt zahlreiche Cluster mit je einem Mandanten zu verwalten, können Sie mehrmandantenfähige Cluster verwenden.

Außerdem finden Sie auf dieser Seite eine Zusammenfassung der Kubernetes- und GKE-Funktionen für die Verwaltung von mehrmandantenfähigen Clustern.

Was ist Mehrmandantenfähigkeit?

Ein mehrmandantenfähiger Cluster wird von mehreren Nutzern und/oder Arbeitslasten gemeinsam genutzt. Diese werden als "Mandanten" bezeichnet. Zur Eindämmung der infolge eines gehackten oder böswilligen Mandanten möglichen Schäden müssen Betreiber mehrmandantenfähiger Cluster Mandanten voneinander isolieren. Wichtig ist auch eine angemessene Aufteilung der Clusterressourcen zwischen Mandanten.

Wenn Sie eine mehrmandantenfähige Architektur planen, sollten Sie die in Kubernetes vorhandenen Ebenen der Ressourcenisolation berücksichtigen: Cluster, Namespace, Knoten, Pod und Container. Erwägen Sie außerdem, wie sich die Freigabe verschiedener Ressourcentypen für Mandanten auf die Sicherheit auswirkt. Durch eine entsprechende Planung der Pods verschiedener Mandanten auf demselben Knoten kann sich beispielsweise die Anzahl der im Cluster benötigten Maschinen reduzieren. Andererseits müssen Sie möglicherweise verhindern, dass bestimmte Arbeitslasten am selben Ort verarbeitet werden. Es wird beispielsweise davon abgeraten, nicht vertrauenswürdigen Code von außerhalb Ihrer Organisation auf demselben Knoten wie Container auszuführen, in denen vertrauliche Informationen verarbeitet werden.

Obwohl in Kubernetes keine absolut sichere Isolation zwischen Mandanten sichergestellt werden kann, reichen die darin verfügbaren Funktionen gegebenenfalls aus, um bestimmte Anwendungsfälle abzudecken. Sie können jeden Mandanten und die zugehörigen Kubernetes-Ressourcen in separate Namespaces aufteilen. Anschließend haben Sie die Möglichkeit, die Isolation der Mandanten mit Richtlinien zu erzwingen. Richtlinien beziehen sich normalerweise auf den jeweiligen Namespace. Sie können damit den API-Zugriff, die Ressourcennutzung und die Berechtigungen von Containern einschränken.

Die Mandanten eines mehrmandantenfähigen Clusters nutzen Folgendes gemeinsam:

Die Verwendung eines mehrmandantenfähigen Clusters bietet gegenüber der Nutzung mehrerer Cluster mit je einem Mandanten diverse Vorteile:

  • Reduzierter Verwaltungsaufwand
  • Reduzierte Fragmentierung der Ressourcen
  • Keine Wartezeiten für die Clustererstellung für neue Mandanten

Anwendungsfälle für Mehrmandantenfähigkeit

In diesem Abschnitt wird beschrieben, wie Sie einen Cluster für verschiedene Anwendungsfälle für Mehrmandantenfähigkeit konfigurieren können.

Mehrmandantenfähigkeit in Unternehmen

In einer Unternehmensumgebung sind die Mandanten eines Clusters individuelle Teams innerhalb der Organisation. Jeder Mandant hat in der Regel einen zugehörigen Namespace. Es gibt auch Modelle der Mehrmandantenfähigkeit mit einem Mandanten pro Cluster oder pro Google Cloud-Projekt. Sie lassen sich jedoch schwieriger verwalten. Für den Netzwerktraffic innerhalb eines Namespaces gelten keine Einschränkungen. Der Netzwerktraffic zwischen Namespaces muss explizit zugelassen werden. Diese Richtlinien können Sie mithilfe der Netzwerkrichtlinie für Kubernetes erzwingen.

Die Nutzer des Clusters haben je nach Berechtigung eine von drei Rollen:

Clusteradministrator
Diese Rolle wird Administratoren zugewiesen, die den gesamten Cluster einschließlich aller Mandanten verwalten. Clusteradministratoren können beliebige Richtlinienobjekte erstellen, lesen, aktualisieren und löschen. Sie können Namespaces erstellen und diese Namespace-Administratoren zuweisen.
Namespace-Administrator
Diese Rolle wird Administratoren bestimmter Einzelmandanten zugewiesen. Ein Namespace-Administrator kann die Nutzer in seinem Namespace verwalten.
Entwickler
Nutzer mit dieser Rolle können mit einem Namespace versehene Nicht-Richtlinienobjekte wie Pods, Jobs und Ingresses erstellen, lesen, aktualisieren und löschen. Diese Berechtigungen gelten nur für Namespaces, auf die ein Entwickler Zugriff hat.

Informationen zum Einrichten von mehreren mehrmandantenfähigen Clustern für eine Unternehmensorganisation finden Sie unter Best Practices für die Mehrmandantenfähigkeit in Unternehmen.

Mehrmandantenfähige Cluster von SaaS-Anbietern

In den Clustern eines SaaS-Anbieters sind Mandanten die pro Kunde verwendeten Instanzen der Anwendung sowie die Steuerungsebene der SaaS. Wenn Sie Namespace-bezogene Richtlinien nutzen möchten, sollten Sie die Anwendungsinstanzen in separaten Namespaces organisieren. Dies gilt auch für die Komponenten der Steuerungsebene der SaaS. Endnutzer können nicht direkt mit der Kubernetes-Steuerungsebene interagieren. Sie verwenden stattdessen die SaaS-Benutzeroberfläche, die wiederum mit der Kubernetes-Steuerungsebene interagiert.

Eine Blogging-Plattform kann beispielsweise in einem mehrmandantenfähigen Cluster ausgeführt werden. Die Mandanten sind in diesem Fall die Bloginstanz jedes Kunden und die Steuerungsebene der Plattform. Die Steuerungsebene der Plattform und die einzelnen gehosteten Blogs werden dabei in separaten Namespaces ausgeführt. Kunden können Blogs erstellen und löschen und die Blogging-Softwareversionen über die Benutzeroberfläche der Plattform aktualisieren, ohne Einblick in die Funktionsweise des Clusters zu erhalten.

Durchsetzung einer Richtlinie für Mehrmandantenfähigkeit

GKE und Kubernetes bieten mehrere Verwaltungsfunktionen für mehrmandantenfähige Cluster. In den folgenden Abschnitten erhalten Sie einen Überblick über diese Funktionen.

Zugriffssteuerung

GKE hat zwei Zugriffssteuerungssysteme: Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) und rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC). IAM ist das Zugriffssteuerungssystem der Google Cloud. Darüber werden die Authentifizierung und Autorisierung für Google Cloud-Ressourcen verwaltet. Mit IAM gewähren Sie Nutzern Zugriff auf GKE- und Kubernetes-Ressourcen. RBAC ist in Kubernetes eingebunden und gewährt detaillierte Berechtigungen für bestimmte Ressourcen und Vorgänge in den Clustern.

Weitere Informationen zu den Optionen und ihrer Verwendung finden Sie in der Übersicht über die Zugriffssteuerung.

Mehr zur Verwendung dieser Zugriffssteuerungssysteme erfahren Sie unter Rollenbasierte Zugriffssteuerung und IAM-Richtlinien.

Sie können IAM- und RBAC-Berechtigungen zusammen mit Namespaces verwenden, um Nutzerinteraktionen mit Clusterressourcen in der Google Cloud Console einzuschränken. Weitere Informationen finden Sie unter Zugriff gewähren und Clusterressourcen nach Namespace aufrufen.

Netzwerkrichtlinien

Mit Cluster-Netzwerkrichtlinien können Sie die Kommunikation zwischen den Pods des Clusters steuern. Richtlinien geben an, mit welchen Namespaces, Labels und IP-Adressbereichen ein Pod kommunizieren kann.

Mehr zum Erzwingen von Netzwerkrichtlinien in GKE erfahren Sie unter Cluster-Netzwerkrichtlinien erstellen.

Wie Sie Netzwerkrichtlinien schreiben, wird unter Netzwerkrichtlinien für Anwendungen konfigurieren erläutert.

Ressourcenkontingente

Mit Ressourcenkontingenten verwalten Sie den Umfang der von den Objekten in einem Namespace verwendeten Ressourcen. Sie können wahlweise Kontingente für die CPU- und Speicherauslastung oder die Objektanzahl festlegen. Mit Ressourcenkontingenten stellen Sie sicher, dass jeder Mandant nur die ihm zugewiesenen Clusterressourcen nutzt.

Weitere Informationen finden Sie in der Dokumentation zu Ressourcenkontingenten (nur auf Englisch).

Richtlinienbasierte Steuerung der Pod-Zugriff

Verwenden Sie einen Zulassungs-Controller, um zu verhindern, dass Pods, die gegen Ihre Sicherheitsgrenzen verstoßen, in Ihrem Cluster ausgeführt werden. Zulassungs-Controller können Pod-Spezifikationen mit von Ihnen definierten Richtlinien vergleichen und verhindern, dass Pods, die gegen diese Richtlinien verstoßen, in Ihrem Cluster ausgeführt werden.

GKE unterstützt die folgenden Typen der Zulassungskontrolle:

Pod-Anti-Affinität

Sie können durch Pod-Anti-Affinität verhindern, dass Pods verschiedener Mandanten auf demselben Knoten geplant werden. Einschränkungen hinsichtlich der Anti-Affinität basieren auf Pod-Labels. In der folgenden Pod-Spezifikation wird beispielsweise ein Pod mit dem Label "team": "billing" und einer Anti-Affinitätsregel beschrieben, die verhindert, dass der Pod zusammen mit Pods ohne das Label geplant wird.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

Nachteil dieser Technik ist, dass böswillige Nutzer die Regel umgehen könnten. Sie brauchen dafür nur einem beliebigen Pod das Label team: billing zuzuweisen. Pod-Anti-Affinität alleine reicht nicht aus, um die Richtlinie für Cluster mit nicht vertrauenswürdigen Mandanten sicher zu erzwingen.

Weitere Informationen finden Sie in der Dokumentation zur Pod-Anti-Affinität (nur auf Englisch).

Dedizierte Knoten mit Markierungen und Toleranzen

Knotenmarkierungen bieten eine weitere Möglichkeit zur Steuerung der Arbeitslastplanung. Sie können mit Knotenmarkierungen spezielle Knoten für bestimmte Mandanten reservieren. Weisen Sie beispielsweise Mandanten, für deren Arbeitslasten GPUs erforderlich sind, mit GPUs ausgestattete Knoten zu. Für Autopilot-Cluster werden Knotentoleranzen nur für die Trennung von Arbeitslasten unterstützt. Knotenmarkierungen werden bei Bedarf automatisch durch die automatische Knotenbereitstellung hinzugefügt.

Wenn Sie einem bestimmten Mandanten einen Knotenpool zuweisen möchten, wenden Sie mit effect: "NoSchedule" eine Markierung auf den Knotenpool an. Dadurch können für Knoten im Knotenpool nur Pods mit einer entsprechenden Toleranz geplant werden.

Nachteil dieser Technik ist, dass böswillige Nutzer durch Festlegen einer Pod-Toleranz Zugriff auf den speziellen Knotenpool erhalten. Knotenmarkierungen und -toleranzen alleine reichen nicht aus, um die Richtlinie für Cluster mit nicht vertrauenswürdigen Mandanten sicher zu erzwingen.

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Markierungen und Toleranzen.

Nächste Schritte