Ottimizzazione dell'utilizzo delle risorse in un cluster GKE multi-tenant mediante il provisioning automatico dei nodi

Questo tutorial mostra come utilizzare il provisioning automatico dei nodi per scalare un multi-tenant Google Kubernetes Engine (GKE) cluster e come utilizzare Identità carico di lavoro per controllare l'accesso del tenant a risorse come i bucket Cloud Storage. Questa guida è rivolto a sviluppatori e architetti, presuppone una conoscenza di base di Kubernetes con GKE. Se hai bisogno di una presentazione, consulta Panoramica di GKE.

Multitenancy dei cluster viene spesso implementata per ridurre i costi o standardizzare le operazioni tenant. Per ottenere appieno il risparmio sui costi, devi dimensionare il cluster in modo da e l'uso efficiente delle risorse del cluster. Dovresti anche ridurre al minimo lo spreco di risorse quando il cluster viene scalato automaticamente, assicurandoti che i nodi del cluster vengano siano di dimensioni adeguate.

In questo tutorial utilizzerai il provisioning automatico dei nodi per scalare il cluster. Nodo il provisioning automatico può aiutare a ottimizzare l'utilizzo delle risorse del cluster, i costi, aggiungendo i nodi cluster che meglio si adattano carichi di lavoro con scale out impegnativi.

Obiettivi

  • Crea un cluster GKE con provisioning automatico dei nodi e Workload Identity abilitati.
  • Configura il cluster per la multitenancy.
  • Invia job al cluster per dimostrare come il provisioning automatico dei nodi crea e distrugge i nodi di dimensioni ottimizzate.
  • Utilizza incompatibilità ed etichette per indicare al provisioning automatico dei nodi di creare pool di nodi dedicato per ogni tenant.
  • Usa Workload Identity per controllare l'accesso alle risorse specifiche per il tenant come i bucket Cloud Storage.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Prima di iniziare

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  3. In the Google Cloud console, activate Cloud Shell.

    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.

  4. In Cloud Shell, abilita le API per GKE e l'API Cloud Build: 
    gcloud services enable container.googleapis.com \
    cloudbuild.googleapis.com

    Questa operazione può richiedere alcuni minuti.

preparazione dell'ambiente

In questa sezione, ottieni il codice necessario per questo tutorial e configuri il tuo ambiente con i valori che utilizzerai durante il tutorial.

  1. In Cloud Shell, definisci le variabili di ambiente che utilizzi per questo tutorial:

    export PROJECT_ID=$(gcloud config get-value project)

  2. Clona il repository GitHub che contiene il codice per questo tutorial:

    git clone https://github.com/GoogleCloudPlatform/solutions-gke-autoprovisioning

  3. Cambia la directory del repository:

    cd solutions-gke-autoprovisioning

  4. Aggiorna il file di configurazione del job YAML Kubernetes con il tuo ID progetto Google:

    sed -i "s/MY_PROJECT/$PROJECT_ID/" manifests/bases/job/base-job.yaml

  5. Invia un job Cloud Build per creare un'immagine container:

    gcloud builds submit pi/ --tag gcr.io/$PROJECT_ID/generate-pi

    L'immagine è un programma Go che genera un'approssimazione di pi greco. Utilizzi per questa immagine container in un secondo momento.

    Cloud Build esporta l'immagine nella cartella e Container Registry.

Crea un cluster GKE

