Eseguire il deployment di un cluster Redis su GKE

Standard

---

Questo tutorial fornisce pratiche consigliate per la creazione di un'applicazione stateful e l'upgrade del cluster Google Kubernetes Engine (GKE) su cui è in esecuzione l'applicazione. Questo tutorial utilizza Redis come esempio per il deployment di un'applicazione stateful, ma gli stessi concetti sono applicabili ad altri tipi di applicazioni stateful di cui è stato eseguito il deployment in GKE.

Obiettivi

Questo tutorial illustra i seguenti passaggi:

1. Crea un cluster GKE registrato in un canale di rilascio.
2. Crea un cluster Redis su GKE.
3. Eseguire il deployment dell'applicazione client Redis in GKE.
4. Esegui queste best practice per gli upgrade del pool di nodi:
   1. Configura il budget di interruzione dei pod (PDB).
   2. Configura il periodo di manutenzione e le esclusioni.
   3. Configura la strategia di upgrade dei nodi per l'upgrade per un picco o l'upgrade blu/verde.
5. Testa l'applicazione.
6. Esegui l'upgrade del cluster.
7. Testare l'interruzione del carico di lavoro.

Il seguente diagramma mostra una visione generale dell'architettura del cluster per questo tutorial:

Costi

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

• GKE

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

Configura il progetto

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

2. Nella pagina del selettore di progetti della console Google Cloud, fai clic su Crea progetto per iniziare a creare un nuovo progetto Google Cloud.

   Vai al selettore progetti

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

4. Attiva l'API GKE.

   Abilita l'API

5. Nella pagina del selettore di progetti della console Google Cloud, fai clic su Crea progetto per iniziare a creare un nuovo progetto Google Cloud.

   Vai al selettore progetti

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

7. Attiva l'API GKE.

   Abilita l'API

Configura i valori predefiniti per Google Cloud CLI

1. Nella console Google Cloud, avvia un'istanza di Cloud Shell:
   Apri Cloud Shell

2. Scarica il codice sorgente per questa app di esempio:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    cd kubernetes-engine-samples/quickstarts/hello-app-redis/manifests
   

3. Imposta le variabili di ambiente predefinite:

    gcloud config set project PROJECT-ID
    gcloud config set compute/zone COMPUTE-ZONE
   

   Sostituisci i seguenti valori:

   • PROJECT_ID: il tuo ID progetto Google Cloud.
   • COMPUTE_ZONE: la zona di Compute Engine.

Crea un cluster GKE registrato in un canale di rilascio

Per creare il tuo cluster GKE, completa questi passaggi:

1. Crea un cluster denominato redis-test con tre nodi:

   gcloud container clusters create redis-test \
       --num-nodes=3 \
       --release-channel regular
   

   Una volta creato il cluster, dovresti vedere un output simile al seguente esempio:

     NAME: redis-test
     LOCATION: us-central1-c
     MASTER_VERSION: 1.22.10-gke.600
     MASTER_IP: 34.69.67.7
     MACHINE_TYPE: e2-medium
     NODE_VERSION: 1.22.10-gke.600
     NUM_NODES: 3
     STATUS: RUNNING
   

2. Configura kubectl per comunicare con il cluster:

   gcloud container clusters get-credentials redis-test
   

Crea un cluster Redis su GKE

In questa sezione aggiungerai un cluster Redis al di sopra del cluster GKE che hai creato in precedenza eseguendo il deployment di un cluster ConfigMap, StatefulSet e servizio headless.

Per creare un cluster Redis, completa questi passaggi:

1. Fai riferimento al file ConfigMap (redis-configmap.yaml) in cui è archiviata la configurazione Redis. Lo snippet riportato di seguito mostra gli script del probe di idoneità e del probe di attività.

   readiness.sh: |-
     #!/bin/sh
   
     pingResponse="$(redis-cli -h localhost ping)"
     if [ "$?" -eq "124" ]; then
       echo "PING timed out"
       exit 1
     fi
   
     if [ "$pingResponse" != "PONG"]; then
       echo "$pingResponse"
       exit 1
     fi
   liveness.sh: |-
     #!/bin/sh
   
     pingResponse="$(redis-cli -h localhost ping | head -n1 | awk '{print $1;}')"
     if [ "$?" -eq "124" ]; then
       echo "PING timed out"
       exit 1
     fi
   
     if [ "$pingResponse" != "PONG"] && [ "$pingResponse" != "LOADING" ] && [ "$pingResponse" != "MASTERDOWN" ]; then
       echo "$pingResponse"
       exit 1
     fi

   Gli script readiness.sh e liveness.sh utilizzano il ping su Redis per verificare se il server Redis è in esecuzione o meno. Se restituisce PONG, il server Redis è in esecuzione. Questi script verranno utilizzati in redis-cluster.yaml.

   Per scoprire di più sui parametri Redis in questo ConfigMap, consulta la sezione sui parametri di configurazione del cluster Redis nel tutorial sul cluster Redis.

