Best Practices für die Mehrmandantenfähigkeit in Unternehmen

Der Begriff der Mehrmandantenfähigkeit in Google Kubernetes Engine (GKE) bezieht sich auf einen oder mehrere Cluster, die von Mandanten gemeinsam genutzt werden. In Kubernetes kann ein Mandant Folgendes sein:

  • Ein Team, das für die Entwicklung und Ausführung einer oder mehrerer Arbeitslasten verantwortlich ist.
  • Eine Gruppe zusammengehöriger Arbeitslasten, die von einem oder mehreren Teams ausgeführt werden.
  • Eine einzelne Arbeitslast, z. B. ein Deployment.

Die Mehrmandantenfähigkeit von Clustern wird häufig implementiert, um Kosten zu senken oder Verwaltungsrichtlinien konsistent auf Mandanten anzuwenden. Die fehlerhafte Konfiguration eines GKE-Clusters oder der zugehörigen GKE-Ressourcen kann dabei aber das Ziel der Kosteneinsparung gefährden und zu einer falschen Richtlinienanwendung oder zu schädlichen Interaktionen zwischen den Arbeitslasten verschiedener Mandanten führen.

Dieser Leitfaden enthält Best Practices zum sicheren und effizienten Einrichten von mehrmandantenfähigen Clustern für eine Unternehmensorganisation.

Annahmen und Anforderungen

Den Best Practices in diesem Leitfaden liegt ein mehrmandantenfähiger Anwendungsfall für eine Unternehmensumgebung mit den folgenden Annahmen und Anforderungen zugrunde:

  • Die Organisation ist ein einzelnes Unternehmen mit vielen Mandanten (zwei oder mehr Anwendungs-/Dienstteams), die Kubernetes verwenden und Computing- bzw. Verwaltungsressourcen gemeinsam nutzen möchten.
  • Jeder Mandant ist ein einzelnes Team, das eine Arbeitslast entwickelt.
  • Neben den Anwendungs-/Dienstteams gibt es auch noch andere Teams, die Cluster verwenden und verwalten, darunter Mitglieder des Plattformteams, Clusteradministratoren, Auditoren usw.
  • Das Plattformteam ist Eigentümer der Cluster und definiert den Umfang der Ressourcen, die jedes Mandantenteam verwenden kann. Jeder Mandant kann weitere Ressourcen anfordern.
  • Jedes Mandantenteam soll seine Anwendung über die Kubernetes API bereitstellen können, ohne mit dem Plattformteam kommunizieren zu müssen.
  • Die Mandanten im freigegebenen Cluster sollen keine anderen Mandanten beeinflussen können, außer durch explizite Designentscheidungen wie API-Aufrufe, freigegebene Datenquellen usw.

Diese Konfiguration dient als Modell, mit dem wir Best Practices für mehrere Mandanten darstellen. Die Beispieleinrichtung bildet möglicherweise nicht alle Unternehmensorganisationen perfekt ab. Sie kann aber problemlos auf ähnliche Szenarien erweitert werden.

Ordner, Projekte und Cluster einrichten

Best Practices:

Ordner und Projekthierarchie einrichten
Rollen mit IAM zuweisen
Netzwerksteuerung mit freigegebenen VPCs zentralisieren
Ein Cluster-Administratorprojekt pro Cluster erstellen
Cluster als privat festlegen
Prüfen, ob die Steuerungsebene für den Cluster regional ist
Prüfen, ob die Knoten in Ihrem Cluster mindestens drei Zonen umfassen
Clusterknoten und -ressourcen automatisch skalieren
Wartungsfenster außerhalb der Spitzenzeiten planen
Externen Application Load Balancer mit Ingress einrichten

Für Unternehmen, die Cluster mit mehreren Mandanten in GKE bereitstellen, ist in anderen Google Cloud-Systemen eine zusätzliche Konfiguration erforderlich. Nur so kann die damit verbundene Komplexität bewältigt werden, die in einfacheren Kubernetes-Deployments mit einer Anwendung und einem Team nicht gegeben ist. Dies umfasst sowohl die Projektkonfiguration zur Isolierung von administrativen Problemen als auch die Zuordnung der Organisationsstruktur zu Cloud-Identitäten und -Konten sowie die Verwaltung zusätzlicher Google Cloud-Ressourcen wie Datenbanken, Logging und Monitoring, Speicher und Netzwerke.