In questa sezione creerai un cluster GKE con provisioning automatico e Workload Identity abilitati. Prendi in esame i seguenti dettagli il processo di creazione del cluster:

  • Specifica i limiti di CPU e memoria per il cluster. Nodo il provisioning automatico rispetta questi limiti quando aggiunge o rimuove nodi nel cluster. Per ulteriori informazioni, vedi Abilitazione del provisioning automatico dei nodi nella documentazione di GKE.
  • Devi specificare l'account di servizio e gli ambiti predefiniti utilizzati di nodi all'interno dei pool di nodi di cui è stato eseguito il provisioning automatico. Con queste impostazioni, puoi controllare le autorizzazioni di accesso del nodo di cui è stato eseguito il provisioning. Per ulteriori informazioni, vedi Configurare valori predefiniti dell'identità per i nodi di cui è stato eseguito il provisioning automatico nella documentazione di GKE.
  • Hai impostato profilo di scalabilità automatica che dà la priorità all'utilizzo. Questo profilo indica al gestore della scalabilità automatica dei cluster fare lo scale down rapido del cluster per ridurre al minimo le risorse inutilizzate. Questo può consente di utilizzare in modo più efficiente le risorse per carichi di lavoro incentrati sul job o batch. La si applica a tutti i pool di nodi nel cluster.
  • Puoi abilitare Workload Identity specificando il pool di carichi di lavoro.

Per creare il cluster:

  1. Crea un account di servizio:

    gcloud iam service-accounts create nap-sa

    Questo account di servizio è utilizzato dai nodi di cui è stato eseguito il provisioning automatico.

  2. Concedi al nuovo account di servizio le autorizzazioni per eseguire il pull delle immagini dal Bucket Cloud Storage utilizzato da Container Registry:

    gcloud storage buckets add-iam-policy-binding \
    gs://artifacts.$PROJECT_ID.appspot.com \
    --member=serviceAccount:nap-sa@$PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer

  3. Crea un cluster GKE con nodi provisioning automatico e Workload Identity abilitati:

    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

  4. Imposta il nome del cluster e la zona di computing predefiniti:

    gcloud config set container/cluster multitenant
gcloud config set compute/zone us-central1-c

Configurazione del cluster per la multitenancy

Quando utilizzi un'app SaaS (Software-as-a-Service) multi-tenant, di solito devi separare i tenant. La separazione degli inquilini può aiutare a ridurre al minimo i danni da un tenant compromesso. Può anche aiutarti ad allocare le risorse del cluster in modo uniforme tra i tenant e monitorare il numero di risorse consumate da ciascun tenant. Kubernetes non può garantire l'isolamento perfettamente sicuro tra i tenant, offre funzionalità che potrebbero essere sufficienti per casi d'uso specifici. Per maggiori informazioni sulle funzionalità multi-tenancy di GKE, consulta Panoramica e best practice guide nella documentazione di GKE.

Nell'app di esempio vengono creati due tenant, tenant1 e tenant2. Tu separa ogni tenant e le relative risorse Kubernetes in spazio dei nomi. Crei una semplice criteri di rete che applica l'isolamento dei tenant impedendo la comunicazione da altri spazi dei nomi. In seguito, utilizzi incompatibilità dei nodi e nodeSelector per impedire la pianificazione di pod di tenant diversi nodo. Puoi fornire un ulteriore grado di separazione eseguendo il tenant su nodi dedicati.

Utilizzi Kustomize per gestire i manifest di Kubernetes che invii al cluster. Kustomize consente di combinare e personalizzare i file YAML per più scopi.

  1. Crea uno spazio dei nomi, un account di servizio e una risorsa del criterio di rete per tenant1:

    kubectl apply -k manifests/setup/tenant1

    L'output è simile al seguente:

    namespace/tenant1-ns created
serviceaccount/tenant1-ksa created
networkpolicy.networking.k8s.io/tenant1-deny-from-other-namespaces created

  2. Crea le risorse del cluster per tenant2:

    kubectl apply -k manifests/setup/tenant2

Verifica del comportamento del provisioning automatico dei nodi

Un cluster GKE è costituito da uno dei seguenti pool di nodi. Tutti i nodi all'interno di un pool di nodi hanno lo stesso tipo di macchina, il che significa che hanno la stessa quantità di CPU e memoria. Se le esigenze delle risorse del tuo carico di lavoro potresti trarre vantaggio dall'avere più pool di nodi con diversi tipi di macchine all'interno del tuo cluster. In questo modo, il gestore della scalabilità automatica dei cluster nodi più adatti, in grado di migliorare l'efficienza delle risorse e di conseguenza costi inferiori. Tuttavia, il mantenimento di molti pool di nodi aggiunge gestione overhead. Potrebbe anche non essere pratico in un cluster multi-tenant se vuoi per eseguire carichi di lavoro dei tenant in pool di nodi dedicati.

