Simulare un errore di zona nei cluster GKE a livello di regione


Un requisito normativo comune è che un'azienda possa dimostrare la propria capacità di risposta ai disastri (RE). Per le applicazioni in esecuzione nel cloud, questo requisito include l'affidabilità e la disponibilità dei servizi quando i server in hosting in una zona non sono disponibili per un determinato periodo di tempo. Questo documento è rivolto ad amministratori e architetti, operatori e amministratori di backup e ripristino di emergenza (RE) che vogliono imparare a simulare un failover di zona quando utilizzano un cluster regionale Google Kubernetes Engine (GKE) Standard.

I cluster regionali GKE vengono creati in una regione scelta dall'utente ed eseguono il piano di controllo su VM situate in più zone all'interno della regione scelta. I cluster GKE Autopilot sono sempre regionali e i cluster GKE Standard possono essere regionali o a livello di zona. Questo tutorial utilizza un cluster GKE Standard a livello di regione. I nodi del cluster comunicano con il piano di controllo tramite un bilanciatore del carico, il che significa che la posizione del nodo e la posizione della VM del piano di controllo non corrispondono sempre. Nella console Google Cloud, non puoi disattivare una determinata zona quando utilizzi un cluster regionale. Per maggiori informazioni, consulta Architettura del cluster GKE.

Questo tutorial fornisce tre diversi metodi per simulare un errore di zona. Puoi simulare un errore di zona e verificare la risposta corretta dell'applicazione utilizzando il metodo richiesto per le tue finalità di conformità.

I metodi descritti in questo documento si applicano anche ai cluster a livello di zona, inclusi quelli a zona singola e multi-zona. Questi metodi influiscono solo sui nodi nelle zone scelti come target e il piano di controllo GKE non è interessato.

Obiettivi

  • Crea un cluster GKE Standard a livello di regione utilizzando la configurazione predefinita.
  • Esegui il deployment di un'applicazione di microservizi di esempio nel cluster regionale.
  • Simula un'interruzione di servizio in una zona utilizzando uno dei seguenti tre metodi:
    • Riduci le zone del pool di nodi in un cluster regionale.
    • Utilizza un pool di nodi a zona singola.
    • Isola e svuota i nodi della zona di errore target.
  • Verifica la disponibilità dei microservizi.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

  • Compute Engine
  • Cluster in modalità GKE Standard

Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.

Prima di iniziare

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Kubernetes Engine API, Compute Engine APIs:

    gcloud services enable container.googleapis.com compute.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Kubernetes Engine API, Compute Engine APIs:

    gcloud services enable container.googleapis.com compute.googleapis.com

Creare un cluster standard regionale

Prima di simulare un errore di zona, crea un cluster a livello di area geografica con un pool di nodi multi-zona. Il piano di controllo e i nodi del cluster vengono replicati in più zone della regione specificata.

Utilizza Google Cloud CLI per creare il cluster:

  1. Crea un nuovo cluster GKE Standard utilizzando la configurazione predefinita:

    gcloud container clusters create CLUSTER_NAME \
      --region REGION \
      --num-nodes 2
    

    Sostituisci i seguenti parametri:

    • CLUSTER_NAME: il nome del cluster.
    • REGION: la regione del cluster, ad esempio us-central1.

    GKE impiega alcuni minuti per creare il cluster e verificare che tutto funzioni correttamente. Vengono creati due nodi in ogni zona della regione specificata.

  2. Controlla le zone di ogni nodo creato nel passaggio precedente:

    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    L'output è simile all'esempio seguente:

    NAME                                    ZONE                INT_IP
    regional-cluster-1-default-pool-node1   asia-southeast1-c   10.128.0.37
    regional-cluster-1-default-pool-node2   asia-southeast1-c   10.128.0.36
    regional-cluster-1-default-pool-node3   asia-southeast1-b   10.128.0.38
    regional-cluster-1-default-pool-node4   asia-southeast1-b   10.128.0.33
    regional-cluster-1-default-pool-node5   asia-southeast1-a   10.128.0.35
    regional-cluster-1-default-pool-node6   asia-southeast1-a   10.128.0.34
    
  3. Connettiti al cluster:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --region REGION
    

Esegui il deployment di un'applicazione di microservizi di esempio