2. Esegui il deployment del ConfigMap:

   kubectl apply -f redis-configmap.yaml
   

3. Fai riferimento allo snippet StatefulSet (redis-cluster.yaml) di seguito che mostra l'utilizzo del probe di idoneità e del probe di attività.

   Per scoprire come configurare i probe in Kubernetes, consulta Configurare i probe.

   startupProbe:
     periodSeconds: 5
     timeoutSeconds: 5
     successThreshold: 1
     failureThreshold: 20
     tcpSocket:
       port: redis
   livenessProbe:
     periodSeconds: 5
     timeoutSeconds: 5
     successThreshold: 1
     failureThreshold: 5
     exec:
       command: ["sh", "-c", "/probes/liveness.sh"]
   readinessProbe:
     periodSeconds: 5
     timeoutSeconds: 1
     successThreshold: 1
     failureThreshold: 5
     exec:
       command: ["sh", "-c", "/probes/readiness.sh"]

   Ti consigliamo vivamente di utilizzare probe di idoneità e di attività quando esegui l'upgrade dei pool di nodi, in modo che i tuoi pod siano pronti durante un upgrade.

4. Esegui il deployment dello StatefulSet:

   kubectl apply -f redis-cluster.yaml
   

5. Il servizio headless denominato redis-service.yaml è destinato alla connessione dei nodi Redis. Per creare un servizio headless, il campo clusterIP è impostato su None.

   Esegui il deployment del servizio:

   kubectl apply -f redis-service.yaml
   

6. Attendi circa due minuti e verifica che tutti i pod siano in esecuzione utilizzando il seguente comando:

   kubectl get pods
   

   Dovresti vedere un output simile al seguente esempio:

   NAME      READY   STATUS              RESTARTS   AGE
   redis-0   1/1     Running             0          2m29s
   redis-1   1/1     Running             0          2m8s
   redis-2   1/1     Running             0          107s
   redis-3   1/1     Running             0          85s
   redis-4   1/1     Running             0          54s
   redis-5   1/1     Running             0          23s
   

7. Verifica che i volumi permanenti siano stati creati eseguendo questo comando:

   kubectl get pv
   

   Dovresti vedere un output simile al seguente esempio:

   NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-5   standard                75s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-1   standard                2m59s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-3   standard                2m16s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-2   standard                2m38s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-0   standard                3m20s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-4   standard                104s
   

   In questo output, HASH rappresenta un hash associato al nome di ogni volume permanente.

Assegna ruoli al tuo cluster Redis

Una volta completata la configurazione, assegna i ruoli al cluster Redis.

Lo script seguente ottiene gli indirizzi IP dei pod, quindi assegna i ruoli leader e follower passando al comando ciascuno degli indirizzi IP dei pod:

#!/bin/bash
# Usage: ./roles.sh

urls=$(kubectl get pods -l app=redis -o jsonpath='{range.items[*]}{.status.podIP} ')
command="kubectl exec -it redis-0 -- redis-cli --cluster create --cluster-replicas 1 "

for url in $urls
do
    command+=$url":6379 "
done

echo "Executing command: " $command
$command

Per assegnare ruoli al tuo cluster Redis, completa questi passaggi:

1. Esegui lo script:

   chmod +x ./roles.sh
   ./roles.sh
   

2. Digita yes quando richiesto.

3. Accedi a un nodo Redis per verificarne il ruolo. Ad esempio, per verificare che redis-0 abbia un ruolo di leader, esegui questo comando:

   kubectl exec -it redis-0 -- redis-cli role
   

   Dovresti vedere un output simile al seguente esempio:

   1) "master"
   2) (integer) 574
   3) 1) 1) "10.28.2.3"
          2) "6379"
          3) "574"
   

Esegui il deployment dell'applicazione client Redis

Per eseguire il deployment dell'applicazione nel cluster GKE che hai creato, definisci un deployment per l'applicazione. Il file denominato app-deployment.yaml contiene la definizione del deployment dell'applicazione.

Per saperne di più sui probe e sulle regole di affinità dei pod utilizzati in questo deployment, consulta Best practice di GKE: progettazione e creazione di cluster ad alta disponibilità.

Per creare il deployment, completa i seguenti passaggi:

1. Applica il deployment:

   kubectl apply -f app-deployment.yaml
   