Puoi utilizzare invece provisioning automatico dei nodi per estendere il gestore della scalabilità automatica dei cluster. Quando il provisioning automatico dei nodi è abilitato, il gestore della scalabilità automatica dei cluster può creare automaticamente nuovi pool di nodi in base specifiche di pod in attesa. Di conseguenza, il gestore della scalabilità automatica dei cluster può creare ma non devi creare o gestire personalmente i pool di nodi. Grazie al provisioning automatico dei nodi, il cluster può scalare automaticamente in modo efficiente senza il provisioning eccessivo, che può aiutarti a ridurre i costi.

Inoltre, se i pod in attesa vincoli di separazione dei carichi di lavoro, il provisioning automatico dei nodi può creare nodi che soddisfano i vincoli. In questo puoi utilizzare il provisioning automatico dei nodi per creare automaticamente pool di nodi verrà utilizzato da un solo tenant.

In questa sezione, invierai vari job al cluster per verificare il comportamento del provisioning automatico dei nodi. I job utilizzano l'immagine generate-pi che hai creato in precedenza.

Inviare un semplice job

Innanzitutto, invii al cluster un semplice job. Il job non specifica nessun a vincoli specifici per il tenant. La capacità di riserva nel cluster è sufficiente per per gestire le richieste di CPU e memoria del job. Di conseguenza, ti aspetti che il job pianificato in uno dei nodi esistenti nel pool di nodi predefinito. Nessun altro viene eseguito il provisioning dei nodi.

  1. Elenca i pool di nodi nel cluster:

    gcloud container node-pools list

    Vedi un singolo pool predefinito.

  2. Stampa la configurazione del job nella console:

    kubectl kustomize manifests/jobs/simple-job/

    L'output è simile al seguente:

    apiVersion: batch/v1
kind: Job
metadata:
name: pi-job
spec:
...

    La configurazione non specifica incompatibilità o selettori dei nodi.

  3. Invia il job:

    kubectl apply -k manifests/jobs/simple-job/

  4. Osserva i pool di nodi nel cluster:

    watch -n 5 gcloud container node-pools list

    Vedi ancora un singolo pool predefinito. Non vengono creati nuovi pool di nodi.

  5. Dopo circa 30 secondi, premi Control+C per interrompere la visualizzazione dei pool di nodi.

  6. Osserva i nodi nel cluster:

    kubectl get nodes -w

    Non vedi nessun nuovo nodo in fase di creazione.

  7. Dopo aver guardato i contenuti per 1 minuto, premi Control+C per interrompere la visione.

  8. Elenca i job nel cluster:

    kubectl get jobs --all-namespaces

    L'output è simile al seguente:

    NAMESPACE   NAME     COMPLETIONS   DURATION   AGE
default     pi-job   1/1           14s        21m

    Il valore 1/1 nella colonna Completions indica che 1 job è stato eliminato di un totale di 1 job completato.

Invia un job con vincoli specifici del tenant

In questa sezione, invierai un altro job per confermare che il provisioning automatico dei nodi rispetta i vincoli di separazione dei carichi di lavoro. La configurazione del job include specifico per il tenant selettore nodi e un modello specifico per il tenant tolleranza. Il job può essere pianificato solo su un nodo con etichette corrispondenti le coppie chiave-valore del selettore. Una tolleranza funziona insieme incompatibilità dei nodi, il che limita anche i job che possono essere pianificati su un nodo. Una best practice con il provisioning automatico dei nodi prevede l'inclusione di un selettore di nodi e di una tolleranza la separazione dei carichi di lavoro.