Per vedere l'effetto del failover simulato in questo documento, esegui il deployment di un'applicazione basata su microservizi di esempio nel tuo cluster. In questo documento utilizzi la applicazione di esempio Cymbal Bank:

  1. Nella shell, clona il seguente repository GitHub e passa alla directory:

    git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
    cd bank-of-anthos/
    
  2. Esegui il deployment dell'applicazione di esempio Cymbal Bank nel cluster GKE che hai creato nella sezione precedente:

    kubectl apply -f ./extras/jwt/jwt-secret.yaml
    kubectl apply -f ./kubernetes-manifests
    
  3. Attendi che i pod siano pronti:

    kubectl get pods
    
  4. Dopo qualche minuto, dovresti vedere i pod in uno stato Running:

    NAME                                  READY   STATUS    RESTARTS   AGE
    accounts-db-0                         1/1     Running   0          16s
    balancereader-7dc7d9ff57-sstm5        0/1     Running   0          15s
    contacts-7ddc76d94-rr28x              0/1     Running   0          14s
    frontend-747b84bff4-2mtlv             0/1     Running   0          13s
    ledger-db-0                           1/1     Running   0          13s
    ledgerwriter-f6cc7889d-9qjfg          0/1     Running   0          13s
    loadgenerator-57d4cb57cc-zqvqb        1/1     Running   0          13s
    transactionhistory-5dd7c7fd77-lwkv8   0/1     Running   0          12s
    userservice-cd5ddb4bb-wwhml           0/1     Running   0          12s
    
  5. Quando tutti i pod sono in stato Running, recupera l'indirizzo IP esterno del servizio frontend:

    kubectl get service frontend | awk '{print $4}'
    
  6. In una finestra del browser web, apri l'indirizzo IP mostrato nell'output del comando kubectl get service per accedere alla tua istanza di Cymbal Bank.

    Le credenziali predefinite vengono compilate automaticamente, quindi puoi accedere all'app ed esplorare alcune delle transazioni e dei saldi di esempio. Non sono necessarie azioni specifiche, tranne che per verificare che Cymbal Bank funzioni correttamente. Potrebbero essere necessari un paio di minuti per l'avvio corretto di tutti i servizi e per consentirti di accedere. Attendi che tutti i pod siano in stato Running e che tu riesca ad accedere al sito della banca Cymbal prima di passare alla sezione successiva e simulare un errore di zona.

Simulare un errore di una zona

In questa sezione simuli un errore con una delle zone. Esistono tre modi diversi per simulare questo failover. Devi scegliere un solo metodo. Simula un errore di zona e verifica la risposta corretta dell'applicazione utilizzando il metodo necessario per le tue finalità di conformità.

Riduci le zone pool di nodi

Per impostazione predefinita, un pool di nodi di un cluster regionale ha nodi che si estendono a tutte le zone della regione. Nel seguente diagramma, Cloud Load Balancing distribuisce il traffico a un pool di nodi che si estende su tre zone. Ogni zona ha due nodi e i pod possono essere eseguiti nei nodi di qualsiasi zona.

Un bilanciatore del carico indirizza il traffico a un cluster regionale che viene eseguito in tre zone. Ogni zona contiene due nodi.

In questa sezione simuli un errore di zona aggiornando il pool di nodi in modo che venga eseguito solo in due zone su tre. Questo approccio verifica che l'applicazione possa rispondere alla perdita di una zona ridistribuendo correttamente i pod e il traffico tra le altre zone.

Per aggiornare il pool di nodi in modo che venga eseguito solo in determinate zone e simulare un errore: compila i seguenti passaggi:

  1. Verifica la disponibilità dei cluster e dei servizi a livello di regione:

    kubectl get po -o wide \
    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    Il risultato è simile al seguente esempio di output:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   regional-cluster-1-default-pool-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   regional-cluster-1-default-pool-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   regional-cluster-1-default-pool-node2
    frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   regional-cluster-1-default-pool-node6
    ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   regional-cluster-1-default-pool-node1
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   regional-cluster-1-default-pool-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   regional-cluster-1-default-pool-node2
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   regional-cluster-1-default-pool-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   regional-cluster-1-default-pool-node1
    
    NAME                                    ZONE                INT_IP
    regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.6
    regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.7
    regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
    regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
    regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
    regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
    

    In questo esempio, tutti i carichi di lavoro di Cymbal Bank vengono dipartiti in tutte le zone. Per simulare un errore, disattiva una delle zone, ad esempio asia-southeast1-c, in cui è dipiegato il servizio frontend.

  2. Simula un'interruzione del servizio in una zona. Aggiorna il pool di nodi esistente (default-pool) in modo da specificare solo due zone su tre:

      gcloud container node-pools update default-pool \
        --cluster=CLUSTER_NAME \
        --node-locations=ZONE_A, ZONE_B \
        --region=REGION
    

    Sostituisci ZONE_A, ZONE_B con le due zone in cui vuoi che il pool di nodi continui a funzionare.

  3. Verifica la disponibilità dei microservizi dopo aver aggiornato il pool di nodi:

    kubectl get po -o wide
    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    L'output dovrebbe essere simile all'esempio seguente:

    NAME                                    ZONE                INT_IP
    regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
    regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
    regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
    regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
    
    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-default-pool-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-default-pool-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-default-pool-node2
    frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-default-pool-node3
    ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-default-pool-node1
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-default-pool-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-default-pool-node2
    transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-default-pool-node2
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-default-pool-node1
    

    In questo esempio di output, asia-southeast1-c non è più in uso. Il servizio frontend a cui accedi da un browser con l'URL http://EXTERNAL_IP è ancora accessibile. Un utente potrà comunque eseguire azioni di deposito e pagamento anche se una delle zone non è più disponibile.