2. Esponi l'applicazione tramite un bilanciatore del carico:

   kubectl expose deployment hello-web \
       --type=LoadBalancer \
       --port 80 \
       --target-port 8080
   

3. Attendi circa un minuto e recupera l'indirizzo IP esterno dell'applicazione eseguendo questo comando:

   kubectl get service
   

   Dall'output, copia il valore elencato nella colonna hello-web's EXTERNAL-IP:

   NAME             TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)              AGE
   hello-web        LoadBalancer   10.13.10.55   EXTERNAL_IP   80:30703/TCP         166m
   

4. Verifica che l'applicazione funzioni incollando EXTERNAL_IP nel browser web. Dovresti vedere un output simile al seguente esempio:

   I have been hit [1] times since deployment!
   

   Prendi nota del numero della visita. Devi utilizzarlo nella sezione Test dell'interruzione dell'applicazione.

5. Imposta una variabile per EXTERNAL_IP che hai appena copiato. Utilizza questo valore quando crei script per testare l'applicazione nella sezione successiva:

   export IP=EXTERNAL_IP
   

Configura le best practice per gli upgrade dei pool di nodi

Esegui queste best practice per le applicazioni stateful al fine di ottimizzare la disponibilità durante gli upgrade del pool di nodi.

Configura il budget per l'interruzione dei pod (PDB)

Crea un budget di interruzione dei pod per limitare il numero di pod replicati inattivi contemporaneamente durante un'interruzione volontaria. Questo è utile per le applicazioni stateful in cui è necessario un quorum affinché il numero di repliche sia disponibile durante un upgrade.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: redis

In una definizione dei PDB:

• app specifica l'applicazione a cui si applica il PDB.
• minAvailable imposta il numero minimo di pod disponibili durante un'interruzione. Può essere un valore o una percentuale (ad es. 30%).
• maxUnavailable imposta il numero massimo di pod che possono essere non disponibili durante un'interruzione. Può essere anche un valore o una percentuale.

Nota: in base al quorum o alle preferenze dell'applicazione, scegli minAvailable o maxUnavailable per il PDB.

Nota: una volta impostato il PodDisruptionBudget, GKE non arresterà i pod nell'applicazione se il numero di pod è uguale o inferiore a un limite configurato per un massimo di 60 minuti.

Per configurare il PDB, segui questi passaggi:

1. Esegui il deployment del PDB:

   kubectl apply -f pdb-minavailable.yaml
   

2. Verifica che il PDB sia stato creato:

   kubectl get pdb
   

Configurare i periodi di manutenzione e le esclusioni

Gli upgrade automatici dei nodi semplificano il processo di upgrade e mantengono aggiornati i nodi nel cluster quando viene eseguito l'upgrade del piano di controllo per tuo conto. Questa funzione è attivata per impostazione predefinita. Per scoprire di più, consulta Upgrade automatico dei nodi.

Utilizza periodi di manutenzione ed esclusioni di manutenzione per impostare gli intervalli di tempo e controllare quando può essere eseguita la manutenzione dei cluster GKE:

1. Configura un periodo di manutenzione che inizia alle 02:00 UTC del 19 agosto 2022 e termina quattro ore dopo. Questo periodo di manutenzione viene eseguito ogni giorno. Durante questo periodo, è consentita la manutenzione automatica.

   gcloud container clusters update redis-test \
      --maintenance-window-start 2022-08-19T02:00:00Z \
      --maintenance-window-end 2022-08-19T06:00:00Z \
      --maintenance-window-recurrence FREQ=DAILY
   

2. Configura un periodo di esclusione che impedisca la manutenzione durante le festività di Capodanno. Questa esclusione della manutenzione utilizza l'ambito no_upgrades. Durante questo periodo, non è consentita alcuna manutenzione automatica di alcun tipo. Per scoprire di più, consulta Ambito della manutenzione da escludere.

   gcloud container clusters update redis-test \
      --add-maintenance-exclusion-name new-year \
      --add-maintenance-exclusion-start 2022-12-26T00:00:00Z \
      --add-maintenance-exclusion-end 2023-01-02T02:00:00Z \
      --add-maintenance-exclusion-scope no_upgrades
   

3. Verifica che il periodo di manutenzione e le esclusioni siano applicate. Cerca sotto maintenancePolicy:

   gcloud container clusters describe redis-test
   

Per scoprire di più, consulta Configurare i periodi di manutenzione e le esclusioni.

Configura una strategia di upgrade dei nodi

Esistono due strategie di upgrade dei nodi che puoi utilizzare per i pool di nodi nel cluster GKE: upgrade blu/verde e upgrade di picco. Per scoprire di più, consulta Strategie di upgrade dei nodi.

