Google Distributed Cloud è progettato per limitare l'ambito degli errori e dare la priorità alle funzionalità fondamentali per la continuità operativa. Questo documento spiega l'impatto della funzionalità dei cluster in caso di errore. Queste informazioni possono aiutarti a dare la priorità alle aree da risolvere in caso di problemi.
La funzionalità di base di Google Distributed Cloud include le seguenti categorie:
- Esecuzione dei workload: i workload esistenti possono continuare a essere eseguiti. Questa è la considerazione più importante per mantenere la continuità operativa. Anche se il cluster presenta un problema, i workload esistenti potrebbero continuare a essere eseguiti senza interruzioni.
- Gestione dei workload: puoi creare, aggiornare ed eliminare i workload. Questa è la seconda considerazione più importante per scalare i workload quando il traffico aumenta, anche se il cluster presenta un problema.
- Gestione dei cluster utente: puoi gestire i nodi, aggiornare, eseguire l'upgrade ed eliminare i cluster utente. Questa considerazione è meno importante di quelle relative al ciclo di vita dell'applicazione. Se è disponibile capacità sui nodi esistenti, l'impossibilità di modificare i cluster utente non influisce sui workload utente.
- Gestione dei 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 workload utente. Se il cluster di amministrazione presenta un problema, i workload dell'applicazione sugli altri cluster continuano a essere eseguiti senza interruzioni.
- Se utilizzi altri modelli di deployment, come ibrido o autonomo, il cluster di amministrazione esegue i workload dell'applicazione. Se il cluster di amministrazione presenta un problema e il piano di controllo non è attivo, non puoi gestire i workload dell'applicazione 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 errore, viene indicata anche la durata (ordine) dell'interruzione, ove possibile.
Errori dei nodi
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 errore, esistono diverse modalità di errore.
Nodo del piano di controllo
La tabella seguente descrive il comportamento dei nodi che fanno parte del piano di controllo in Google Distributed Cloud:
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Nessuna interruzione | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) |
| Spiegazione | — | Se l'errore del nodo influisce sul nodo del piano di controllo singolo in un cluster utente non ad alta affidabilità (HA) o se influisce su almeno la metà dei nodi del piano di controllo in un cluster utente ad alta affidabilità, si verifica un'interruzione. Il quorum del piano di controllo del cluster utente viene perso. | Se l'errore del nodo influisce sul nodo del control plane singolo in un cluster di amministrazione non ad alta disponibilità o se influisce su almeno la metà dei nodi del control plane in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del piano di controllo del cluster di amministrazione viene perso. | Se l'errore del nodo influisce sul nodo del piano di controllo singolo in un cluster di amministrazione non ad alta disponibilità o se influisce 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 viene perso. |
| Ripristino | — | Per saperne di più, consulta la sezione Come eseguire il ripristino in caso di perdita del quorum. | Per saperne di più, consulta la sezione Come eseguire il ripristino in caso di perdita del quorum. | Per saperne di più, consulta la sezione Come eseguire il ripristino in caso di perdita del quorum. |
| Prevenzione | — | Esegui il deployment dei cluster utente in modalità ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | Esegui il deployment dei cluster di amministrazione in modalità ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | Esegui il deployment dei cluster di amministrazione in modalità ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. |
Nodo del bilanciatore del carico
La tabella seguente descrive 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 la modalità di livello 2. Per il bilanciamento del carico manuale, consulta le modalità di errore dei bilanciatori del carico esterni:
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Possibile interruzione (varia) | Possibile interruzione (varia) | Possibile interruzione (varia) | Possibile interruzione (varia) |
| Spiegazione | Se i workload esterni si basano sul bilanciatore del carico del piano dati per comunicare con i workload nel cluster e hai un solo nodo del bilanciatore del carico, si verifica un'interruzione. | L'indirizzo IP virtuale del piano di controllo del cluster utente risiede su un nodo del bilanciatore del carico. Se il node pool del bilanciatore del carico del cluster utente cluster non è ad alta disponibilità, si verifica un'interruzione. | L'indirizzo IP virtuale del piano di controllo del cluster di amministrazione risiede su un nodo del bilanciatore del carico. Se il node pool del bilanciatore del carico del cluster di amministrazione non è ad alta disponibilità, si verifica un'interruzione. | L'indirizzo IP virtuale del piano di controllo del cluster di amministrazione risiede su un nodo del bilanciatore del carico. Se il node pool del bilanciatore del carico del cluster di amministrazione non è ad alta disponibilità, si verifica un'interruzione. |
| Ripristino | Se sono presenti più nodi del bilanciatore del carico, il failover di MetalLB avviene in pochi secondi. Se non è ad alta disponibilità, valuta la possibilità di eseguire il deployment di altri nodi del bilanciatore del carico. |
Se è ad alta disponibilità, il failover è automatico e avviene in pochi secondi. Se non è ad alta disponibilità, valuta la possibilità di eseguire il deployment di altri nodi del bilanciatore del carico. |
Se è ad alta disponibilità, il failover è automatico e avviene in pochi secondi. Se non è ad alta disponibilità, valuta la possibilità di eseguire il deployment di altri nodi del bilanciatore del carico. |
Se è ad alta disponibilità, il failover è automatico e avviene in pochi secondi. Se non è ad alta disponibilità, valuta la possibilità di eseguire il deployment di altri nodi del bilanciatore del carico. |
| Prevenzione | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei node pool del bilanciatore del carico in modalità ad alta disponibilità. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei node pool del bilanciatore del carico in modalità ad alta disponibilità. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei node pool del bilanciatore del carico in modalità ad alta disponibilità. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei node pool del bilanciatore del carico in modalità ad alta disponibilità. |
Nodo worker
La tabella seguente descrive il comportamento dei nodi worker in Google Distributed Cloud:
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Possibile interruzione (ordine dei secondi) | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
| Spiegazione | I Se le applicazioni utente hanno capacità di workload di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i tentativi. I |
— | — | — |
| Ripristino | Se il cluster non ha capacità di riserva, devi eseguire il deployment di altri nodi distribuiti su più zone di errore e spostare i workload in errore sui nuovi nodi. | — | — | — |
| Prevenzione | Esegui il deployment di nodi distribuiti su più zone di errore. Esegui il deployment dei workload con più repliche distribuite su più zone di errore per ridurre al minimo la possibilità di interruzioni. |
— | — | — |
Errore di archiviazione
L'archiviazione in Google Distributed Cloud potrebbe smettere di funzionare o diventare irraggiungibile sulla rete. A seconda dell'archiviazione in errore, 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 sottostante dell'archiviazione. La tabella seguente descrive il comportamento della funzionalità di base a causa degli errori di etcd:
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Nessuna interruzione | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) |
| Spiegazione | Se i workload esistenti non si basano sul piano di controllo di Kubernetes, continuano a funzionare senza interruzioni. | Se etcd non funziona su un singolo cluster utente del piano di controllo o non funziona su 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 su un singolo cluster di amministrazione del piano di controllo o non funziona 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
viene perso. |
Se etcd non funziona su un singolo cluster di amministrazione del piano di controllo o non funziona 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
viene perso. |
| Ripristino | — | Per saperne di più, consulta la sezione Come eseguire il ripristino in caso di perdita del quorum. | Per saperne di più, consulta la sezione Come eseguire il ripristino in caso di perdita del quorum. | Per saperne di più, consulta la sezione Come eseguire il ripristino in caso di perdita del quorum. |
| Prevenzione | — | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei cluster utente in modalità ad alta disponibilità. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei cluster di amministrazione in modalità ad alta disponibilità. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei cluster di amministrazione in modalità ad alta disponibilità. |
PersistentVolume dell'applicazione utente
La tabella seguente descrive il comportamento della funzionalità di base a causa dell'errore di un PersistentVolume:
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Possibile interruzione (sconosciuta) | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
| Spiegazione | I workload che utilizzano il PersistentVolume in errore sono interessati. |
— | — | — |
| Ripristino | — | — | — | — |
| Prevenzione | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment del workload utente in modalità ad alta disponibilità. | — | — | — |
Disco danneggiato di Fluent Bit
Il danneggiamento di un disco Fluent Bit non influisce sulle funzionalità principali, ma influisce sulla capacità di raccogliere e ispezionare i log su Google Cloud.
A volte è possibile osservare l'evento SIGSEGV dai log di stackdriver-log-forwarder. Questo errore potrebbe essere causato dai log memorizzati nel buffer danneggiati sul disco.
Fluent Bit ha un meccanismo per filtrare ed eliminare i blocchi danneggiati. Questa funzionalità è disponibile nella versione di Fluent Bit (v1.8.3) utilizzata in Google Distributed Cloud.
Esaurimento degli indirizzi IP 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 client del servizio di comunicare con i servizi LoadBalancer.
Per eseguire il ripristino da questo esaurimento degli indirizzi IP, assegna altri 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 regolarmente i certificati per evitare tempi di inattività del cluster. Puoi ruotare i certificati eseguendo l' upgrade del cluster, che è il metodo consigliato. Se non riesci a eseguire l'upgrade del cluster, puoi eseguire una rotazione della CA on demand. Per saperne di più sui certificati del cluster, consulta Certificati e requisiti PKI nella documentazione di Kubernetes.
Se i certificati del cluster sono scaduti, devono essere rinnovati manualmente.
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Nessuna interruzione | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) |
| Spiegazione | Se i workload utente non comunicano con i componenti del piano di controllo di Kubernetes non si verificano interruzioni. | Se le autorità di certificazione per i cluster utente scadono, si verifica un' interruzione. | Se le autorità di certificazione per i cluster di amministrazione scadono, si verifica un'interruzione. | Se le autorità di certificazione per i cluster utente scadono, si verifica un'interruzione. |
| Ripristino | — | Segui i passaggi per rinnovare manualmente i certificati su il cluster utente. |
Segui i passaggi per rinnovare manualmente i certificati su il cluster utente. |
Segui i passaggi per rinnovare manualmente i certificati su il cluster utente. |
| Prevenzione | Configura i monitoraggi per la scadenza dei certificati. Un esempio
metrica kubelet_certificate_manager_server_expiration_seconds può
essere trovato su l'elenco delle metriche. |
|||
Errori di upgrade
| Esecuzione dei workload | Gestione dei workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Nessuna interruzione | Nessuna interruzione | Possibile interruzione (sconosciuta) | Possibile interruzione (sconosciuta) |
| Spiegazione | Se l'upgrade non riesce sul control plane del cluster utente, NON si verifica alcuna interruzione dei workload esistenti. Se l'upgrade non riesce su un nodo worker specifico, i workload su quel nodo vengono svuotati e spostati su altri nodi integri se è disponibile capacità aggiuntiva sui nodi integri. |
L'upgrade si interrompe se l'upgrade di uno dei nodi del control plane non riesce. Il cluster è ancora funzionante se l'upgrade non riesce se il cluster utente è ad alta disponibilità. | Se l'upgrade non riesce sul piano di controllo del cluster di amministrazione, si verifica un'interruzione fino al completamento dell'upgrade. | Se l'upgrade non riesce sul piano di controllo del cluster di amministrazione, si verifica un'interruzione fino al completamento dell'upgrade. |
| Ripristino | — | — | L'upgrade può essere ritentato. Per saperne di più, consulta la sezione Come diagnosticare i problemi di upgrade e riprendere. | L'upgrade può essere ritentato. Per saperne di più, consulta la sezione Come diagnosticare i problemi di upgrade e riprendere. |
| Prevenzione | — | — | Per saperne di più, consulta la sezione Come creare un backup prima dell'upgrade. | Per saperne di più, consulta la sezione Come creare un backup prima dell'upgrade. |
Passaggi successivi
Per saperne di più sui problemi noti relativi ai prodotti e sulle soluzioni alternative, consulta Problemi noti di Google Distributed Cloud.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:
- Requisiti per l'apertura di una richiesta di assistenza.
- Strumenti per la risoluzione dei problemi, come la configurazione dell'ambiente, i log e le metriche.
- Componenti supportati.