Utilizzare un pool di nodi a zona singola

In questa sezione simuli un errore di zona eliminando due dei pool di nodi. Questo approccio verifica che la tua applicazione possa rispondere alla perdita di un pool di nodi ridistribuendo correttamente i pod e il traffico in un pool di nodi in un'altra zona. Per simulare un'interruzione di servizio in una zona in un cluster regionale, espandi il cluster di base creato in precedenza eseguendo l'applicazione Cymbal Bank su più pool di nodi. Questo metodo di simulazione dell'interruzione della zona riflette più da vicino un guasto effettivo della zona rispetto al primo esempio di aggiornamento delle zone attive in un pool di nodi, poiché è più comune che in un cluster esistano più pool di nodi:

Un bilanciatore del carico indirizza il traffico a un cluster regionale che viene eseguito su tre pool di nodi. Il pool di nodi predefinito viene eseguito in tutte le zone, mentre gli altri due vengono eseguiti ciascuno in una singola zona.

Il cluster che crei in questa sezione per simulare un errore del node pool a una zona include i seguenti componenti:

  • Pool di nodi predefinito, di solito creato quando crei un cluster GKE Standard regionale, ovvero un pool di nodi multizonale (default-pool).

    Questo cluster con il singolo default-pool è quello che hai creato in precedenza in questo documento.

  • Altri pool di nodi (zonal-node-pool-1 e zonal-node-pool-2) che eseguono anche servizi per l'applicazione di esempio Cymbal Bank.

Le linee tratteggiate nel diagramma mostrano come il traffico viene pubblicato solo in zonal-node-pool-2 dopo aver simulato un errore in default-pool e zonal-node-pool-1.

Per creare altri pool di nodi e simulare un errore, completa i seguenti passaggi:

  1. Verifica la disponibilità del cluster regionale:

    gcloud container node-pools list \
        --cluster=CLUSTER_NAME \
        --region REGION
    
    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    Il risultato è simile al seguente esempio di output:

    NAME: default-pool
    MACHINE_TYPE: e2-medium
    DISK_SIZE_GB: 100
    NODE_VERSION: 1.27.8-gke.1067004
    
    NAME                                         ZONE.               INT_IP
    regional-cluster-1-default-pool-node5-pzmc   asia-southeast1-c   10.148.0.6
    regional-cluster-1-default-pool-node6-qf1l   asia-southeast1-c   10.148.0.7
    regional-cluster-1-default-pool-node2-dlk2   asia-southeast1-a   10.148.0.8
    regional-cluster-1-default-pool-node1-pkfd   asia-southeast1-a   10.148.0.9
    regional-cluster-1-default-pool-node3-6b6n   asia-southeast1-b   10.148.0.5
    regional-cluster-1-default-pool-node4-h0lc   asia-southeast1-b   10.148.0.4
    

    In questo esempio di output, tutti i pod Cymbal Bank vengono di cuipiati in tutte le zone dello stesso cluster e vengono eseguiti nell'default-pool esistente.

  2. Crea due nuovi pool di nodi a zona singola:

    gcloud beta container node-pools create zonal-node-pool-1 \
      --cluster CLUSTER_NAME \
      --region REGION \
      --num-nodes 4 \
      --node-locations ZONE_A
    
    gcloud beta container node-pools create zonal-node-pool-2 \
        --cluster CLUSTER_NAME \
        --region REGION \
        --num-nodes 4 \
        --node-locations ZONE_B
    

    Sostituisci ZONE_A e ZONE_B con le due zone in cui vuoi eseguire i nuovi pool di nodi a zona singola.

  3. Per simulare un errore di una zona, elimina il pool di nodi regionale default-pool e uno dei nuovi node pool a zona singola:

    gcloud container node-pools delete default-pool \
        --cluster=CLUSTER_NAME \
        --region=REGION
    
    gcloud container node-pools delete zonal-node-pool-1 \
        --cluster=CLUSTER_NAME \
        --region=REGION
    

    Durante il processo di eliminazione di node-pool, i carichi di lavoro vengono arrestati e riprogrammati in un altro pool di nodi disponibile. Durante questa procedura, i servizi e le implementazioni non sono disponibili. Questo comportamento significa che è necessario specificare finestre di tempo di riposo per la generazione di report o la documentazione del piano di ripristino dei dati.

    Verifica la disponibilità continua dei microservizi:

    kubectl get po -o wide \
    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    L'output dovrebbe essere simile all'esempio seguente:

    NAME                                  ZONE                INT_IP
    regional-cluster-1-node-pool3-node1   asia-southeast1-b   10.148.0.8
    regional-cluster-1-node-pool3-node2   asia-southeast1-b   10.148.0.9
    regional-cluster-1-node-pool3-node3   asia-southeast1-b   10.148.0.5
    regional-cluster-1-node-pool3-node4   asia-southeast1-b   10.148.0.4
    
    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-zonal-node-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-zonal-node-pool-2-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-zonal-node-pool-2-node2
    frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-zonal-node-pool-2-node3
    ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-zonal-node-pool-2-node4
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-zonal-node-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-zonal-node-pool-2-node2
    transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-zonal-node-pool-2-node2
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-zonal-node-pool-2-node1
    

    In questo esempio di output, poiché default-pool e zonal-node-pool-1 non esistono più, tutti i servizi vengono eseguiti in zonal-node-pool-2.

