Google Distributed Cloud è progettato per limitare l'ambito degli errori e dare la priorità alle funzionalità fondamentali per la continuità aziendale. Questo documento spiega in che modo la funzionalità dei tuoi cluster è interessata in caso di errore. Queste informazioni possono aiutarti a stabilire le priorità delle aree da risolvere in caso di problemi.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.
Le funzionalità di base di Google Distributed Cloud includono le seguenti categorie:
- Esegui carichi di lavoro: i carichi di lavoro esistenti possono continuare a essere eseguiti. Questo è il considerazione più importante per mantenere la continuità aziendale. Anche se il cluster ha un problema, i carichi di lavoro esistenti potrebbero continuare a funzionare senza interruzione.
- Gestisci i carichi di lavoro: puoi creare, aggiornare ed eliminare i carichi di lavoro. Questo è il secondo aspetto più importante da considerare per scalare i carichi di lavoro quando il traffico aumenta, anche se il cluster ha un problema.
- Gestire i cluster utente: puoi gestire i nodi, aggiornare, eseguire l'upgrade ed eliminare i cluster utente. Questo aspetto è meno importante rispetto alle considerazioni sul ciclo di vita dell'applicazione. Se la capacità è disponibile sui nodi esistenti, l'impossibilità di modificare i cluster di utenti non influisce sui carichi di lavoro degli utenti.
- Gestisci i cluster di amministrazione: puoi aggiornare ed eseguire l'upgrade del cluster di amministrazione.
- Per i deployment che utilizzano cluster di amministrazione e utente separati, questa è la considerazione meno importante perché il cluster di amministrazione non ospita carichi di lavoro degli utenti. Se si verifica un problema con il cluster di amministrazione, i carichi di lavoro delle applicazioni su altri cluster continuano a funzionare senza interruzioni.
- Se utilizzi altri modelli di deployment, ad esempio ibrido o autonomo, il cluster amministrativo esegue i carichi di lavoro delle applicazioni. Se il cluster di amministrazione ha un problema e il piano di controllo non è attivo, non puoi nemmeno gestire i carichi di lavoro delle applicazioni o i componenti del cluster utente.
Le sezioni seguenti utilizzano queste categorie di funzionalità di base per descrivere l'impatto di tipi specifici di scenari di errore. Quando si verifica un'interruzione nell'ambito di uno scenario di guasto, se possibile viene annotata anche la durata (ordine) dell'interruzione.
Errori del nodo
Un nodo in Google Distributed Cloud potrebbe smettere di funzionare o diventare irraggiungibile sulla rete. A seconda del pool di nodi e del cluster di cui fa parte la macchina in stato di errore, esistono diversi modi di errore.
Nodo piano di controllo
La tabella seguente illustra il comportamento dei nodi che fanno parte del piano di controllo in Google Distributed Cloud:
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Nessuna interruzione | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) |
Spiegazione | — | Se l'errore del nodo interessa il nodo del control plane singolo in un cluster utente non ad alta disponibilità (HA) o se interessa almeno la metà dei nodi del control plane in un cluster utente ad alta disponibilità, si verifica un'interruzione. Il quorum del piano di controllo del cluster utente è andato perso. | Se l'errore del nodo interessa il nodo del piano di controllo singolo in un cluster di amministrazione non ad alta disponibilità o se interessa almeno la metà dei nodi del piano di controllo in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster di amministrazione è andato perso. | Se il malfunzionamento del nodo interessa il nodo del piano di controllo singolo in un cluster di amministrazione non ad alta disponibilità o se interessa almeno la metà dei nodi del piano di controllo in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster di amministrazione è andato perso. |
Recupero | — | Per ulteriori informazioni, consulta come recuperare da una perdita del quorum. | Per ulteriori informazioni, consulta come recuperare da una perdita del quorum. | Per ulteriori informazioni, consulta come recuperare da una perdita del quorum. |
Prevenzione | — | Esegui il deployment dei cluster utente in modalità HA per ridurre al minimo la possibilità di interruzione. | Esegui il deployment dei cluster di amministrazione in modalità HA per ridurre al minimo la possibilità di interruzione. | Esegui il deployment dei cluster di amministrazione in modalità HA per ridurre al minimo la possibilità di interruzione. |
Nodo del bilanciatore del carico
La tabella seguente illustra il comportamento dei nodi che ospitano i bilanciatori del carico in Google Distributed Cloud. Queste indicazioni si applicano solo ai bilanciatori del carico in bundle con modalità di livello 2. Per il bilanciamento del carico manuale, consulta le modalità di errore dei bilanciatori del carico esterni:
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Possibile interruzione (varia) | Possibile interruzione (varia) | Possibile interruzione (varia) | Possibile interruzione (varia) |
Spiegazione | Se i carichi di lavoro esterni si basano sul bilanciatore del piano dati per comunicare con i carichi di lavoro nel cluster e hai un solo nodo del bilanciatore, si verifica un'interruzione. | L'indirizzo IP virtuale del control plane del cluster utente si trova su un nodo del bilanciatore del carico. Se il pool di nodi del bilanciatore del carico del cluster utente non è ad alta disponibilità, si verifica un'interruzione. | L'indirizzo IP virtuale del control plane del cluster di amministrazione si trova su un nodo del bilanciatore del carico. Se il pool di nodi del bilanciatore del carico del cluster di amministrazione non è ad alta disponibilità, si verifica un'interruzione. | L'indirizzo IP virtuale del control plane del cluster di amministrazione si trova su un nodo del bilanciatore del carico. Se il pool di nodi del bilanciatore del carico del cluster di amministrazione non è ad alta disponibilità, si verifica un'interruzione. |
Recupero | Se sono presenti più nodi del bilanciatore del carico, il failover di MetalLB avviene entro pochi secondi. Se non è HA, valuta la possibilità di implementare nodi di bilanciamento del carico aggiuntivi. |
Se è attivo il failover, il failover è automatico e richiede pochi secondi. Se non è HA, valuta la possibilità di implementare nodi di bilanciamento del carico aggiuntivi |
Se è attivo il failover, il failover è automatico e richiede pochi secondi. Se non è HA, valuta la possibilità di implementare nodi di bilanciamento del carico aggiuntivi. |
Se è attivo il failover, il failover è automatico e richiede pochi secondi. Se non è HA, valuta la possibilità di implementare nodi di bilanciamento del carico aggiuntivi. |
Prevenzione | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei pool di nodi bilanciatori del carico in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei pool di nodi bilanciatori del carico in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei pool di nodi bilanciatori del carico in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei pool di nodi bilanciatori del carico in modalità HA. |
Nodo worker
La tabella seguente illustra il comportamento dei nodi worker in Google Distributed Cloud:
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Possibile interruzione (nell'ordine di secondi) | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
Spiegazione | I Se le applicazioni utente dispongono di capacità di carico di lavoro di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i tentativi di nuovo invio. I |
— | — | — |
Recupero | Se il cluster non dispone di capacità di riserva, devi implementare più nodi distribuiti su più zone di errore e spostare i workload non riusciti sui nuovi nodi. | — | — | — |
Prevenzione | Esegui il deployment di nodi distribuiti su più zone di errore. Esegui il deployment dei carichi di lavoro con più repliche distribuite su più zone di errore per ridurre al minimo la possibilità di interruzione. |
— | — | — |
Errore di archiviazione
Lo spazio di archiviazione in Google Distributed Cloud potrebbe smettere di funzionare o diventare irraggiungibile sulla rete. A seconda dello spazio di archiviazione che non funziona, esistono diverse modalità di errore.
etcd
I contenuti delle directory /var/lib/etcd
e /var/lib/etcd-events
potrebbero essere danneggiati se si verifica un arresto anomalo del nodo o un errore di archiviazione sottostante. La tabella seguente illustra il comportamento della funzionalità di base a causa di errori etcd
:
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Nessuna interruzione | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) |
Spiegazione | Se i carichi di lavoro esistenti non si basano sul piano di controllo Kubernetes, continuano a funzionare senza interruzioni. | Se etcd non funziona in un singolo cluster utente con piano di controllo o
non funziona in almeno la metà dei nodi del piano di controllo in un cluster utente ad alta disponibilità, si verifica un'interruzione. Il quorum del piano di controllo del
cluster utente viene perso. |
Se etcd non funziona in un singolo cluster di amministrazione del piano di controllo o su almeno la metà dei nodi del piano di controllo in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del piano di controllo del
cluster di amministrazione è andato perso. |
Se etcd non funziona in un singolo cluster di amministrazione del piano di controllo o su almeno la metà dei nodi del piano di controllo in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del piano di controllo del
cluster di amministrazione è andato perso. |
Recupero | — | Per ulteriori informazioni, consulta come recuperare da una perdita del quorum. | Per ulteriori informazioni, consulta come recuperare da una perdita del quorum. | Per ulteriori informazioni, consulta come recuperare da una perdita del quorum. |
Prevenzione | — | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei cluster utente in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei cluster di amministrazione in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei cluster di amministrazione in modalità HA. |
Applicazione utente PersistentVolume
La tabella seguente illustra il comportamento della funzionalità di base a causa del fallimento di un PersistentVolume
:
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Possibile interruzione (sconosciuto) | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
Spiegazione | I workload che utilizzano PersistentVolume non riuscito |
— | — | — |
Recupero | — | — | — | — |
Prevenzione | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment del carico di lavoro utente in modalità HA. | — | — | — |
Disco Fluent Bit danneggiato
La corruzione di un disco Fluent Bit non influisce sulle funzionalità di base, ma incide sulla capacità di raccogliere e ispezionare i log su Google Cloud.
A volte l'evento SIGSEGV
può essere osservato dai log di
stackdriver-log-forwarder
. Questo errore potrebbe essere causato da log bufferizzati danneggiati sul disco.
Fluent Bit ha un meccanismo per filtrare ed eliminare i chunk danneggiati. Questa funzionalità è disponibile nella versione di fluent-bit (v1.8.3) utilizzata in Google Distributed Cloud.
IP di LoadBalancer
Se tutti gli indirizzi IP nei pool assegnati sono attualmente occupati, i servizi LoadBalancer
appena creati non possono acquisire un indirizzo IP LoadBalancer
. Questo
scenario influisce sulla capacità dei clienti del servizio di comunicare con i servizi
LoadBalancer
.
Per recuperare da questo esaurimento degli indirizzi IP, assegna più indirizzi IP al pool di indirizzi modificando la risorsa personalizzata del cluster.
Scadenza del certificato
Google Distributed Cloud genera un'autorità di certificazione (CA) autofirmata durante la procedura di installazione del cluster. La CA ha una scadenza di 10 anni ed è responsabile della generazione dei certificati, che scadono dopo un anno. Ruota i certificati regolarmente per evitare i tempi di riposo del cluster. Puoi ruotare i certificati eseguendo l'upgrade del cluster, che è il metodo consigliato. Se non riesci ad eseguire l'upgrade del cluster, puoi eseguire una rotazione dei certificati CA on demand. Per ulteriori informazioni sui certificati del cluster, consulta Requisiti e certificati PKI nella documentazione di Kubernetes.
Se i certificati del cluster sono scaduti, devono essere rinnovati manualmente.
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Nessuna interruzione | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) |
Spiegazione | Se i carichi di lavoro utente non comunicano con i componenti del piano di controllo Kubernetes, non ci saranno interruzioni. | Se le autorità di certificazione per i cluster utente scadono, si verificherà un'interruzione. | Se le autorità di certificazione per i cluster di amministrazione scadono, si verificherà un'interruzione. | Se le autorità di certificazione per i cluster utente scadono, si verificano interruzione. |
Recupero | — | Segui i passaggi per rinnovare manualmente i certificati sul cluster di utenti. |
Segui i passaggi per rinnovare manualmente i certificati sul cluster di utenti. |
Segui i passaggi per rinnovare manualmente i certificati sul cluster di utenti. |
Prevenzione | Configura i monitor per la scadenza dei certificati. Un esempio
di metrica kubelet_certificate_manager_server_expiration_seconds è disponibile nell'elenco delle metriche. |
Errori di upgrade
Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
---|---|---|---|---|
Interruzioni (durata) | Nessuna interruzione | Nessuna interruzione | Possibile interruzione (sconosciuto) | Possibile interruzione (sconosciuto) |
Spiegazione | Se l'upgrade non riesce nel piano di controllo del cluster utente, NON viene interrotta l'attività dei carichi di lavoro esistenti. Se l'upgrade non va a buon fine su un determinato nodo worker, i carichi di lavoro su quel nodo verranno svuotati e spostati su altri nodi integri se questi dispongono di capacità aggiuntiva. |
L'upgrade verrà interrotto se non riesce su uno dei nodi del piano di controllo. Il cluster è ancora funzionale se l'upgrade non riesce se il cluster utente è ad alta disponibilità. | Se l'upgrade non riesce nel piano di controllo del cluster di amministrazione, si verifica un'interruzione fino al termine dell'upgrade. | Se l'upgrade non riesce nel piano di controllo del cluster di amministrazione, si verifica un'interruzione fino al termine dell'upgrade. |
Recupero | — | — | L'upgrade può essere ripetuto. Per ulteriori informazioni, scopri come diagnosticare i problemi di upgrade e riprendere. | L'upgrade può essere ripetuto. Per ulteriori informazioni, scopri come diagnosticare i problemi di upgrade e riprendere. |
Prevenzione | — | — | Per ulteriori informazioni, scopri come creare un backup prima dell'upgrade. | Per ulteriori informazioni, scopri come creare un backup prima dell'upgrade. |
Passaggi successivi
Per ulteriori informazioni su problemi e soluzioni alternative noti dei prodotti, consulta Problemi noti di Google Distributed Cloud.
<>