Ordner- und Projekthierarchie einrichten

Mithilfe von Ordnern und Projekten können Sie erfassen, wie Ihre Organisation Google Cloud-Ressourcen verwaltet, sowie eine Trennung von Bereichen erzwingen. Ordner bieten verschiedenen Teams die Möglichkeit, Richtlinien festzulegen, die über mehrere Projekte verteilt sind. Außerdem können Projekte dazu verwendet werden, Umgebungen (z. B. Produktion oder Staging) und Teams voneinander zu trennen. Die meisten Organisationen haben beispielsweise ein Team für das Verwalten der Netzwerkinfrastruktur und ein anderes für das Verwalten von Clustern. Jede Technologie wird als separater Teil des Stacks betrachtet, der eigene Kenntnisse, eine eigene Fehlerbehebung und eigenen Zugriff erfordert.

Ein übergeordneter Ordner kann bis zu 300 Ordner enthalten und Sie können Ordner bis zu zehn Ebenen verschachteln. Wenn Sie mehr als 300 Mandanten haben, können Sie die Mandanten in verschachtelte Hierarchien einteilen, um innerhalb des Limits zu bleiben. Weitere Informationen zu Ordnern finden Sie unter Ordner erstellen und verwalten.

Rollen mit IAM zuweisen

Sie können den Zugriff auf Google Cloud-Ressourcen über IAM-Richtlinien steuern. Ermitteln Sie dafür zuerst die für Ihre Organisation erforderlichen Gruppen sowie deren Tätigkeitsbereich und weisen Sie der jeweiligen Gruppe dann die entsprechende IAM-Rolle zu.

Verwenden Sie Google Groups, um IAM für Nutzer effizient zuzuweisen und zu verwalten.

Netzwerksteuerung zentralisieren

Zur zentralen Steuerung von Netzwerkressourcen wie Subnetze, Routen und Firewalls verwenden Sie freigegebene VPC-Netzwerke. Ressourcen in einer freigegebenen VPC können mithilfe von internen IP-Adressen sicher und effizient über Projektgrenzen hinweg miteinander kommunizieren. Jedes freigegebene VPC-Netzwerk wird von einem zentralen Hostprojekt definiert, zu dem es gehört. Es kann von einem oder mehreren Dienstprojekten genutzt werden.

Mit freigegebener VPC und IAM können Sie die Netzwerkverwaltung von der Projektverwaltung trennen. Diese Trennung ermöglicht, den Grundsatz der geringsten Berechtigung zu implementieren. Ein zentrales Netzwerkteam kann beispielsweise das Netzwerk verwalten, ohne Berechtigungen für die beteiligten Projekte zu benötigen. Ebenso können die Projektadministratoren ihre Projektressourcen verwalten, ohne zu Änderungen am freigegebenen Netzwerk berechtigt sein zu müssen.

Wenn Sie eine freigegebene VPC einrichten, müssen Sie die Subnetze und ihre sekundären IP-Bereiche in der VPC konfigurieren. Zum Bestimmen der Subnetzgröße benötigen Sie die erwartete Anzahl an Mandanten, die Anzahl der Pods und Dienste, die sie ausführen sollen, sowie die maximale und die durchschnittliche Pod-Größe. Durch die Berechnung der erforderlichen Gesamtkapazität des Clusters können Sie die gewünschte Instanzgröße ermitteln und erhalten so die Gesamtzahl der Knoten. Anhand der Gesamtzahl der Knoten kann der insgesamt belegte IP-Speicherplatz berechnet und damit die gewünschte Subnetzgröße bereitgestellt werden.