Nodi di cordonamento e svuotamento in una zona

In questa sezione, isola e svuota nodi specifici del cluster. Isola e svuota tutti i nodi di una singola zona, simulando la perdita dei pod che vengono eseguiti su questi nodi nella zona:

Un bilanciatore del carico indirizza il traffico a un cluster regionale che viene eseguito in tre zone. Ogni zona contiene due nodi e i pod dell'applicazione di esempio Cymbal Bank vengono eseguiti in tutte le zone e su tutti i nodi.

In questo diagramma, isola e svuota i nodi nella prima zona. I nodi nelle altre due zone continuano a funzionare. Questo approccio verifica che la tua applicazione possa rispondere alla perdita di tutti i nodi di una zona ridistribuendo correttamente i pod e il traffico tra i nodi in esecuzione in altre zone.

Per mettere in isolamento e scaricare i nodi in una delle zone, simulando un errore, completa i seguenti passaggi:

  1. Verifica la disponibilità del cluster regionale e dei servizi. Esamina i nomi dei nodi della zona di errore del target. Vuoi specificare una zona in cui vengono eseguiti i pod frontend:

    kubectl get pods -o wide
    

    L'output dovrebbe essere simile all'esempio seguente:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
    accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node2
    balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node1
    contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
    frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node1
    ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node2
    ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
    ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
    loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node2
    transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
    userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node1
    
  2. Associa i pod elencati nell'output precedente alla zona del nodo:

    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    L'output dovrebbe essere simile all'esempio seguente:

    NAME                                    ZONE                INT_IP
    regional-cluster-1-default-pool-node1   asia-southeast1-b   10.148.0.41
    regional-cluster-1-default-pool-node2   asia-southeast1-b   10.148.0.42
    regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
    regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
    regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
    regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
    

    Nell'output dell'esempio precedente, i pod frontend si trovano in regional-cluster-1-default-pool-node1 nella zona asia-southeast1-b.

    Nel passaggio successivo, traccerai tutti i nodi nella zona asia-southeast1-b, che in questo output di esempio sono regional-cluster-1-default-pool-node1 e regional-cluster-1-default-pool-node2

  3. Isola e svuota i nodi target in una delle zone. In questo esempio, si tratta dei due nodi in asia-southeast1-b:

    kubectl drain regional-cluster-1-default-pool-node1 \
        --delete-emptydir-data --ignore-daemonsets
    
    kubectl drain regional-cluster-1-default-pool-node2 \
        --delete-emptydir-data --ignore-daemonsets
    

    Questo comando contrassegna i nodi come non pianificabili e simula i relativi errori. Kubernetes ripianifica i pod su altri nodi nelle zone funzionanti.

  4. Controlla dove sono stati riprogrammati i nuovi pod di frontend e altri pod di Cymbal Bank di esempio che precedentemente erano in esecuzione sul nodo nella zona di errore:

    kubectl get po -o wide
    kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    L'output dovrebbe essere simile all'esempio seguente:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
    accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node4
    balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node6
    contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
    frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node3
    ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node6
    ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
    ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
    loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node4
    transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
    userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node3
    
    NAME                                    ZONE                INT_IP
    regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
    regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
    regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
    regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
    

    In questo esempio di output, non sono presenti pod Cymbal Bank che vengono eseguiti su nodi messi in isolamento e tutti i pod ora vengono eseguiti solo nelle altre due zone.

    I budget di interruzione dei pod (PDB) sui nodi potrebbero bloccare lo svuotamento dei nodi. Valuta le norme relative ai PDB prima dell'azione di isolamento e svuotamento. Per scoprire di più su la PDB e sulla sua relazione con la gestione delle interruzioni, scopri come garantire l'affidabilità e il tempo di attività del tuo cluster GKE.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial:

Elimina il progetto

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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi