Questo insieme di tutorial è rivolto a operatori e amministratori IT che vogliono eseguire il deployment, eseguire e gestire ambienti di applicazioni moderne che vengono eseguiti su Google Kubernetes Engine (GKE). Man mano che procedi con questo insieme di tutorial, imparerai a configurare il monitoraggio e gli avvisi, a scalare i carichi di lavoro e a simulare un errore, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:
- Crea un cluster ed esegui il deployment di un'applicazione di esempio
- Monitora con Google Cloud Managed Service per Prometheus
- Scala i carichi di lavoro
- Simula un errore (questo tutorial)
- Centralizza la gestione dei cambiamenti
Panoramica e obiettivi
Le applicazioni devono essere in grado di tollerare interruzioni ed errori. Questa capacità 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 essere eseguita, senza che tu debba risolvere i problemi e correggerli. Per fornire questa resilienza, i cluster regionali GKE distribuiscono i nodi di calcolo tra le zone e il controller Kubernetes risponde automaticamente ai problemi del servizio all'interno del cluster.
In questo tutorial imparerai a simulare un errore in Google Cloud e a vedere come rispondono i servizi dell'applicazione nel cluster GKE. Imparerai a completare le seguenti attività:
- Esamina la distribuzione di nodi e servizi.
- Simula un errore del nodo o della zona.
- Verifica che i servizi continuino a essere eseguiti sui nodi rimanenti.
Costi
L'abilitazione di GKE e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano addebiti per cluster per GKE on Google Cloud premise, come indicato nella nostra pagina dei prezzi finché non disabiliti GKE o elimini il progetto.
Sei anche responsabile 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 imparare a 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 Cymbal Bank.
Ti consigliamo di completare questa serie di tutorial per le app scalabili in ordine. Man mano che procedi con la serie di tutorial, imparerai nuove competenze e utilizzerai altri Google Cloud prodotti e servizi.
Esamina 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 nel 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 ad alta affidabilità, Google consiglia di eseguire il deployment delle applicazioni in più zone e regioni. Questo approccio aiuta a proteggere da guasti imprevisti dei componenti, anche di una zona o regione.
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 tra le zone della regione specificata. Questo approccio significa che l'applicazione di esempio Cymbal Bank è già sottoposta a deployment in più zone, il che aiuta a proteggere da guasti imprevisti.
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 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 dell'applicazione di esempio Cymbal Bank nei nodi del cluster GKE:
kubectl get pods -o wideL'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 tra le 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 del servizio
Google progetta le zone per ridurre al minimo il rischio di guasti correlati causati da interruzioni dell'infrastruttura fisica, ad esempio di corrente, raffreddamento o rete. 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 instradato ai nodi funzionanti.
Per simulare un'interruzione del servizio 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 di 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-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 su altri nodi nelle zone funzionanti.
Controlla la risposta all'errore simulato
In un tutorial precedente di questa serie, hai imparato a configurare l'istanza di Prometheus gestita per il tuo cluster GKE in modo da monitorare alcuni dei servizi e generare avvisi in caso di problemi. Se i pod erano in esecuzione sui nodi della zona in cui hai simulato un'interruzione del servizio, riceverai messaggi di notifica di Slack dagli avvisi generati da Prometheus. Questo comportamento mostra come puoi creare un ambiente di applicazioni moderno che monitora l'integrità dei deployment, ti avvisa in caso di problemi e può adattarsi automaticamente alle modifiche o agli errori di carico.
Il cluster GKE risponde automaticamente all'interruzione del servizio simulata. Tutti i servizi sui nodi interessati vengono riavviati sui nodi rimanenti.
Controlla di nuovo 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 all'output di esempio seguente, che mostra che i nodi sono ora 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.4Il controller Kubernetes riconosce che due dei 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 dell'applicazione di esempio Cymbal Bank nei nodi del cluster GKE:
kubectl get pods -o wideL'output di esempio seguente mostra che i servizi sono distribuiti tra i nodi rimanenti del cluster. Dal passaggio precedente per verificare la distribuzione dei nodi, questo output mostra che i servizi 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-node1Esamina l'
AGEdei servizi. Nell'output di esempio precedente, alcuni dei servizi hanno un'età inferiore rispetto ad altri nell'applicazione di esempio Cymbal Bank. Questi servizi più recenti venivano eseguiti in precedenza su uno dei nodi in cui hai simulato un errore. Il controller Kubernetes ha riavviato questi servizi sui nodi disponibili.
In uno scenario reale, dovresti risolvere il problema o attendere 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 e vedere come risponde il cluster GKE con un carico maggiore quando sono disponibili solo due zone nella regione. Il cluster dovrebbe eseguire lo scale up con le due zone rimanenti disponibili.
Libera spazio
Per evitare che al tuo Google Cloud account vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che hai creato.
- Nella Google Cloud console, 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 progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
Nel prossimo tutorial imparerai a centralizzare la gestione dei cambiamenti con Config Sync.