Bei der Einrichtung Ihres Netzwerks sollten Sie außerdem die folgenden Faktoren berücksichtigen:

  • Die maximale Anzahl an Dienstprojekten, die an ein Hostprojekt angehängt werden können, beträgt 1.000. Die maximale Anzahl an freigegebenen VPC-Hostprojekten in einer einzelnen Organisation beträgt 100.
  • Die IP-Bereiche für Knoten, Pods und Dienste müssen eindeutig sein. Sie können kein Subnetz erstellen, dessen primärer und sekundärer IP-Adressbereich sich überschneiden.
  • Die maximale Anzahl an Pods und Diensten in einem bestimmten GKE-Cluster ist durch die Größe der sekundären Bereiche des Clusters begrenzt.
  • Die maximale Anzahl an Knoten im Cluster ist durch die Größe des primären IP-Adressbereichs des Clustersubnetzes und des Pod-Adressbereichs des Clusters begrenzt.
  • Für mehr Flexibilität und Kontrolle über die IP-Adressverwaltung können Sie die maximale Anzahl an Pods konfigurieren, die sich auf einem Knoten ausführen lassen. Wird die Anzahl der Pods pro Knoten reduziert, verringert sich auch der pro Knoten zugewiesene CIDR-Bereich. Dadurch sind weniger IP-Adressen erforderlich.

Sie können mit dem Open-Source-Tool GKE IPAM Calculator die Subnetze für Ihre Cluster berechnen. Die IP-Adressverwaltung (IP Address Management, IPAM) ermöglicht eine effiziente Nutzung von IP-Bereichen/Subnetzen und hilft, Überlappungen in Bereichen zu vermeiden. Dies begrenzt letztlich auch Verbindungsmöglichkeiten. Informationen zu Netzwerkbereichen in einem VPC-Cluster finden Sie unter VPC-nativen Cluster erstellen.

Wenn Mandanten eine zusätzliche Isolierung für Ressourcen benötigen, die außerhalb der freigegebenen Cluster ausgeführt werden (z. B. dedizierte Compute Engine-VMs), können sie ihre eigene VPC verwenden, die mit der vom Netzwerkteam ausgeführten freigegebenen VPC per Peering verbunden ist. Dies bietet zusätzliche Sicherheit, allerdings auf Kosten höherer Komplexität und zahlreicher anderer Einschränkungen. Weitere Informationen zum Peering finden Sie unter VPC-Netzwerk-Peering verwenden. Im folgenden Beispiel haben sich alle Mandanten entschieden, eine einzelne Mandanten-VPC (pro Umgebung) gemeinsam zu nutzen.

Zuverlässige und hochverfügbare Cluster erstellen

Konzipieren Sie Ihre Clusterarchitektur so, dass Hochverfügbarkeit und Zuverlässigkeit gewährleistet sind. Folgen Sie dazu den folgenden Empfehlungen:

  • Erstellen Sie ein Clusteradministratorprojekt pro Cluster. Damit verringern Sie das Risiko, dass Konfigurationen auf Projektebene (z. B. IAM-Bindungen) viele Cluster beeinträchtigen, und ermöglichen eine Trennung von Kontingenten und Abrechnung. Clusteradministratorprojekte sind von Mandantenprojekten getrennt, mit denen einzelne Mandanten beispielsweise ihre Google Cloud-Ressourcen verwalten.
  • Legen Sie den Produktionscluster als privat fest, um den Zugriff auf die Knoten zu deaktivieren und um den Zugriff auf die Steuerungsebene verwalten zu können. Außerdem empfehlen wir die Verwendung privater Cluster für Entwicklungs- und Staging-Umgebungen.
  • Achten Sie darauf, dass die Steuerungsebene für den Cluster regional ist, um eine Hochverfügbarkeit für Mehrmandantenfähigkeit zu gewährleisten. Alle Unterbrechungen der Steuerungsebene wirken sich auf die Mandanten aus. Beachten Sie, dass die Ausführung regionaler Cluster kostenbezogene Auswirkungen haben kann. Autopilot-Cluster sind als regionale Cluster vorkonfiguriert.
  • Knoten in Ihrem Cluster müssen mindestens drei Zonen umfassen, um eine zonale Zuverlässigkeit zu erreichen. Informationen zu den Kosten für ausgehenden Traffic zwischen Zonen in derselben Region finden Sie in der Dokumentation zu den allgemeinen Netzwerkpreisen.
