Questo insieme di tutorial è rivolto agli amministratori IT e agli operatori che vogliono eseguire il deployment, eseguire e gestire ambienti applicativi moderni eseguiti sulla versione Google Kubernetes Engine (GKE) Enterprise. Man mano che procedi in questo insieme di tutorial, imparerai a configurare monitoraggio e avvisi, scalare i carichi di lavoro e simulare errori, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:
- Crea un cluster ed esegui il deployment di un'applicazione di esempio
- Monitoraggio con Google Cloud Managed Service per Prometheus
- Scala i carichi di lavoro
- 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 di Cymbal Bank è progettata per gestire gli errori e continuare a essere eseguita, senza che tu debba occuparti della risoluzione dei problemi. Per offrire questa resilienza, i cluster a livello di regione GKE distribuiscono i nodi di computing tra le zone e il controller Kubernetes risponde automaticamente ai problemi dei servizi all'interno del cluster.
In questo tutorial imparerai a simulare un errore in Google Cloud e vedrai come rispondono i servizi dell'applicazione nel cluster della versione Google Kubernetes Engine (GKE) Enterprise. 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
L'abilitazione di GKE Enterprise e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano l'addebito di addebiti per cluster per GKE Enterprise su Google Cloud, come indicato nella nostra pagina Prezzi, fino a quando non disattivi GKE Enterprise o elimini il progetto.
Sei inoltre responsabile di altri costi di Google Cloud 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 utilizzi Autopilot ed eseguire il deployment dell'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 procedi 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 hanno tre o più zone. Ad esempio,
us-central1 corrisponde a una regione del Midwest degli Stati Uniti
che ha più zone, come 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 dotate di disponibilità elevata, Google consiglia di eseguire il deployment delle applicazioni in più zone e regioni. Questo approccio contribuisce a proteggere da guasti imprevisti dei componenti, fino a una zona o una regione inclusa.
Quando hai creato il tuo cluster GKE Enterprise nel primo tutorial, sono stati utilizzati alcuni valori di configurazione predefiniti. Per impostazione predefinita, un cluster GKE Enterprise che utilizza Autopilot crea ed esegue nodi distribuiti in diverse zone della regione specificata. Questo approccio significa che il deployment dell'applicazione di esempio Cymbal Bank è già stato eseguito in più zone, il che contribuisce a proteggere da errori imprevisti.
Controlla la distribuzione dei nodi nel tuo 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'output di esempio 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.4Controlla la distribuzione dei servizi delle applicazioni di esempio di Cymbal Bank nei nodi dei cluster GKE Enterprise:
kubectl get pods -o wideL'output di esempio riportato di seguito mostra che i servizi sono distribuiti tra i nodi nel cluster. Dal passaggio precedente per verificare come sono distribuiti i nodi, questo output mostra che i servizi vengono eseguiti in 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
Simula un'interruzione
Google progetta 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 sono più disponibili, vuoi che i servizi continuino a essere eseguiti su altri nodi o in zone nella 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 instradato ai nodi funzionanti.
Per simulare un'interruzione in questo tutorial, contrassegna e svuota i nodi in una delle tue zone. Questo approccio simula ciò che accade quando si verifica un errore di un nodo o quando si verifica un problema in un'intera zona. Il controller Kubernetes dovrebbe riconoscere che alcuni servizi non sono più disponibili e deve essere riavviato sui nodi in altre zone:
Non disturbare e svuotare 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-daemonsetsQuesto 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 nelle zone funzionali.
Controlla la risposta all'errore simulata
In un tutorial precedente di questa serie, hai imparato a configurare l'istanza Prometheus gestita per il tuo cluster GKE Enterprise al fine di monitorare alcuni dei servizi 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 dagli avvisi generati da Prometheus. Questo comportamento mostra come creare un ambiente applicativo moderno che monitori l'integrità dei tuoi deployment, ti avvisa in caso di problemi e può adattarsi automaticamente in caso di modifiche al carico o errori.
Il cluster GKE Enterprise risponde automaticamente all'interruzione simulata. Tutti i servizi sui nodi interessati vengono riavviati sui nodi rimanenti.
Controlla di nuovo 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'output di esempio seguente, che mostra che i nodi ora sono distribuiti solo in due 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.4Il controller Kubernetes riconosce che due nodi non sono più disponibili e ridistribuisce i servizi tra i nodi disponibili. Tutti i servizi dovrebbero continuare a essere eseguiti.
Controlla la distribuzione dei servizi delle applicazioni di esempio di Cymbal Bank nei nodi dei cluster GKE Enterprise:
kubectl get pods -o wideL'output di esempio seguente mostra che i servizi sono distribuiti tra i nodi rimanenti nel cluster. Dal passaggio precedente per verificare come sono distribuiti i nodi, questo output mostra che ora i servizi vengono eseguiti solo su due zone nella 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-node1Guarda i
AGEdei Servizi. Nell'output di esempio precedente, alcuni servizi hanno un'età inferiore rispetto ad altri nell'applicazione di esempio di Cymbal Bank. In precedenza, questi servizi più recenti venivano eseguiti su uno dei nodi in cui si simulava l'errore. Il controller Kubernetes ha riavviato questi servizi sui nodi disponibili.
In uno scenario reale, dovresti risolvere il problema o attendere che venga risolto il problema di manutenzione sottostante. Se hai configurato Prometheus per l'invio di messaggi Slack in base agli avvisi, riceverai queste notifiche. Puoi anche facoltativamente ripetere i passaggi del tutorial precedente per scalare le risorse per vedere come il tuo cluster GKE Enterprise risponde con un carico maggiore quando sono disponibili solo due zone con la regione. Il cluster dovrebbe fare lo scale up 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.
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
Prima di iniziare a creare il tuo ambiente cluster GKE Enterprise simile a quello che hai imparato in questa serie di tutorial, rivedi alcune considerazioni sulla produzione.