In dieser Anleitung wird gezeigt, wie Sie mithilfe der automatischen Knotenbereitstellung einen mandantenfähigen GKE-Cluster (Google Kubernetes Engine) skalieren und mithilfe von Workload Identity den Mandantenzugriff auf Ressourcen wie Cloud Storage-Buckets steuern. Dieser Leitfaden richtet sich an Entwickler und Architekten und setzt Grundkenntnisse in Kubernetes und GKE voraus. Eine Einführung finden Sie in der Übersicht über GKE.
Die Mehrmandantenfähigkeit von Clustern wird häufig implementiert, um Kosten zu senken oder Vorgänge für Mandanten zu standardisieren. Um das Potenzial für Kosteneinsparungen komplett auszuschöpfen, sollten Sie die Größe Ihres Clusters so anpassen, dass die Clusterressourcen effizient genutzt werden. Außerdem wird empfohlen, Ressourcenverschwendung zu minimieren, wenn für Ihren Cluster das Autoscaling aktiviert ist. Sorgen Sie dafür, dass hinzugefügte Clusterknoten eine geeignete Größe haben.
In dieser Anleitung verwenden Sie die automatische Knotenbereitstellung, um den Cluster zu skalieren. Mit der automatischen Knotenbereitstellung können Sie die Nutzung von Clusterressourcen optimieren und damit Ihre Kosten entsprechend steuern. Dabei werden Clusterknoten hinzugefügt, die optimal für Ihre ausstehenden Arbeitslasten sind.
Ziele
- Einen GKE-Cluster erstellen, bei dem die automatische Knotenbereitstellung und Workload Identity aktiviert sind
- Den Cluster für Mandantenfähigkeit einrichten
- Jobs an den Cluster senden, um zu sehen, wie Knoten optimierter Größen über die automatische Knotenbereitstellung erstellt und gelöscht werden
- Mithilfe von Markierungen und Labels die automatische Knotenbereitstellung anweisen, separate Knotenpools für jeden Mandanten zu erstellen
- Workload Identity verwenden, um den Zugriff auf mandantenspezifische Ressourcen wie Cloud Storage-Buckets zu steuern
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Hinweis
- Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
- Aktivieren Sie in Cloud Shell die APIs für GKE und die Cloud Build API:
gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com
Dies kann einige Minuten dauern.
Umgebung vorbereiten
In diesem Abschnitt rufen Sie den Code ab, den Sie für diese Anleitung benötigen, und richten Ihre Umgebung mit Werten ein, die Sie im Verlauf der Anleitung verwenden.
Definieren Sie in Cloud Shell die Umgebungsvariablen für diese Anleitung:
export PROJECT_ID=$(gcloud config get-value project)
Klonen Sie das GitHub-Repository, das den Code für diese Anleitung enthält:
git clone https://github.com/GoogleCloudPlatform/solutions-gke-autoprovisioning
Wechseln Sie in das Repository-Verzeichnis:
cd solutions-gke-autoprovisioning
Aktualisieren Sie die YAML-Jobkonfigurationsdatei für Kubernetes mit Ihrer Google-Projekt-ID:
sed -i "s/MY_PROJECT/$PROJECT_ID/" manifests/bases/job/base-job.yaml
Senden Sie einen Cloud Build-Job, um ein Container-Image zu erstellen:
gcloud builds submit pi/ --tag gcr.io/$PROJECT_ID/generate-pi
Das Image ist ein Go-Programm, das eine Pi-Näherung generiert. Sie werden dieses Container-Image später verwenden.
Cloud Build exportiert das Image in die Container Registry Ihres Projekts.
GKE-Cluster erstellen
In diesem Abschnitt erstellen Sie einen GKE-Cluster, für den die automatische Knotenbereitstellung und Workload Identity aktiviert sind. Beachten Sie Folgendes für die Clustererstellung:
- Sie legen CPU- und Arbeitsspeicherlimits für den Cluster fest. Bei der automatischen Knotenbereitstellung werden diese Limits berücksichtigt, wenn dem Cluster Knoten hinzugefügt oder daraus entfernt werden. Weitere Informationen finden Sie in der GKE-Dokumentation unter Automatische Knotenbereitstellung aktivieren.
- Sie geben das Standarddienstkonto und die Standardbereiche an, die von den Knoten in den automatisch bereitgestellten Knotenpools verwendet werden. Mit diesen Einstellungen können Sie die Zugriffsberechtigungen des bereitgestellten Knotens steuern. Weitere Informationen finden Sie unter Identitätseinstellungen für automatisch bereitgestellte Knoten festlegen in der GKE-Dokumentation.
- Sie legen ein Autoscaling-Profil fest, das die Nutzung priorisiert. Mit diesem Profil wird für das Cluster-Autoscaling festgelegt, dass der Cluster schnell herunterskaliert wird, um den Umfang nicht verwendeter Ressourcen zu minimieren. Dies kann die Ressourceneffizienz für Batch- oder joborientierte Arbeitslasten verbessern. Die Einstellung gilt für alle Knotenpools im Cluster.
- Sie aktivieren Workload Identity, indem Sie den Workloadpool angeben.
So erstellen Sie den Cluster:
Erstellen Sie ein Dienstkonto:
gcloud iam service-accounts create nap-sa
Dieses Dienstkonto wird von den automatisch bereitgestellten Knoten verwendet.
Gewähren Sie dem neuen Dienstkonto Berechtigungen zum Abrufen von Images aus dem von der Container Registry verwendeten Cloud Storage-Bucket:
gsutil iam ch \ serviceAccount:nap-sa@$PROJECT_ID.iam.gserviceaccount.com:objectViewer \ gs://artifacts.$PROJECT_ID.appspot.com
Erstellen Sie einen GKE-Cluster, bei dem die automatische Knotenbereitstellung und die Workloadidentität aktiviert sind:
gcloud container clusters create multitenant \ --release-channel=regular \ --zone=us-central1-c \ --num-nodes=2 \ --machine-type=n1-standard-2 \ --workload-pool=${PROJECT_ID}.svc.id.goog \ --autoscaling-profile=optimize-utilization \ --enable-autoprovisioning \ --autoprovisioning-service-account=nap-sa@${PROJECT_ID}.iam.gserviceaccount.com \ --autoprovisioning-scopes=\ https://www.googleapis.com/auth/devstorage.read_write,\ https://www.googleapis.com/auth/cloud-platform \ --min-cpu 1 \ --min-memory 1 \ --max-cpu 50 \ --max-memory 256 \ --enable-network-policy \ --enable-ip-alias
Legen Sie den Standard-Clusternamen und die Computing-Zone fest:
gcloud config set container/cluster multitenant gcloud config set compute/zone us-central1-c
Cluster für Mandantenfähigkeit einrichten
Wenn Sie eine mandantenfähige SaaS-Anwendung (Software as a Service) betreiben, sollten Sie Ihre Mandanten normalerweise trennen. Durch die Trennung von Mandanten können Sie Schäden durch einen manipulierten Mandanten minimieren. Außerdem können Sie dadurch Clusterressourcen gleichmäßig auf Mandanten verteilen und die Anzahl der Ressourcen verfolgen, die jeder Mandant verbraucht. Kubernetes kann keine vollständig sichere Isolation zwischen Mandanten gewährleisten, aber es bietet Funktionen, die für bestimmte Anwendungsfälle möglicherweise ausreichend sind. Weitere Informationen zu den Funktionen der GKE-Mehrmandantenfähigkeit finden Sie in der Übersicht und den Best Practices in der GKE-Dokumentation.
In der Beispielanwendung erstellen Sie zwei Mandanten: tenant1
und tenant2
. Sie trennen die Mandanten und die zugehörigen Kubernetes-Ressourcen in eigene Namespaces.
Sie erstellen eine einfache Netzwerkrichtlinie, die die Mandantentrennung erzwingt und dafür die Kommunikation aus anderen Namespaces verhindert. Später verwenden Sie die Felder Knotenmarkierungen und nodeSelector
, um zu verhindern, dass Pods verschiedener Mandanten auf demselben Knoten geplant werden. Sie können die Trennung der Mandanten zusätzlich unterstützen, wenn Sie Mandantenarbeitslasten auf dedizierten Knoten ausführen.
Mit Kustomize verwalten Sie die Kubernetes-Manifeste, die Sie an den Cluster senden. Kustomize bietet die Möglichkeit, YAML-Dateien für verschiedene Zwecke zu kombinieren und anzupassen.
Erstellen Sie einen Namespace, ein Dienstkonto und eine Netzwerkrichtlinienressource für
tenant1
:kubectl apply -k manifests/setup/tenant1
Die Ausgabe sieht so aus:
namespace/tenant1-ns created serviceaccount/tenant1-ksa created networkpolicy.networking.k8s.io/tenant1-deny-from-other-namespaces created
Erstellen Sie die Clusterressourcen für
tenant2
:kubectl apply -k manifests/setup/tenant2
Verhalten der automatischen Knotenbereitstellung prüfen
Ein GKE-Cluster besteht aus einem oder mehreren Knotenpools. Alle Knoten in einem Knotenpool haben denselben Maschinentyp, also dieselbe CPU- und Arbeitsspeicherkapazität. Wenn Ihre Anforderungen an Arbeitslastressourcen variieren, kann es sinnvoll sein, mehrere Knotenpools mit unterschiedlichen Maschinentypen im Cluster bereitzustellen. Auf diese Weise können durch das Cluster-Autoscaling Knoten vom jeweils am besten geeigneten Typ hinzugefügt werden. Dies verbessert die Ressourceneffizienz und senkt somit die Kosten. Die Nutzung vieler Knotenpools erhöht aber auch den Verwaltungsaufwand. Es ist in einem mehrmandantenfähigen Cluster möglicherweise auch nicht sinnvoll, Mandantenarbeitslasten in dedizierten Knotenpools auszuführen.
Stattdessen können Sie die automatische Knotenbereitstellung verwenden, um den Cluster Autoscaler zu erweitern. Wenn die automatische Knotenbereitstellung aktiviert ist, kann der Cluster-Autoscaler neue Knotenpools basierend auf den Spezifikationen ausstehender Pods automatisch erstellen. Der Cluster Autoscaler kann daher Knoten des geeigneten Typs erstellen, ohne die Knotenpools selbst erstellen oder verwalten zu müssen. Mit der automatischen Knotenbereitstellung kann der Cluster effizient ohne Überdimensionierung skalieren, wodurch Sie die Kosten senken können.
Wenn für ausstehende Pods Einschränkungen bei der Arbeitslasttrennung gelten, kann die automatische Knotenbereitstellung außerdem Knoten erstellen, die den Einschränkungen genügen. Dies bietet die Möglichkeit, mit der automatischen Knotenbereitstellung automatisch Knotenpools zu erstellen, die nur von einem einzigen Mandanten verwendet werden.
In diesem Abschnitt senden Sie verschiedene Jobs an den Cluster, um das Verhalten der automatischen Knotenbereitstellung zu prüfen. Die Jobs verwenden das zuvor erstellte Image generate-pi
.
Einfachen Job senden
Als Erstes senden Sie einen einfachen Job an den Cluster. Mit dem Job werden keine mandantenspezifischen Einschränkungen definiert. Der Cluster enthält ausreichend freie Kapazitäten für die CPU- und Arbeitsspeicheranforderungen des Jobs. Daher soll der Job in einem der vorhandenen Knoten im Standardknotenpool geplant werden. Es werden keine zusätzlichen Knoten bereitgestellt.
Knotenpools im Cluster auflisten:
gcloud container node-pools list
Es wird ein einzelner Standardpool angezeigt.
Geben Sie die Konfiguration des Jobs in der Konsole aus:
kubectl kustomize manifests/jobs/simple-job/
Die Ausgabe sieht so aus:
apiVersion: batch/v1 kind: Job metadata: name: pi-job spec: ...
In der Konfiguration werden keine Knotenmarkierungen oder -selektoren festgelegt.
Senden Sie den Job:
kubectl apply -k manifests/jobs/simple-job/
Beobachten Sie die Knotenpools im Cluster:
watch -n 5 gcloud container node-pools list
Es wird weiterhin ein einzelner Standardpool angezeigt. Es wurden keine neuen Knotenpools erstellt.
Drücken Sie nach 30 Sekunden auf
Control+C
, um die Anzeige der Knotenpools zu beenden.Beobachten Sie die Knoten im Cluster:
kubectl get nodes -w
Es wurden keine neuen Knoten erstellt.
Drücken Sie nach einer Minute
Control+C
, um die Wiedergabe zu beenden.Listen Sie die Jobs im Cluster auf:
kubectl get jobs --all-namespaces
Die Ausgabe sieht so aus:
NAMESPACE NAME COMPLETIONS DURATION AGE default pi-job 1/1 14s 21m
Der Wert
1/1
in der SpalteCompletions
gibt an, dass 1 Job von insgesamt 1 Job abgeschlossen wurde.
Job mit mandantenspezifischen Einschränkung senden
In diesem Abschnitt senden Sie einen weiteren Job, um zu prüfen, ob die automatische Knotenbereitstellung die Einschränkungen für die Arbeitslasttrennung einhält. Die Jobkonfiguration enthält einen mandantenspezifischen Knotenselektor und eine mandantenspezifische Toleranz. Der Job kann nur für einen Knoten geplant werden, dessen Labels mit den Schlüssel/Wert-Paaren des Selektors übereinstimmen. Eine Toleranz wird in Verbindung mit Knotenmarkierungen verwendet, die außerdem einschränken, welche Jobs auf einem Knoten geplant werden können. Eine der Best Practices für die automatische Knotenbereitstellung besteht darin, sowohl einen Knotenselektor als auch eine Toleranz für die Trennung der Arbeitslasten anzugeben.
Dieser Job kann nicht im Standardknotenpool geplant werden, da dieser Pool keine Knoten enthält, die die Selektoreinschränkung erfüllen. Daher erstellt die automatische Knotenbereitstellung einen neuen Knotenpool mit Knotenlabels, die die Anforderung des Selektors erfüllen. Die automatische Knotenbereitstellung fügt den Knoten auch eine mandantenspezifische Markierung hinzu, die der Toleranz in der Jobkonfiguration entspricht. Nur Pods mit einer übereinstimmenden Toleranz können auf Knoten im Pool geplant werden. Dadurch lassen sich Arbeitslasten von Mandanten genauer trennen.
Knotenpools im Cluster auflisten:
gcloud container node-pools list
Es wird ein einzelner Standardpool angezeigt.
Geben Sie die Konfiguration des Jobs in der Konsole aus:
kubectl kustomize manifests/jobs/one-tenant/
Die Konfiguration umfasst die Anforderung eines mandantenspezifischen Knotenselektors und eine Toleranz. Die Ausgabe sieht so aus:
apiVersion: batch/v1 kind: Job metadata: name: tenant1-pi-job spec: ...
Senden Sie den Job:
kubectl apply -k manifests/jobs/one-tenant/
Beobachten Sie die Knotenpools im Cluster:
watch -n 5 gcloud container node-pools list
Nach einiger Zeit wird ein neuer Knotenpool angezeigt. Die Ausgabe sieht in etwa so aus:
NAME MACHINE_TYPE DISK_SIZE_GB default-pool n1-standard-2 100 nap-n1-standard-1-15jwludl n1-standard-1 100
Der Name des Knotenpools erhält das Präfix
nap-
, das angibt, dass er durch die automatische Knotenbereitstellung erstellt wurde. Der Knotenpoolname enthält auch den Maschinentyp der Knoten im Pool, z. B.n1-standard-1
.Beobachten Sie die Knoten im Cluster:
kubectl get nodes -w
Nach etwa einer Minute wird ein neuer Knoten in der Liste angezeigt. Der Knotenname enthält den Namen des Knotenpools
nap-
. Der neue Knoten hat anfangs den StatusNot Ready
. Nach einiger Zeit ändert sich der Status des neuen Knotens inReady
. Das bedeutet, dass der Knoten jetzt ausstehende Arbeitslasten akzeptiert.Zum Beenden der Knoten drücken Sie
Control+C
.Listen Sie die Knotenmarkierungen auf:
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
Der neue Knoten hat eine
NoSchedule
-Markierung für das Schlüssel/Wert-Paartenant: tenant1
. Daher können nur Pods, die eine entsprechende Toleranz fürtenant: tenant1
haben, auf dem Knoten geplant werden.Beobachten Sie die Jobs im Cluster:
kubectl get jobs -w --all-namespaces
Nach einiger Zeit sehen Sie, dass
tenant1-pi-job
1/1
Abschluss hat, was darauf hinweist, dass sie erfolgreich abgeschlossen wurde.Um die Beobachtung der Jobs zu beenden, drücken Sie
Control+C
.Beobachten Sie die Knotenpools im Cluster:
watch -n 5 gcloud container node-pools list
Nach einiger Zeit stellen Sie fest, dass der Pool
nap-
gelöscht wird und der Cluster wieder nur noch den einzigen Standardknotenpool hat. Der Knotenpoolnap-
wurde durch die automatische Knotenbereitstellung gelöscht, da keine ausstehenden Aufgaben vorhanden sind, die den Einschränkungen des Pools entsprechen.Drücken Sie
Control+C
, um die Beobachtung der Knotenpools zu beenden.
Zwei größere Jobs mit Mandantenbeschränkungen senden
In diesem Abschnitt senden Sie zwei Jobs mit mandantenspezifischen Einschränkungen und erhöhen außerdem die Ressourcenanforderungen für jeden Job. Auch hier können diese Jobs aufgrund der Einschränkungen des Knotenselektors nicht für den Standardknotenpool geplant werden. Da für jeden Job eine eigene Selektoreinschränkung vorhanden ist, werden bei der automatischen Knotenbereitstellung zwei neue Knotenpools erstellt. Auf diese Weise können Sie die automatische Knotenbereitstellung dazu verwenden, um die Mandantenjobs getrennt zu halten. Da die Jobs im Vergleich zum vorherigen Job eine höhere Ressourcenanforderung haben, werden bei der automatischen Knotenbereitstellung Knotenpools erstellt, deren Maschinentypen größer sind als das letzte Mal.
Knotenpools im Cluster auflisten:
gcloud container node-pools list
Es wird ein einzelner Standardpool angezeigt.
Geben Sie die kombinierte Konfiguration aus:
kubectl kustomize manifests/jobs/two-tenants/
Die Konfiguration umfasst zwei separate Jobs mit jeweils einem mandantenspezifischen Knotenselektor und einer Toleranz sowie mit erhöhten Ressourcenanforderungen.
Die Ausgabe sieht so aus:
apiVersion: batch/v1 kind: Job metadata: name: tenant1-larger-pi-job spec: ...
Senden Sie die Jobs:
kubectl apply -k manifests/jobs/two-tenants/
Beobachten Sie die Knotenpools im Cluster:
watch -n 5 gcloud container node-pools list
Nach einiger Zeit werden zwei zusätzliche Knotenpools angezeigt. Die Ausgabe sieht in etwa so aus:
NAME MACHINE_TYPE DISK_SIZE_GB default-pool n1-standard-2 100 nap-n1-standard-2-6jxjqobt n1-standard-2 100 nap-n1-standard-2-z3s06luj n1-standard-2 100
Die Namen der Knotenpools haben das Präfix
nap-
. Dieses gibt an, dass sie durch die automatische Knotenbereitstellung erstellt wurden. Die Namen der Knotenpools enthalten auch den Maschinentyp der Knoten im Pool, z. B.n1-standard-2
.Zum Beenden der Knoten drücken Sie
Control+C
.Beobachten Sie die Knoten im Cluster:
kubectl get nodes -w
Nach etwa einer Minute werden zwei neue Knoten in der Liste angezeigt. Die Knotennamen enthalten den Namen des zugehörigen
nap-
-Knotenpools. Die neuen Knoten haben anfangs den StatusNot Ready
. Nach einiger Zeit ändert sich der Status des neuen Knotens inReady
. Das bedeutet, dass der Knoten jetzt ausstehende Arbeitslasten akzeptiert.Zum Beenden der Knoten drücken Sie
Control+C
.Listen Sie die Knotenmarkierungen auf:
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
Sie sehen, dass die neuen Knoten
NoSchedule
-Markierungen haben, eine Markierung mit dem Schlüssel/Wert-Paartenant: tenant1
und eine andere mittenant: tenant2
. Auf den Knoten können nur Pods mit entsprechenden Mandantentoleranzen geplant werden.Beobachten Sie die Jobs im Cluster:
kubectl get jobs -w --all-namespaces
Nach einiger Zeit wird für
tenant1-larger-pi-job
undtenant2-larger-pi-job
der Status1/1
angezeigt, um anzugeben, dass die Jobs erfolgreich abgeschlossen wurden.Um die Beobachtung der Jobs zu beenden, drücken Sie
Control+C
.Beobachten Sie die Knotenpools im Cluster:
watch -n 5 gcloud container node-pools list
Nach einiger Zeit sehen Sie, dass beide
nap-
-Pools gelöscht werden und der Cluster wieder nur einen einzigen Standardknotenpool hat. Durch die automatische Knotenbereitstellung wurden dienap-
-Knotenpools gelöscht, da keine ausstehenden Arbeitsaufträge mehr vorhanden sind, die den Pooleinschränkungen entsprechen.Drücken Sie
Control+C
, um die Beobachtung der Knotenpools zu beenden.
Zugriff auf Google Cloud-Ressourcen steuern
Zusätzlich zur Trennung der Mandanten in einem Cluster möchten Sie normalerweise auch den Mandantenzugriff auf Google Cloud-Ressourcen wie Cloud Storage-Buckets oder Pub/Sub-Themen steuern. Beispielsweise kann jeder Mandant einen Cloud Storage-Bucket benötigen, der nicht von anderen Mandanten zugänglich sein soll.
Mit Workload Identity können Sie eine Zuordnung zwischen Kubernetes-Dienstkonten und Google Cloud-Dienstkonten erstellen. Anschließend haben Sie die Möglichkeit, dem Google Cloud-Dienstkonto die entsprechenden Rollen für Identity and Access Management (IAM) zuzuweisen. Sie können so das Prinzip der geringsten Berechtigung erzwingen, damit Mandantenjobs auf ihre zugewiesenen Ressourcen zugreifen können, aber nicht auf die Ressourcen, die zu anderen Mandanten gehören.
Richten Sie die GKE-Workloadidentität ein
Konfigurieren Sie die Zuordnung zwischen Ihrem Kubernetes-Dienstkonto und einem von Ihnen erstellten Google Cloud-Dienstkonto.
Erstellen Sie ein Google Cloud-Dienstkonto für
tenant1
.gcloud iam service-accounts create tenant1-gsa
Gewähren Sie dem Kubernetes-Dienstkonto für
tenant1
IAM-Berechtigungen, um das entsprechende Google Cloud-Dienstkonto fürtenant1
zu verwenden:gcloud iam service-accounts add-iam-policy-binding \ tenant1-gsa@${PROJECT_ID}.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[tenant1-ns/tenant1-ksa]"
Schließen Sie die Zuordnung zwischen den Dienstkonten ab. Annotieren Sie dazu das Kubernetes-Dienstkonto mit dem Google Cloud-Dienstkonto:
kubectl annotate serviceaccount tenant1-ksa -n tenant1-ns \ iam.gke.io/gcp-service-account=tenant1-gsa@${PROJECT_ID}.iam.gserviceaccount.com
Job senden, der in einen Cloud Storage-Bucket schreibt
In diesem Abschnitt prüfen Sie, ob ein Job, der als ein bestimmtes Kubernetes-Dienstkonto ausgeführt wird, die IAM-Berechtigungen seines zugeordneten Google Cloud-Dienstkontos verwendet.
Erstellen Sie einen neuen Cloud Storage-Bucket für
tenant1
:export BUCKET=tenant1-$PROJECT_ID gsutil mb -b on -l us-central1 gs://$BUCKET
Sie verwenden die Projekt-ID als Suffix für den Bucket-Namen, um den Namen eindeutig zu machen.
Aktualisieren Sie die Konfigurationsdatei des Jobs so, dass der Cloud Storage-Bucket verwendet wird:
sed -i "s/MY_BUCKET/$BUCKET/" \ manifests/jobs/write-gcs/bucket-write.yaml
Gewähren Sie dem Dienstkonto
tenant1
Berechtigungen zum Lesen und Schreiben von Objekten im Bucket:gsutil iam ch \ serviceAccount:tenant1-gsa@$PROJECT_ID.iam.gserviceaccount.com:objectAdmin \ gs://$BUCKET
Geben Sie die Jobkonfiguration aus:
kubectl kustomize manifests/jobs/write-gcs/
Die Ausgabe sieht so aus:
apiVersion: batch/v1 kind: Job metadata: name: tenant1-pi-job-gcs spec: ...
Der neue Bucket-Name wird als Argument an den Container
generate-pi
übergeben und der Job legt das entsprechende Kubernetes-Dienstkontotenant1-ksa
fest.Senden Sie den Job:
kubectl apply -k manifests/jobs/write-gcs/
Wie im vorherigen Abschnitt erstellt die automatische Knotenbereitstellung einen neuen Knotenpool und einen neuen Knoten, um den Job auszuführen.
Beobachten Sie den Pod des Jobs:
kubectl get pods -n tenant1-ns -w
In diesem Fall beobachten Sie den Pod und nicht den Knotenpool. Für den Pod-Übergang werden verschiedene Status angegeben. Nach einigen Minuten ändert sich der Status in
Completed
. Dieser Status zeigt an, dass der Job erfolgreich abgeschlossen wurde.Drücken Sie
Control+C
, um die Wiedergabe zu beenden.Prüfen Sie, ob eine Datei in den Cloud Storage-Bucket geschrieben wurde:
gsutil ls -l gs://$BUCKET
Es wird eine einzelne Datei angezeigt.
Löschen Sie den Job zur Bereinigung:
kubectl delete job tenant1-pi-job-gcs -n tenant1-ns
Im nächsten Abschnitt senden Sie diesen Job noch einmal.
IAM-Berechtigungen widerrufen
Abschließend prüfen Sie, ob durch das Widerrufen von IAM-Berechtigungen aus dem Google Cloud-Dienstkonto der Zugriff auf das zugeordnete Kubernetes-Dienstkonto verhindert wird.
Widerrufen Sie für das Google Cloud-Dienstkonto die Berechtigung zum Schreiben in den Cloud Storage-Bucket:
gsutil iam ch -d \ serviceAccount:tenant1-gsa@$PROJECT_ID.iam.gserviceaccount.com:objectAdmin \ gs://$BUCKET
Senden Sie den gleichen Job wie zuvor:
kubectl apply -k manifests/jobs/write-gcs/
Hier sehen Sie den Pod-Status des Jobs noch einmal:
kubectl get pods -n tenant1-ns -w
Nach einigen Minuten ändert sich der Status auf
Error
, was darauf hinweist, dass der Job fehlgeschlagen ist. Dieser Fehler wird erwartet, da der Job als Kubernetes-Dienstkonto ausgeführt wird, das einem Google Cloud-Dienstkonto zugeordnet ist, das wiederum keine Schreibrechte für den Cloud Storage-Bucket hat.Wenn Sie den Pod nicht länger beobachten möchten, drücken Sie
Control+C
.Listen Sie die Dateien im Bucket auf:
gsutil ls -l gs://$BUCKET
Es wird eine einzige Datei im Bucket angezeigt, d. h., es wurde keine neue Datei geschrieben.
Bereinigen
Am einfachsten können Sie die Abrechnung deaktivieren, wenn Sie das Google Cloud-Projekt löschen, das Sie für die Anleitung erstellt haben.
Projekt löschen
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
GKE-Cluster löschen
Wenn Sie das Projekt nicht löschen möchten, löschen Sie den GKE-Cluster:
gcloud container clusters delete multitenant
Nächste Schritte
- GKE-Mandantenfähigkeit
- Cluster-Autoscaling entdecken.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center