Percorso di apprendimento: Applicazioni scalabili - Simula un errore


Questo insieme di tutorial è rivolto agli amministratori IT e agli operatori che vogliono per eseguire il deployment, eseguire e gestire ambienti applicativi moderni in esecuzione Google Kubernetes Engine (GKE) Enterprise. Man mano che avanzi in questo insieme di tutorial, imparerai come configurare il monitoraggio e gli avvisi, scalare i carichi di lavoro e simulare i guasti, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

  1. Creare un cluster ed eseguire il deployment di un'applicazione di esempio
  2. Monitoraggio con Google Cloud Managed Service per Prometheus
  3. Scalabilità dei carichi di lavoro
  4. Simulare un errore (questo tutorial)
  5. Centralizza la gestione dei cambiamenti

Panoramica e obiettivi

Le applicazioni devono essere in grado di tollerare interruzioni e guasti. Questa funzionalità consente gli utenti continuano ad accedere alle tue applicazioni anche quando si verifica un problema. L'applicazione di esempio Cymbal Bank è progettata per gestire gli errori e continuare a funzionare, senza che tu debba risolvere i problemi. Per fornire resilienza, i cluster a livello di regione di GKE distribuiscono i nodi di computing 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 di applicazione nel cluster Google Kubernetes Engine (GKE) Enterprise Edition. Imparerai a completare le attività seguenti:

  • Rivedere la distribuzione di nodi e servizi.
  • Simula un errore di un nodo o di una zona.
  • Verifica che i servizi continuino a essere eseguiti sui nodi rimanenti.

Costi

Se attivi GKE Enterprise e esegui il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial, dovrai sostenere costi per GKE Enterprise su Google Cloud per ogni cluster, come indicato nella nostra pagina dei prezzi, finché non disattivi GKE Enterprise o non elimini il progetto.

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

Prima di iniziare

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

Ti consigliamo di completare questo insieme di tutorial per Cymbal Bank in ordine. Man mano che avanzi nella serie di tutorial, acquisisci nuove competenze e utilizzi altri prodotti e servizi Google Cloud.

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 indica una regione del Midwest degli Stati Uniti con 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 in più regioni. Questo approccio contribuisce a proteggere da guasti imprevisti dei componenti, fino a una zona o una regione incluse.

Quando hai creato il tuo cluster GKE Enterprise nel corso sono stati utilizzati alcuni valori di configurazione predefiniti. Per impostazione predefinita, un cluster GKE Enterprise che utilizza Autopilot crea esegue nodi distribuiti in più zone della regione specificata. Questo significa che è già stato eseguito il deployment dell'applicazione di esempio di Cymbal Bank in più zone, per proteggerti da guasti imprevisti.

  1. Controlla la distribuzione dei nodi nel cluster GKE Enterprise:

    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 all'esempio di output seguente 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 di Cymbal Bank su dei nodi dei cluster GKE Enterprise:

    kubectl get pods -o wide
    

    L'output di esempio seguente mostra che i servizi sono distribuiti tra nodi nel cluster. Dal passaggio precedente per verificare come sono distribuiti, questo output mostra che i servizi vengono eseguiti in zone 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 zone per ridurre al minimo il rischio di errori correlati causati da e interruzioni dell'infrastruttura fisica, ad esempio di alimentazione, raffreddamento o networking. Tuttavia, possono verificarsi problemi imprevisti. Se un nodo o una zona non sono più disponibili, I servizi continueranno a essere eseguiti su altri nodi o in zone nella stessa regione.

Il controller Kubernetes monitora lo stato di nodi, servizi e deployment nel tuo cluster. Se si verifica un'interruzione imprevista, riavvia le risorse interessate e il traffico viene indirizzato ai nodi funzionanti.

Per simulare un'interruzione in questo tutorial, contrassegna e svuota i nodi in uno dei le tue zone. Questo approccio simula cosa succede quando un nodo si guasta o quando si verifica un problema in un'intera zona. Il controller Kubernetes deve riconoscere che alcune I servizi non sono più disponibili e devono essere riavviati sui nodi in altre zone:

  • Isola e scollega 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 in altri nodi in funzione zone.

Controlla la risposta all'errore simulata

In un tutorial precedente di questa serie, hai imparato a configurare l'istanza Prometheus gestita il cluster GKE Enterprise per monitorare alcuni servizi e e generare avvisi in caso di problemi. Se i pod erano in esecuzione su nodi nella zona in cui hai simulato un'interruzione, ricevi messaggi di notifica di Slack generati da Prometheus. Questo comportamento mostra come creare un modello che monitora l'integrità dei tuoi deployment, ti avvisa se c'è un problema e può adattarsi automaticamente alle modifiche o agli errori del caricamento.

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

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

    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 all'esempio di output seguente che mostra che i nodi ora sono distribuiti solo in 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 nodi non sono più disponibili e ridistribuisce i servizi tra i nodi disponibili. Tutte le I servizi dovrebbero continuare a funzionare.

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

    kubectl get pods -o wide
    

    L'esempio di output seguente mostra che i servizi sono distribuiti tra i nodi rimanenti del cluster. Dal passaggio precedente per controllare come di nodi sono distribuiti, questo output mostra che ora i servizi vengono eseguiti 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. Guarda i AGE dei Servizi. Nell'output di esempio precedente, alcune delle i Servizi hanno un'età inferiore a quella degli altri partecipanti nel campione di Cymbal Bank un'applicazione. In precedenza, questi servizi più recenti venivano eseguiti su uno dei nodi in cui hai simulato l'errore. Il controller Kubernetes ha riavviato questi servizi in data nodi disponibili.

In uno scenario reale, dovresti risolvere il problema o attendere la risoluzione del problema di manutenzione di fondo. Se hai configurato Prometheus per inviare Slack in base agli avvisi, riceverai queste notifiche. Se vuoi, puoi anche ripetere i passaggi del tutorial precedente per scalare le risorse per vedere come il tuo cluster GKE Enterprise risponde con un aumento del caricamento quando nella regione sono disponibili solo due zone. Il cluster dovrebbe eseguire il ridimensionamento con le due zone rimanenti disponibili.

Esegui la pulizia

L'insieme di tutorial per Cymbal Bank è pensato per essere completato uno dopo il e l'altro. Man mano che procedi nella serie di tutorial, acquisisci nuove competenze e per utilizzare altri prodotti e servizi Google Cloud.

Se vuoi fare una pausa prima di passare al tutorial successivo ed 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

Scopri come centralizza la gestione dei cambiamenti con Config Sync nel prossimo tutorial.