Ein privater regionaler Cluster mit einer regionalen Steuerungsebene, die in drei Zonen ausgeführt wird
Abbildung 3: Ein privater regionaler Cluster mit einer regionalen Steuerungsebene, die in drei Zonen ausgeführt wird

Autoscaling von Clusterknoten und -ressourcen

Skalieren Sie die Knoten in Ihrem Cluster automatisch, um die Anforderungen Ihrer Mandanten zu erfüllen. Aktivieren Sie dazu Autoscaling.

Das Autoscaling sorgt dafür, dass Systeme reaktionsfähig und fehlerfrei bleiben, wenn von mehreren Mandanten in ihren Namespaces hohe Arbeitslasten bereitgestellt werden. Außerdem hilft es dabei, auf Zonenausfälle zu reagieren.

Bei Autopilot-Clustern werden Knotenpools automatisch skaliert, um die Anforderungen Ihrer Arbeitslasten zu erfüllen.

Wenn Sie das Autoscaling aktivieren, müssen Sie die minimale und maximale Anzahl an Knoten in einem Cluster angeben, je nach erwarteter Arbeitslastgröße. Durch Festlegen der maximalen Anzahl an Knoten können Sie dafür sorgen, dass für alle Pods im Cluster immer genügend Speicherplatz vorhanden ist, unabhängig davon, in welchem Namespace sie ausgeführt werden. Das Cluster-Autoscaling skaliert Knotenpools anhand der festgelegten Min/Max-Werte neu. Dadurch reduzieren sich die Betriebskosten, wenn die Systemlast sinkt. Außerdem wechseln Pods nicht in den Status "Ausstehend", wenn nicht genügend Clusterressourcen verfügbar sind. Um die maximale Anzahl an Knoten zu bestimmen, ermitteln Sie den maximalen Umfang an CPU und Arbeitsspeicher, den jeder Mandant benötigt. Addieren Sie dann diese Werte. Sie erhalten so die Gesamtkapazität, die der Cluster bewältigen muss, wenn alle Mandanten das Limit erreicht haben. Anhand der maximalen Anzahl an Knoten können Sie dann die Größe sowie die Anzahl von Instanzen bestimmen und dabei den für den Cluster verfügbaren IP-Subnetzbereich berücksichtigen.

Mit Pod-Autoscaling können Sie Pods anhand der Ressourcenanforderungen automatisch skalieren. Horizontales Pod-Autoscaling (HPA) skaliert die Anzahl der Pod-Replikate anhand der CPU-/Arbeitsspeicherauslastung oder von benutzerdefinierten Messwerten. Mit vertikalem Pod-Autoscaling (VPA) können Pod-Ressourcenanforderungen automatisch skaliert werden. Es sollte nicht mit HPA verwendet werden, sofern keine benutzerdefinierten Messwerte verfügbar sind, da die beiden Autoscaling-Methoden miteinander konkurrieren können. Aus diesem Grund sollten Sie mit HPA beginnen und erst später VPA verwenden, wenn dies erforderlich wird.

Größe des Clusters bestimmen

Bei der Bestimmung der Größe Ihres Clusters sind folgende wichtige Faktoren zu berücksichtigen:

  • Die Größe des Clusters hängt von der Art der Arbeitslasten ab, die Sie ausführen möchten. Wenn Ihre Arbeitslasten eine höhere Dichte haben, erhöht sich die Kosteneffizienz, aber auch die Wahrscheinlichkeit von Ressourcenkonflikten.
  • Die Mindestgröße eines Clusters wird durch die Anzahl der Zonen definiert, die er umfasst: ein Knoten für einen zonalen Cluster und drei Knoten für einen regionalen Cluster.
  • Pro Projekt sind maximal 50 Cluster pro Zone sowie 50 regionale Cluster pro Region möglich.
  • Pro Cluster sind maximal 15.000 Knoten pro Cluster (5.000 für GKE-Versionen bis 1.17), 1.000 Knoten pro Knotenpool, 1.000 Knoten pro Cluster (bei Verwendung des GKE-Ingress-Controllers), 256 Pods pro Knoten (110 für GKE-Versionen vor 1.23.5-gke.1300), 150.000 Pods pro Cluster und 300.000 Container pro Cluster zulässig. Weitere Informationen finden Sie auf der Seite zu Kontingenten und Limits.