Questo job non può essere pianificato nel pool di nodi predefinito perché quel pool non avere nodi che soddisfino il vincolo del selettore. Di conseguenza, i nodi Il provisioning automatico crea un nuovo pool di nodi con etichette dei nodi che soddisfano requisito del selettore. Il provisioning automatico dei nodi aggiunge anche un'incompatibilità specifica per il tenant ai nodi che corrispondono alla tolleranza nella configurazione del job. Solo i pod con una tolleranza corrispondente possono essere pianificati sui nodi nel pool, che ti consente di separare ulteriormente i carichi di lavoro dei tenant.

  1. Elenca i pool di nodi nel cluster:

    gcloud container node-pools list

    Vedi un singolo pool predefinito.

  2. Stampa la configurazione del job nella console:

    kubectl kustomize manifests/jobs/one-tenant/

    La configurazione include un requisito del selettore di nodi specifico per il tenant e una tolleranza. L'output è simile al seguente:

    apiVersion: batch/v1
kind: Job
metadata:
name: tenant1-pi-job
spec:
...

  3. Invia il job:

    kubectl apply -k manifests/jobs/one-tenant/

  4. Osserva i pool di nodi nel cluster:

    watch -n 5 gcloud container node-pools list

    Dopo un po' di tempo, vedrai un nuovo pool di nodi. L'output assomiglia a seguenti:

    NAME                            MACHINE_TYPE       DISK_SIZE_GB
default-pool                    n1-standard-2      100
nap-n1-standard-1-15jwludl      n1-standard-1      100

    Il nome del pool di nodi è preceduto dal prefisso nap-, per indicare che è create dal provisioning automatico dei nodi. Il nome del pool di nodi include anche dei nodi nel pool, ad esempio n1-standard-1.

  5. Osserva i nodi nel cluster:

    kubectl get nodes -w

    Dopo circa un minuto, viene visualizzato un nuovo nodo nell'elenco. Il nodo include il nome del pool di nodi nap-. Inizialmente, il nuovo nodo uno stato Not Ready. Dopo un po' di tempo, lo stato del nuovo nodo cambia a Ready, il che significa che il nodo può ora accettare il lavoro in sospeso.

  6. Per interrompere la visualizzazione dei nodi, premi Control+C.

  7. Elenca le incompatibilità dei nodi:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    Puoi notare che il nuovo nodo ha un'incompatibilità NoSchedule per la coppia chiave-valore tenant: tenant1. Di conseguenza, solo i pod con un la tolleranza corrispondente per tenant: tenant1 può essere pianificato sul nodo.

  8. Controlla i job nel cluster:

    kubectl get jobs -w --all-namespaces

    Dopo un po' di tempo, vedrai che tenant1-pi-job ha completato 1/1, che indica che l'operazione è riuscita.

  9. Per interrompere la visione dei job, premi Control+C.

  10. Osserva i pool di nodi nel cluster:

    watch -n 5 gcloud container node-pools list

    Dopo un po' di tempo, noterai che il pool nap- è stato eliminato e il di nuovo ha solo il singolo pool di nodi predefinito. Nodo Il provisioning automatico ha eliminato il pool di nodi nap- perché non sono presenti altro lavoro in sospeso che corrisponde ai vincoli del pool.

  11. Per interrompere la visualizzazione dei pool di nodi, premi Control+C.

Invia due job più grandi con vincoli del tenant

In questa sezione, vengono inviati due job con vincoli specifici per il tenant e aumenterai anche le richieste di risorse per ogni job. Di nuovo, questi job Impossibile pianificare nel pool di nodi predefinito a causa del selettore di nodi i vincoli. Poiché ogni job ha il proprio vincolo di selettore, il provisioning automatico crea due nuovi pool di nodi. In questo modo, puoi utilizzare i nodi il provisioning automatico per mantenere separati i job tenant. Poiché i posti di lavoro hanno un numero di richieste di risorse più alto rispetto al job precedente, il provisioning automatico dei nodi crea pool di nodi con tipi di macchine più grandi rispetto all'ultima volta.

  1. Elenca i pool di nodi nel cluster:

    gcloud container node-pools list

    Vedi un singolo pool predefinito.

  2. Stampa la configurazione combinata:

    kubectl kustomize manifests/jobs/two-tenants/

    La configurazione include due job separati, ciascuno con una un selettore di nodi e una tolleranza specifici per il tenant, con una maggiore richieste.

    L'output è simile al seguente:

    apiVersion: batch/v1