Upgrade blu/verde

Scegli gli upgrade blu/verde se i carichi di lavoro tollerano meno le interruzioni ed è accettabile un aumento temporaneo dei costi dovuto a un maggiore utilizzo delle risorse.

Esegui questo comando per modificare gli attuali pool di nodi nella strategia di upgrade blu-verde.

gcloud container node-pools update default-pool \
--cluster=redis-test \
--enable-blue-green-upgrade \
--zone COMPUTE-ZONE \
--node-pool-soak-duration=120s

La durata di attesa del pool di nodi è impostata su due minuti per risparmiare tempo durante la fase di soak del pool di nodi ai fini di questo tutorial. Questa fase viene utilizzata per verificare l'integrità del carico di lavoro dopo lo svuotamento dei nodi del pool blu. Ti consigliamo di impostare la durata di attesa del pool di nodi su un'ora (3600 secondi) o su una durata più adatta all'applicazione.

Per ulteriori informazioni sulla gestione dell'allocazione dei pod, consulta Eseguire il deployment di un pod in un pool di nodi specifico e Deployment di servizi in pool di nodi specifici.

Per ulteriori informazioni sulla configurazione degli upgrade blu/verde, consulta Configurare gli upgrade blu/verde.

Upgrade di Surge

Scegli gli upgrade di sovraccarico se l'ottimizzazione dei costi è importante e se i carichi di lavoro possono tollerare un arresto controllato in meno di 60 minuti (GKE rispetta PDB fino a 60 minuti).

Esegui questo comando per modificare gli attuali pool di nodi in modo da utilizzare la strategia di upgrade di picco.

gcloud container node-pools update default-pool \
--max-surge-upgrade=1 \
--max-unavailable-upgrade=0 \
--cluster=redis-test

Con questa configurazione (maxSurge=1 e maxUnavailable=0), durante un upgrade è possibile aggiungere un solo nodo di picco al pool di nodi, in modo che sia possibile eseguire l'upgrade di un solo nodo alla volta. Questa impostazione velocizza i riavvii dei pod durante gli upgrade, mentre i progressi vengono eseguiti in modo conservativo.

Per ulteriori informazioni sulla configurazione degli upgrade di sovraccarico, consulta Configurare gli upgrade di sovraccarico.

Controlla la configurazione attuale del pool di nodi:

   gcloud container node-pools describe default-pool \
   --cluster redis-test \
   --zone COMPUTE-ZONE

Per saperne di più sulla visualizzazione dei pool di nodi, consulta Visualizzare i pool di nodi in un cluster.

testa l'applicazione

In questa sezione utilizzi due script, uno che invia richieste all'applicazione e l'altro che misura la percentuale di successo delle richieste. che puoi utilizzare per misurare cosa succede quando esegui l'upgrade del cluster.

Per creare gli script:

1. Passa alla directory che contiene gli script:

   cd
   cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
   

2. Fai riferimento allo script denominato generate_load.sh che invia una richiesta di query al secondo (QPS) alla tua applicazione. Lo script salva il codice di risposta HTTP nella directory corrente in un file denominato output. Il valore di output viene utilizzato nello script creato nel passaggio successivo.

   #!/bin/bash
   # Usage: ./generate_load.sh <IP> <QPS>
   
   IP=$1
   QPS=$2
   
   while true
     do for N in $(seq 1 $QPS)
       do curl -I -m 5 -s -w "%{http_code}\n" -o /dev/null http://${IP}/ >> output &
       done
     sleep 1
   done

3. Fai riferimento allo script denominato print_error_rate.sh che calcola la percentuale di successo in base all'output generato da generate_load.sh.

   #!/bin/bash
   # Usage: watch ./print_error_rate.sh
   
   TOTAL=$(cat output | wc -l);
   SUCCESS=$(grep "200" output |  wc -l);
   ERROR1=$(grep "000" output |  wc -l)
   ERROR2=$(grep "503" output |  wc -l)
   ERROR3=$(grep "500" output |  wc -l)
   SUCCESS_RATE=$(($SUCCESS * 100 / TOTAL))
   ERROR_RATE=$(($ERROR1 * 100 / TOTAL))
   ERROR_RATE_2=$(($ERROR2 * 100 / TOTAL))
   ERROR_RATE_3=$(($ERROR3 * 100 / TOTAL))
   echo "Success rate: $SUCCESS/$TOTAL (${SUCCESS_RATE}%)"
   echo "App network Error rate: $ERROR1/$TOTAL (${ERROR_RATE}%)"
   echo "Resource Error rate: $ERROR2/$TOTAL (${ERROR_RATE_2}%)"
   echo "Redis Error rate: $ERROR3/$TOTAL (${ERROR_RATE_3}%)"