Wartungsfenster planen

Um Ausfallzeiten bei Cluster-/Knotenupgrades und -wartungen zu reduzieren, sollten Sie Wartungsfenster außerhalb der Spitzenzeiten planen. Während der Upgrades kann es zu vorübergehenden Unterbrechungen kommen, wenn Arbeitslasten verschoben werden, um Knoten neu zu erstellen. Um solche Unterbrechungen so gering wie möglich zu halten, sollten Sie Upgrades außerhalb der Spitzenzeiten planen und Ihre Anwendungs-Deployments so gestalten, dass sie Teilunterbrechungen möglichst reibungslos verarbeiten.

Externen Application Load Balancer mit Ingress einrichten

Um die veröffentlichten Dienste Ihrer Mandanten sowie den eingehenden Traffic zu diesen Diensten besser verwalten zu können, erstellen Sie einen HTTP(s)-Load-Balancer, der eine einzelne Ingress-Ressource pro Cluster zulässt. Dabei sind die Dienste jedes Mandanten bei der Ingress-Ressource des Clusters registriert. Sie können einen HTTP(S)-Load-Balancer erstellen und konfigurieren. Dazu legen Sie eine Kubernetes Ingress-Ressource an, die definiert, wie der Traffic Ihre Dienste erreicht und wie der Traffic an die Anwendung Ihres Mandanten weitergeleitet wird. Die Registrierung von Diensten mit der Ingress-Ressource ermöglicht eine konsistente Namensvergabe bei den Diensten. Damit wird dann immer eine bestimmte Ingress-Ressource wie tenanta.example.com und tenantb.example.com angezeigt.

Cluster für Mehrmandantenfähigkeit sichern

Best Practices:

Pod-Kommunikation mit Netzwerkrichtlinien steuern
Arbeitslasten mit GKE Sandbox ausführen
Richtlinienbasierte Zulassungskontrollen einrichten
Workload Identity-Föderation für GKE verwenden, um Zugriff auf Google Cloud-Dienste zu gewähren.
Netzwerkzugriff auf die Steuerungsebene beschränken

Pod-Kommunikation mit Netzwerkrichtlinien steuern

Zum Steuern der Netzwerkkommunikation zwischen Pods in allen Namespaces Ihres Clusters erstellen Sie Netzwerkrichtlinien anhand der Anforderungen Ihrer Mandanten. Wir empfehlen, als Erstes den Traffic zwischen Namespaces zu blockieren, die die Anwendungen verschiedener Mandanten hosten. Ihr Clusteradministrator kann eine deny-all-Netzwerkrichtlinie anwenden, um den gesamten eingehenden Traffic abzulehnen. Dies verhindert, dass Pods aus einem Namespace versehentlich Traffic an Dienste oder Datenbanken in anderen Namespaces senden.

Im Folgenden finden Sie ein Beispiel für eine Netzwerkrichtlinie, die den eingehenden Traffic von allen anderen Namespaces auf den Namespace tenant-a beschränkt:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Arbeitslasten mit GKE Sandbox ausführen

Cluster, die nicht vertrauenswürdige Arbeitslasten ausführen, sind anfälliger für Sicherheitslücken. Mit GKE Sandbox können Sie die Isolationsgrenzen zwischen Arbeitslasten für Ihre mehrmandantenfähige Umgebung härten. Für die Sicherheitsverwaltung empfehlen wir, mit GKE Sandbox zu beginnen und dann richtlinienbasierte Zulassungskontrollen zu verwenden, um etwaige Lücken zu schließen.

GKE Sandbox basiert auf gVisor, einem Open-Source-Container-Sandboxing-Projekt. Es bietet eine zusätzliche Isolierung für mehrmandantenfähige Arbeitslasten. Dazu wird eine zusätzliche Schicht zwischen Ihren Containern und dem Hostbetriebssystem hinzugefügt. Containerlaufzeiten werden häufig als privilegierter Nutzer auf dem Knoten ausgeführt und haben Zugriff auf die meisten Systemaufrufe im Host-Kernel. In einem mehrmandantenfähigen Cluster kann ein schädlicher Mandant Zugriff auf den Host-Kernel und auf die Daten eines anderen Mandanten bekommen. GKE Sandbox verringert das Risiko solcher Bedrohungen, da Container nicht mehr mit dem Host interagieren müssen. Dazu wird die Angriffsfläche des Hosts verkleinert und die Bewegung schädlicher Nutzer eingeschränkt.