kind: Job
metadata:
name: tenant1-larger-pi-job
spec:
...

  3. Invia i lavori:

    kubectl apply -k manifests/jobs/two-tenants/

  4. Osserva i pool di nodi nel cluster:

    watch -n 5 gcloud container node-pools list

    Dopo un po' di tempo, vedrai due pool di nodi aggiuntivi. L'output sembra ad esempio:

    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

    I nomi dei pool di nodi sono preceduti dal prefisso nap-, per indicare che sono state create mediante il provisioning automatico dei nodi. I nomi dei pool di nodi includono anche il tipo di macchina dei nodi nel pool, ad esempio n1-standard-2.

  5. Per interrompere la visualizzazione dei nodi, premi Control+C.

  6. Osserva i nodi nel cluster:

    kubectl get nodes -w

    Dopo circa un minuto, vengono visualizzati due nuovi nodi nell'elenco. Il nodo includono il nome del pool di nodi nap- associato. I nuovi nodi inizialmente hanno lo stato Not Ready. Dopo un po' di tempo, lo stato del nuovo nodi diventano Ready, il che significa che ora i nodi possono accettare i nodi al lavoro.

  7. Per interrompere la visualizzazione dei nodi, premi Control+C.

  8. Elenca le incompatibilità dei nodi:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    Puoi notare che i nuovi nodi presentano NoSchedule incompatibilità, una con la coppia chiave-valore accoppia tenant: tenant1 e l'altro con tenant: tenant2. Solo i pod con tenant corrispondente le tolleranze possono essere pianificate sui nodi.

  9. Controlla i job nel cluster:

    kubectl get jobs -w --all-namespaces

    Dopo un po' di tempo, vedrai che tenant1-larger-pi-job e tenant2-larger-pi-job modifica per avere 1/1 completamento ciascuno, che indica che il job è stato completato correttamente.

  10. Per interrompere la visione dei job, premi Control+C.

  11. Osserva i pool di nodi nel cluster:

    watch -n 5 gcloud container node-pools list

    Dopo un po' di tempo, vedrai che entrambi i pool nap- sono stati eliminati e ha di nuovo un solo pool di nodi predefinito. Nodo il provisioning automatico ha eliminato nap- pool di nodi perché non sono presenti il lavoro in sospeso che corrisponde ai vincoli dei pool.

  12. Per interrompere la visualizzazione dei pool di nodi, premi Control+C.

Controllo dell'accesso alle risorse Google Cloud

Oltre a mantenere la separazione dei tenant all'interno del cluster, in genere vogliono controllare l'accesso dei tenant alle risorse Google Cloud, bucket Cloud Storage o argomenti Pub/Sub. Ad esempio, ogni tenant potrebbe richiedere un bucket Cloud Storage che non sia accessibili ad altri tenant.

Utilizzo Identità carico di lavoro puoi creare una mappatura tra gli account di servizio Kubernetes Google Cloud account di servizio. Puoi quindi assegnare i ruoli Identity and Access Management (IAM) appropriati al l'account di servizio Google Cloud. In questo modo, puoi applicare in modo forzato principio del privilegio minimo, affinché i job tenant possano accedere alle ma non è possibile accedere alle risorse di proprietà di altri inquilini.

Configura Workload Identity di GKE

configura la mappatura tra il tuo account di servizio Kubernetes e un server l'account di servizio Google Cloud che hai creato.

  1. Crea un account di servizio Google Cloud per tenant1:

    gcloud iam service-accounts create tenant1-gsa

  2. Concedi l'account di servizio Kubernetes per tenant1 IAM autorizzazioni per utilizzare l'account di servizio Google Cloud corrispondente per tenant1:

    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]"

  3. Completa la mappatura tra gli account di servizio annotando il Account di servizio Kubernetes con l'account di servizio Google Cloud:

    kubectl annotate serviceaccount tenant1-ksa -n tenant1-ns \
    iam.gke.io/gcp-service-account=tenant1-gsa@${PROJECT_ID}.iam.gserviceaccount.com

