Percorso di apprendimento: applicazioni scalabili - Simula un errore


Questo insieme di tutorial è rivolto a operatori e amministratori IT che vogliono distribuire, eseguire e gestire ambienti di applicazioni moderne che vengono eseguiti su Google Kubernetes Engine (GKE). Man mano che avanzi in questo insieme di tutorial, imparerai a configurare il monitoraggio e gli avvisi, a scalare i carichi di lavoro e a simulare errori, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

  1. Crea un cluster ed esegui il deployment di un'applicazione di esempio
  2. Monitoraggio con Google Cloud Managed Service per Prometheus
  3. Scalare i workload
  4. Simula un errore (questo tutorial)

Panoramica e obiettivi

Le applicazioni devono essere in grado di tollerare interruzioni e guasti. Questa funzionalità consente agli utenti di continuare ad accedere alle tue applicazioni anche in caso di problemi. L'applicazione di esempio Cymbal Bank è progettata per gestire gli errori e continuare a funzionare, senza che tu debba risolvere i problemi e correggere gli errori. Per fornire questa resilienza, i cluster regionali GKE distribuiscono i nodi di calcolo tra le zone e il controller Kubernetes risponde automaticamente ai problemi di servizio all'interno del cluster.

In questo tutorial, imparerai a simulare un errore in Google Cloud e a vedere come rispondono i servizi applicativi nel cluster GKE. Imparerai a completare le seguenti attività:

  • Rivedi la distribuzione di nodi e servizi.
  • Simula un errore del nodo o della zona.
  • Verifica che i servizi continuino a essere eseguiti nei nodi rimanenti.

Costi

L'attivazione di GKE e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano addebiti per cluster per GKE su Google Cloud , come indicato nella nostra pagina dei prezzi, fino a quando non disattivi GKE o elimini il progetto.

Sei responsabile anche di altri Google Cloud costi sostenuti durante l'esecuzione dell'applicazione di esempio Cymbal Bank, ad esempio gli addebiti per le VM di Compute Engine.

Prima di iniziare

Per scoprire come simulare un errore, devi completare il primo tutorial per creare un cluster GKE che utilizza Autopilot ed eseguire il deployment dell'applicazione di esempio basata su microservizi Cymbal Bank.

Ti consigliamo di completare questa serie di tutorial per le app scalabili in ordine. Man mano che avanzi nella serie di tutorial, acquisisci nuove competenze e utilizzi prodotti e servizi Google Cloud aggiuntivi.

Rivedi la distribuzione di nodi e servizi

In Google Cloud, una regione è una posizione geografica specifica in cui puoi ospitare le tue risorse. Le regioni includono tre o più zone. Ad esempio, la regione us-central1 corrisponde a una regione nel Midwest degli Stati Uniti che è composta da più zone, ad esempio us-central1-a, us-central1-b e us-central1-c. Le zone hanno connessioni di rete a bassa latenza e a larghezza di banda elevata con altre zone della stessa regione.

Per eseguire il deployment di applicazioni a tolleranza di errore con disponibilità elevata, Google consiglia di eseguire il deployment delle applicazioni in più zone e più regioni. Questo approccio aiuta a proteggere da guasti imprevisti dei componenti, fino a una zona o una regione inclusa.

Quando hai creato il cluster GKE nel primo tutorial, sono stati utilizzati alcuni valori di configurazione predefiniti. Per impostazione predefinita, un cluster GKE che utilizza Autopilot crea ed esegue nodi che si estendono su più zone della regione specificata. Questo approccio significa che l'applicazione di esempio Cymbal Bank è già implementata in più zone, il che contribuisce a proteggere da guasti imprevisti.

  1. Controlla la distribuzione dei nodi nel cluster GKE:

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

    Il risultato è simile al seguente output di esempio che mostra che i nodi sono distribuiti in tutte e tre le zone della regione:

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node2   us-central1-a   10.148.0.8
    scalable-apps-pool-2-node1   us-central1-a   10.148.0.9
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. Controlla la distribuzione dei servizi dell'applicazione di esempio Cymbal Bank nei nodi del cluster GKE:

    kubectl get pods -o wide
    

    L'output di esempio seguente mostra che i servizi sono distribuiti tra i nodi del cluster. Dal passaggio precedente per verificare la distribuzione dei nodi, questo output mostra che i servizi vengono eseguiti nelle zone della regione:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   scalable-apps-pool-2-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   scalable-apps-pool-2-node2
    frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   scalable-apps-pool-2-node1
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   scalable-apps-pool-2-node2
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   scalable-apps-pool-2-node1
    

Simulare un'interruzione del servizio