GKE Sandbox bietet zwei Isolationsgrenzen zwischen dem Container und dem Hostbetriebssystem:

  • Ein in Go geschriebener Nutzerbereichs-Kernel, der Systemaufrufe verarbeitet und die Interaktion mit dem Host-Kernel begrenzt. Jeder Pod hat seinen eigenen isolierten Nutzerbereichs-Kernel.
  • Der Nutzerbereichs-Kernel wird auch in Namespaces ausgeführt; Seccomp filtert Systemaufrufe.

Richtlinienbasierte Zulassungskontrollen einrichten

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:

  • Policy Controller: Deklarieren Sie vordefinierte oder benutzerdefinierte Richtlinien und erzwingen Sie sie in Clustern mithilfe von Flotten in großem Umfang. Policy Controller ist eine Implementierung des Open-Source-Gatekeeper-Open-Policy-Agents und ist ein Feature von GKE Enterprise.

Workload Identity-Föderation für GKE verwenden, um Zugriff auf Google Cloud-Dienste zu gewähren

Wenn Sie Arbeitslasten sicheren Zugriff auf Google Cloud-Dienste gewähren möchten, aktivieren Sie im Cluster die Workload Identity-Föderation für GKE. Die Workload Identity-Föderation für GKE unterstützt Administratoren bei der Verwaltung von Kubernetes-Dienstkonten, mit denen Kubernetes-Arbeitslasten auf Google Cloud-Dienste zugreifen. Wenn Sie einen Cluster bei aktivierter Workload Identity-Föderation für GKE erstellen, wird ein Identitäts-Namespace für das Projekt eingerichtet, in dem sich der Cluster befindet. Mit dem Identitäts-Namespace kann der Cluster Dienstkonten für GKE-Anwendungen automatisch authentifizieren. Dazu ordnet er den Namen des Kubernetes-Dienstkontos einem virtuellen Google-Dienstkontonamen zu, der für die IAM-Bindung von Mandanten-Kubernetes-Dienstkonten verwendet wird.

Netzwerkzugriff auf die Steuerungsebene beschränken

Zum Schutz Ihre Steuerungsebene können Sie den Zugriff auf autorisierte Netzwerke beschränken. Wenn Sie in GKE autorisierte Netzwerke aktivieren, haben Sie die Möglichkeit, bis zu 50 CIDR-Bereiche zu autorisieren und festzulegen, dass nur IP-Adressen in diesen Bereichen auf Ihre Steuerungsebene zugreifen können. GKE verwendet bereits Transport Layer Security (TLS) und eine Authentifizierung für einen sicheren Zugriff auf den Endpunkt der Steuerungsebene über das öffentliche Internet. Mit einem autorisierten Netzwerk können Sie den Zugriff auf bestimmte Gruppen von IP-Adressen weiter einschränken.

Mandantenbereitstellung

Best Practices:

Mandantenprojekte erstellen
Mandantenzugriff mit RBAC optimieren
Namespaces für die Isolierung zwischen Mandanten erstellen

Mandantenprojekte erstellen

Zum Hosten von Nicht-Cluster-Ressourcen eines Mandanten müssen Sie für jeden Mandanten ein Dienstprojekt erstellen. Diese Dienstprojekte enthalten logische Ressourcen, die für die Mandantenanwendungen spezifisch sind (z. B. Logs, Monitoring, Storage-Buckets, Dienstkonten usw.). Alle Mandantendienstprojekte sind mit der freigegebenen VPC im Mandantenhostprojekt verbunden.

Mandantenzugriff mit RBAC optimieren

Mit Kubernetes RBAC können Sie einen detaillierteren Zugriff auf Clusterressourcen für Ihre Mandanten definieren. Sie können zusätzlich zu dem Lesezugriff, den Mandantengruppen anfänglich mit IAM erhalten, namespace-weite RBAC-Rollen und -Bindungen für jede Mandantengruppe definieren.

Wir haben zuvor zwei Mandantengruppen identifiziert: Mandantenadministratoren und Mandantenentwickler. Für diese Gruppen definieren wir die folgenden RBAC-Rollen und den Zugriff:

Gruppe Kubernetes
RBAC-Rolle		 Beschreibung
Mandantenadministrator Namespace-Administrator

Gewährt Zugriff, um Deployments in ihrem Namespace aufzulisten und zu überwachen.

Gewährt Zugriff, um Nutzer der Mandantengruppe hinzuzufügen und daraus zu entfernen.
Mandantenentwickler Namespace-Editor,
Namespace-Betrachter		 Gewährt Zugriff, um Pods, Deployments, Dienste und Konfigurationszuordnungen in ihrem Namespace zu erstellen/bearbeiten/löschen.

Neben der Erstellung von RBAC-Rollen und -Bindungen, mit denen Google Workspace- oder Cloud Identity-Gruppen verschiedene Berechtigungen innerhalb ihres Namespace zugewiesen werden, benötigen Mandantenadministratoren häufig die Möglichkeit, Nutzer in jeder dieser Gruppen zu verwalten. Abhängig von den Anforderungen Ihres Unternehmens kann dies entweder durch Delegieren von Google Workspace- oder Cloud Identity-Berechtigungen an den Mandantenadministrator erfolgen, damit dieser seine eigene Gruppenmitgliedschaft verwaltet, oder durch den Mandantenadministrator, der mit einem Team in Ihrem Unternehmen zusammenarbeitet, das die Google Workspace- oder Cloud Identity-Berechtigungen hat, um diese Änderungen vorzunehmen.

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.

Google Groups zum Binden von Berechtigungen verwenden

Um Mandantenberechtigungen in einem Cluster effizient zu verwalten, können Sie RBAC-Berechtigungen an Ihre Google Groups binden. Die Mitgliedschaft in diesen Gruppen wird von Ihren Google Workspace-Administratoren verwaltet, sodass Ihre Clusteradministratoren keine detaillierten Informationen über Ihre Nutzer benötigen.

Beispiel: Der Nutzer admin1@mydomain.com ist Mitglied in der Google-Gruppe tenant-admins@mydomain.com. Die folgende Bindung gewährt dem Nutzer Administratorzugriff auf den Namespace tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Namespaces erstellen

Zum Bereitstellen einer logischen Isolierung zwischen Mandanten im selben Cluster können Sie Namespaces implementieren. Im Rahmen des Kubernetes-RBAC-Prozesses erstellt der Clusteradministrator Namespaces für jede Mandantengruppe. Der Mandantenadministrator verwaltet Nutzer (Mandantenentwickler) innerhalb ihres jeweiligen Mandanten-Namespace. Mandantenentwickler können dann mit cluster- und mandantenspezifischen Ressourcen ihre Anwendungen bereitstellen.

Erreichen von Namespace-Grenzen vermeiden

Die maximal zulässige Anzahl an Namespaces in einem Cluster beträgt 10.000. In der Praxis können jedoch viele Faktoren das Erreichen dieser Grenze verhindern. So wird beispielsweise eventuell die maximale Anzahl an Pods (150.000) und Knoten (5.000) im Cluster vor der maximalen Anzahl von Namespaces erreicht. Andere Faktoren wie die Anzahl der Secrets können die effektiven Limits weiter verringern. Daher ist es eine gute Faustregel, wenn Sie anfänglich versuchen, sich der Grenze einer Einschränkung nur anzunähern, und andere Limits bei weitem nicht ausschöpfen, es sei denn, Tests zeigen, dass Ihre Anwendungsfälle gut funktionieren. Wenn Sie mehr Ressourcen benötigen, als von einem einzelnen Cluster unterstützt werden können, sollten Sie mehr Cluster erstellen. Informationen zur Skalierbarkeit von Kubernetes finden Sie im Artikel Kubernetes-Grenzen der Skalierbarkeit.

Namespace-Benennung standardisieren