Invia un job che scrive in un bucket Cloud Storage

In questa sezione, confermerai che un job viene eseguito come determinato L'account di servizio Kubernetes può utilizzare le autorizzazioni IAM del suo con l'account di servizio Google Cloud mappato.

  1. Crea un nuovo bucket Cloud Storage per tenant1:

    export BUCKET=tenant1-$PROJECT_ID
gcloud storage buckets create gs://$BUCKET --uniform-bucket-level-access --location=us-central1

    Utilizza l'ID progetto come suffisso nel nome del bucket per creare il nome univoci.

  2. Aggiorna il file di configurazione del job per utilizzare il bucket Cloud Storage:

    sed -i "s/MY_BUCKET/$BUCKET/" \
    manifests/jobs/write-gcs/bucket-write.yaml

  3. Concedi all'account di servizio tenant1 le autorizzazioni di lettura e scrittura nel bucket:

    gcloud storage buckets add-iam-policy-binding \
    gs://$BUCKET \
    --member=serviceAccount:tenant1-gsa@$PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/storage.objectAdmin

  4. Stampa la configurazione del job:

    kubectl kustomize manifests/jobs/write-gcs/

    L'output è simile al seguente:

    apiVersion: batch/v1
kind: Job
metadata:
name: tenant1-pi-job-gcs
spec:
...

    Il nuovo nome del bucket viene passato come argomento a generate-pi e il job specifica l'elemento Kubernetes tenant1-ksa appropriato l'account di servizio.

  5. Invia il job:

    kubectl apply -k manifests/jobs/write-gcs/

    Come nella sezione precedente, il provisioning automatico dei nodi crea un nuovo nodo e un nuovo nodo per eseguire il job.

  6. Osserva il pod del job:

    kubectl get pods -n tenant1-ns -w

    In questo caso, stai guardando il pod anziché il pool di nodi. Tu per vedere la transizione dei pod tramite stati diversi. Dopo un paio di minuti, lo stato diventa Completed. Questo stato indica che il job è stato completato correttamente.

  7. Per interrompere la visione, premi Control+C.

  8. Verifica che un file sia stato scritto nel bucket Cloud Storage:

    gcloud storage ls gs://$BUCKET --long

    Vedi un singolo file.

  9. Per eseguire la pulizia, elimina il job:

    kubectl delete job tenant1-pi-job-gcs -n tenant1-ns

    Inviarai di nuovo questo job nella sezione successiva.

Revoca autorizzazioni IAM

Infine, confermi che la revoca delle autorizzazioni IAM dal L'account di servizio Google Cloud impedisce al servizio Kubernetes mappato di accesso al bucket Cloud Storage.

  1. Revocare le autorizzazioni di scrittura per l'account di servizio Google Cloud nel bucket Cloud Storage:

    gcloud storage buckets remove-iam-policy-binding \
    gs://$BUCKET \
    --member=serviceAccount:tenant1-gsa@$PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/storage.objectAdmin

  2. Invia lo stesso job del precedente:

    kubectl apply -k manifests/jobs/write-gcs/

  3. Osserva di nuovo lo stato dei pod del job:

    kubectl get pods -n tenant1-ns -w

    Dopo un paio di minuti, lo stato diventa Error, che indica che il job non è riuscito. Questo errore è previsto, perché il job l'esecuzione come account di servizio Kubernetes mappato a un cluster Google Cloud che a sua volta non dispone più delle autorizzazioni di scrittura nel bucket Cloud Storage.

  4. Per interrompere la visione del pod, premi Control+C.

  5. Elenca i file presenti nel bucket:

    gcloud storage ls gs://$BUCKET --long

    Vedi un singolo file nel bucket: non è stato scritto un nuovo file.

Esegui la pulizia

Il modo più semplice per eliminare la fatturazione è quello di eliminare il progetto Google Cloud che hai creato per il tutorial.

Elimina il progetto

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina il cluster GKE

Se non vuoi eliminare il progetto, elimina Cluster GKE:

gcloud container clusters delete multitenant

Passaggi successivi