Google progetta le zone per ridurre al minimo il rischio di errori correlati causati da interruzioni dell'infrastruttura fisica come alimentazione, raffreddamento o networking. Tuttavia, possono verificarsi problemi imprevisti. Se un nodo o una zona non è più disponibile, vuoi che i servizi continuino a essere eseguiti su altri nodi o in zone della stessa regione.

Il controller Kubernetes monitora lo stato di nodi, servizi e deployment nel cluster. In caso di interruzione imprevista, il controller riavvia le risorse interessate e il traffico viene indirizzato ai nodi funzionanti.

Per simulare un'interruzione in questo tutorial, isola e svuota i nodi in una delle tue zone. Questo approccio simula ciò che accade quando un nodo non funziona o quando si verifica un problema in un'intera zona. Il controller Kubernetes dovrebbe riconoscere che alcuni servizi non sono più disponibili e devono essere riavviati sui nodi in altre zone:

  • Isola e svuota i nodi in una delle zone. L'esempio seguente ha come target i due nodi in us-central1-a:

    kubectl drain scalable-apps-pool-2-node1 \
        --delete-emptydir-data --ignore-daemonsets
    
    kubectl drain scalable-apps-pool-2-node2 \
        --delete-emptydir-data --ignore-daemonsets
    

    Questo comando contrassegna i nodi come non pianificabili in modo che i pod non possano più essere eseguiti su questi nodi. Kubernetes ripianifica i pod su altri nodi nelle zone funzionanti.

Controllare la risposta all'errore simulato

In un tutorial precedente di questa serie, hai imparato a configurare l'istanza Prometheus gestita per il tuo cluster GKE per monitorare alcuni servizi e generare avvisi in caso di problemi. Se i pod erano in esecuzione sui nodi nella zona in cui hai simulato un'interruzione, riceverai messaggi di notifica Slack dagli avvisi generati da Prometheus. Questo comportamento mostra come creare un ambiente applicativo moderno che monitora l'integrità dei tuoi deployment, ti avvisa in caso di problemi e può essere regolato automaticamente in base a variazioni di carico o errori.

Il cluster GKE risponde automaticamente all'interruzione simulata. Tutti i servizi sui nodi interessati vengono riavviati sui nodi rimanenti.

  1. Controlla di nuovo la distribuzione dei nodi nel tuo cluster GKE:

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

    Il risultato è simile al seguente output di esempio che mostra che i nodi ora sono distribuiti solo su due delle zone della regione:

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. Il controller Kubernetes riconosce che due dei nodi non sono più disponibili e ridistribuisce i servizi tra i nodi disponibili. Tutti i servizi devono continuare a essere eseguiti.

    Controlla la distribuzione dei servizi dell'applicazione di esempio Cymbal Bank nei nodi del cluster GKE:

    kubectl get pods -o wide
    

    L'output di esempio seguente mostra che i servizi sono distribuiti tra i nodi rimanenti del cluster. Dal passaggio precedente per controllare la distribuzione dei nodi, questo output mostra che i servizi ora vengono eseguiti solo in due zone della regione:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          28m     10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          9m21s   10.28.5.6   scalable-apps-pool-2-node5
    contacts-7ddc76d94-qv4x5              1/1     Running   0          9m20s   10.28.4.6   scalable-apps-pool-2-node4
    frontend-747b84bff4-xvjxq             1/1     Running   0          28m     10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          9m24s   10.28.5.7   scalable-apps-pool-2-node3
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          9m21s   10.28.4.7   scalable-apps-pool-2-node5
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          28m     10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          9m20s   10.28.5.8   scalable-apps-pool-2-node1
    
  3. Consulta la sezione AGE dei Servizi. Nell'output dell'esempio precedente, alcuni servizi hanno un'età inferiore rispetto ad altri nell'applicazione di esempio Cymbal Bank. Questi servizi più recenti venivano eseguiti su uno dei nodi in cui hai simulato l'errore. Il controller Kubernetes ha riavviato questi servizi sui nodi disponibili.

In uno scenario reale, risolveresti il problema o attenderesti la risoluzione del problema di manutenzione sottostante. Se hai configurato Prometheus per inviare messaggi Slack in base agli avvisi, vedrai queste notifiche. Puoi anche ripetere facoltativamente i passaggi del tutorial precedente per scalare le risorse per vedere come risponde il cluster GKE con un carico maggiore quando sono disponibili solo due zone nella regione. Il cluster deve essere scalato con le due zone rimanenti disponibili.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che hai creato.

  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

Prima di iniziare a creare il tuo ambiente cluster GKE simile a quello che hai imparato in questo insieme di tutorial, esamina alcune considerazioni sulla produzione.