Es ist zu empfehlen, die verwendete Namenskonvention für Namespaces zu standardisieren, um Deployments in mehreren Umgebungen, die in verschiedenen Clustern gehostet werden, zu vereinfachen. Beispielsweise sollten Sie den Umgebungsnamen (Entwicklung, Staging und Produktion) nicht mit dem Namespace-Namen verknüpfen. Verwenden Sie stattdessen den gleichen Namen in allen Umgebungen. Dadurch müssen Sie die Konfigurationsdateien nicht umgebungsspezifisch ändern.

Dienstkonten für Mandantenarbeitslasten erstellen

Erstellen Sie für jede einzelne Arbeitslast in einem Mandanten-Namespace ein mandantenspezifisches Google-Dienstkonto. Auf diese Weise können Mandanten Dienstkonten für die Arbeitslasten sicher verwalten, die in ihren jeweiligen Namespaces vorhanden sind bzw. bereitgestellt werden. Das Kubernetes-Dienstkonto für jeden Namespace wird mithilfe der Workload Identity-Föderation für GKE einem Google-Dienstkonto zugeordnet.

Ressourcenkontingente erzwingen

Alle Mandanten, die einen Cluster gemeinsam nutzen, müssen gleichen Zugriff auf die Clusterressourcen haben. Erzwingen Sie dazu Ressourcenkontingente. Erstellen Sie ein Ressourcenkontingent für jeden Namespace anhand der Anzahl der von jedem Mandanten bereitgestellten Pods und der von jedem Pod benötigten Speicher- und CPU-Menge.

Im folgenden Beispiel wird ein Ressourcenkontingent definiert, bei dem Pods im Namespace tenant-a bis zu 16 CPUs und 64 GB Arbeitsspeicher anfordern können. Das Maximum sind 32 CPUs und 72 GB Arbeitsspeicher.

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

Monitoring, Logging und Nutzung

Best Practices:

Nutzungsmesswerte erfassen
Mandantenspezifische Logs bereitstellen.

Nutzungsmesswerte erfassen

Für Kostenaufschlüsselungen einzelner Namespaces und Labels in einem Cluster können Sie die GKE-Kostenzuordnung aktivieren. Die GKE-Kostenzuordnung erfasst Informationen über Ressourcenanforderungen und die Ressourcennutzung der Arbeitslasten eines Clusters, die sich weiter nach Namespaces und Labels aufschlüsseln lassen. Mit der GKE-Kostenzuordnung können Sie die Kostenaufschlüsselung für Abteilungen/Teams, die einen Cluster gemeinsam nutzen, ungefähr schätzen, die Nutzungsmuster einzelner Anwendungen (oder von Komponenten einer einzelnen Anwendung) nachvollziehen, Clusteradministratoren beim Ermitteln von Auslastungsspitzen unterstützen und eine bessere Kapazitätsplanung sowie Budgetierung ausführen.

Wenn Sie die GKE-Kostenzuordnung aktivieren, werden der Clustername und der Namespace Ihrer GKE-Arbeitslasten im Label-Feld des Abrechnungsexports nach BigQuery angezeigt:

Mandantenspezifische Logs bereitstellen

Wenn Sie für Mandanten bestimmte Logdaten für deren Projektarbeitslasten bereitstellen möchten, verwenden Sie den Log Router von Cloud Logging. Zum Erstellen mandantenspezifischer Logs erstellt der Clusteradministrator eine Senke, um Logeinträge in einen Log-Bucket zu exportieren, der im Google Cloud-Projekt des Mandanten erstellt wurde.

Weitere Informationen zum Konfigurieren dieser Logtypen finden Sie unter Mehrmandantenfähiges Logging in GKE.

Zusammenfassung der Checkliste

In der folgenden Tabelle sind die Aufgaben zusammengefasst, die zum Erstellen von mehrmandantenfähigen Clustern in einer Unternehmensorganisation empfohlen werden:

Bereich Aufgaben
Organisatorische Einrichtung
Identitäts- und Zugriffsverwaltung
Netzwerk
Hochverfügbarkeit und Zuverlässigkeit
Sicherheit
Logging und Monitoring

Nächste Schritte