4. Concediti l'autorizzazione a eseguire gli script:

   chmod u+x generate_load.sh print_error_rate.sh
   

5. Imposta una variabile per il numero di QPS. Questo valore viene utilizzato nello script generate_load.sh così come la variabile impostata per EXTERNAL_IP. Ti consigliamo di impostare un valore pari a 40.

   export QPS=40
   

6. Esegui lo script generate_load.sh per iniziare a inviare QPS:

   ./generate_load.sh $IP $QPS 2>&1
   

7. Lascia in esecuzione lo script generate_load.sh e apri un nuovo terminale. Nel nuovo terminale, esegui lo script print_error_rate.sh per controllare la percentuale di errori:

   cd
   cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
   watch ./print_error_rate.sh
   

   Man mano che vengono effettuati i QPS, dovresti vedere una percentuale di successo del 100% e una percentuale di errore dello 0%.

8. Lascia in esecuzione entrambi gli script e apri un terzo terminale in preparazione per la sezione successiva.

Esegui l'upgrade del cluster

Per eseguire l'upgrade del cluster, completa questi passaggi:

1. Determina quale versione di GKE viene utilizzata dal cluster redis-test:

   V=$(gcloud container clusters describe redis-test | grep "version:" | sed "s/version: //")
   echo $V
   

   Dovresti vedere un output simile al seguente esempio: 1.22.9-gke.2000.

2. Recupera un elenco delle versioni di Kubernetes disponibili:

   gcloud container get-server-config
   

3. Nell'elenco delle versioni, individua la sezione validMasterVersions: e cerca la versione in redis-cluster recuperata nel passaggio precedente. Per evitare il disallineamento delle versioni, copia la versione dall'elenco che si trova immediatamente sopra la versione redis-cluster.

4. Esegui l'upgrade del piano di controllo del cluster alla versione selezionata e digita y quando richiesto:

   gcloud container clusters upgrade redis-test \
       --master \
       --cluster-version VERSION
   

   Sostituisci VERSION con la versione selezionata dall'elenco nel passaggio precedente.

   L'upgrade del piano di controllo richiede diversi minuti.

5. Esegui l'upgrade dei nodi del cluster alla versione selezionata e digita y quando richiesto:

   gcloud container clusters upgrade redis-test \
       --cluster-version=VERSION \
       --node-pool=default-pool
   

   Sostituisci VERSION con la versione selezionata nell'elenco.

Testa l'interruzione del carico di lavoro

In questa sezione testerai lo stato dell'applicazione e osserverai l'interruzione dei carichi di lavoro.

1. Torna alla finestra del terminale che esegue ./print_error_rate.sh e osserva come è cambiata la percentuale di successo durante l'upgrade. Dovresti notare una leggera diminuzione nella percentuale di successo e un leggero aumento della percentuale di errori di rete dell'app man mano che i nodi vengono rimossi per l'upgrade.

   Nel campo Success rate, potrai vedere quante visite sono state effettuate correttamente al sito web. Prendi nota di questo valore.

2. Interrompi l'esecuzione di entrambi gli script inserendo CTRL+C nei terminali pertinenti.

3. Torna al sito web dell'applicazione inserendo il relativo indirizzo IP (si tratta del EXTERNAL_IP che hai copiato durante la sezione Esegui il deployment dell'applicazione client Redis) nel browser.

4. Osserva il numero delle visite per la tua richiesta. Il numero visualizzato deve corrispondere a:

   ORIGINAL_VISIT_NUMBER + SUCCESSFUL_VISIT_NUMBER

   dove ORIGINAL_VISIT_NUMBER è il numero registrato nel passaggio finale del deployment dell'applicazione client Redis e SUCCESSFUL_VISIT_NUMBER è il valore registrato nel primo passaggio di questa sezione.

Esegui la pulizia

Al termine del tutorial, puoi eseguire la pulizia delle risorse che hai creato in modo che smettano di utilizzare la quota e smettano di essere addebitati. Le sezioni seguenti descrivono come eliminare o disattivare queste risorse.

Elimina il progetto

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

Per eliminare il progetto:

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

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.

Eliminare il cluster

Per eliminare il cluster creato per questo tutorial, esegui questo comando:

gcloud container clusters delete redis-test

Passaggi successivi

• Best practice per l'upgrade dei cluster
• Come impostare le notifiche di cluster
• Best practice di GKE: operazioni day-2
• Configurare i controlli di integrità con i probe