Google Distributed Cloud è progettato per limitare l'ambito degli errori e per dare la priorità alle funzionalità essenziali per la continuità operativa. Questo documento spiega in che modo la funzionalità dei cluster viene interessata 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:
- Esegui carichi di lavoro: i carichi di lavoro esistenti possono continuare a essere eseguiti. Questo è l'aspetto più importante da considerare per mantenere la continuità aziendale. Anche se il cluster ha un problema, i carichi di lavoro esistenti potrebbero continuare a essere eseguiti senza interruzioni.
- Gestisci carichi di lavoro: puoi creare, aggiornare ed eliminare i carichi di lavoro. Questo è il secondo aspetto più importante da considerare per scalare i workload 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 è disponibile capacità sui nodi esistenti, l'impossibilità di modificare i cluster utente non influisce sui workload utente.
- Gestisci cluster di amministrazione: puoi aggiornare ed eseguire l'upgrade del cluster di amministrazione.
- Per i deployment che utilizzano cluster di amministrazione e utente separati, questo è l'aspetto meno importante perché il cluster di amministrazione non ospita carichi di lavoro utente. Se il cluster di amministrazione ha un problema, i carichi di lavoro dell'applicazione sugli altri cluster continuano a essere eseguiti senza interruzioni.
- Se utilizzi altri modelli di deployment, come quello ibrido o autonomo, il cluster di amministrazione esegue i carichi di lavoro delle applicazioni. Se il cluster di amministrazione ha un problema e il control plane non è disponibile, non puoi 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, viene annotata anche la durata (ordine) dell'interruzione, ove possibile.
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 a cui appartiene la macchina non riuscita, esistono diverse modalità di errore.
Nodo piano di controllo
La tabella seguente descrive il comportamento dei nodi che fanno parte del piano di controllo in Google Distributed Cloud:
| Esegui carichi di lavoro | Gestire i 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 interessa il singolo nodo del control plane in un cluster utente non ad alta disponibilità 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 control plane del cluster utente è perso. | Se l'errore del nodo interessa il nodo del control plane singolo in un cluster di amministrazione non ad alta disponibilità o se interessa almeno la metà dei nodi del control plane in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster di amministrazione è perso. | Se l'errore del nodo interessa il nodo del control plane singolo in un cluster di amministrazione non ad alta disponibilità o se interessa almeno la metà dei nodi del control plane in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster di amministrazione è perso. |
| Recupero | — | Per ulteriori informazioni, consulta la sezione Come eseguire il ripristino in seguito alla perdita del quorum. | Per ulteriori informazioni, consulta la sezione Come eseguire il ripristino in seguito alla perdita del quorum. | Per ulteriori informazioni, consulta la sezione Come eseguire il ripristino in seguito alla 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à 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. |
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à livello 2. Per il bilanciamento del carico manuale, consulta le modalità di errore dei bilanciatori del carico esterni:
| Esegui carichi di lavoro | Gestire i 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 carichi di lavoro esterni si basano sul bilanciatore del carico del data plane per comunicare con i carichi di lavoro nel cluster e hai un solo nodo del bilanciatore del carico, 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 è HA, 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 in pochi secondi. Se non è HA, valuta la possibilità di eseguire il deployment di altri nodi del bilanciatore del carico. |
Se è presente HA, il failover è automatico e avviene in pochi secondi. Se non è HA, valuta la possibilità di implementare nodi del bilanciamento del carico aggiuntivi |
Se è presente HA, il failover è automatico e avviene in pochi secondi. Se non è HA, valuta la possibilità di eseguire il deployment di altri nodi del bilanciatore del carico. |
Se è presente HA, il failover è automatico e avviene in pochi secondi. Se non è HA, 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 nodepool del bilanciatore del carico in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei nodepool del bilanciatore del carico in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei nodepool del bilanciatore del carico in modalità HA. | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment dei nodepool del bilanciatore del carico in modalità HA. |
Nodo worker
La tabella seguente descrive il comportamento dei nodi worker in Google Distributed Cloud:
| Esegui carichi di lavoro | Gestire i workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione (durata) | Possibile interruzione (ordine di 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 nuovi tentativi. I |
— | — | — |
| Recupero | Se il cluster non ha capacità di riserva, devi eseguire il deployment di 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 workload con più repliche distribuite in 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 che non funziona, esistono diverse modalità di errore.
etcd
I contenuti delle directory /var/lib/etcd e /var/lib/etcd-events potrebbero
danneggiarsi se si verifica un arresto anomalo del nodo o un
errore sottostante dello spazio di archiviazione. La tabella seguente descrive il comportamento della funzionalità di base a causa di errori di etcd:
| Esegui carichi di lavoro | Gestire i 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 carichi di lavoro esistenti non si basano sul piano di controllo Kubernetes, continuano a funzionare senza interruzioni. | Se etcd non riesce su un cluster utente con un singolo control plane o
non riesce su almeno la metà dei nodi del control plane in un cluster utente
ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster utente è perso. |
Se etcd non riesce su un cluster di amministrazione con un singolo control plane o
non riesce su almeno la metà dei nodi del control plane in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster di amministrazione è perso. |
Se etcd non riesce su un cluster di amministrazione con un singolo control plane o
non riesce su almeno la metà dei nodi del control plane in un cluster di amministrazione ad alta disponibilità, si verifica un'interruzione. Il quorum del control plane del cluster di amministrazione è perso. |
| Recupero | — | Per ulteriori informazioni, consulta la sezione Come eseguire il ripristino in seguito alla perdita del quorum. | Per ulteriori informazioni, consulta la sezione Come eseguire il ripristino in seguito alla perdita del quorum. | Per ulteriori informazioni, consulta la sezione Come eseguire il ripristino in seguito alla 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à 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 descrive il comportamento della funzionalità di base a causa del
malfunzionamento di un PersistentVolume:
| Esegui carichi di lavoro | Gestire i 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 PersistentVolume non riuscito |
— | — | — |
| Recupero | — | — | — | — |
| Prevenzione | Per ridurre al minimo la possibilità di interruzioni, esegui il deployment del workload utente in modalità HA. | — | — | — |
Disco danneggiato di Fluent Bit
Il danneggiamento di un disco Fluent Bit non influisce sulle funzionalità di base, ma sulla capacità di raccogliere e ispezionare i log su Google Cloud.
L'evento SIGSEGV a volte può essere osservato 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.
Su LoadBalancer IP
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 risolvere questo problema di 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 il processo di installazione del cluster. La CA ha una scadenza di 10 anni ed è responsabile della generazione di 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 ad eseguire l'upgrade del cluster, puoi eseguire una rotazione 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.
| Esegui carichi di lavoro | Gestire i 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 carichi di lavoro utente non comunicano con i componenti del piano di controllo Kubernetes, non si verificheranno 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 verifica un'interruzione. |
| Recupero | — | Segui i passaggi per rinnovare manualmente i certificati sul cluster utente. |
Segui i passaggi per rinnovare manualmente i certificati sul cluster utente. |
Segui i passaggi per rinnovare manualmente i certificati sul cluster utente. |
| Prevenzione | Configura i monitor per la scadenza dei certificati. Un esempio
di metrica kubelet_certificate_manager_server_expiration_seconds può
essere trovato nell'elenco delle metriche. |
|||
Errori di upgrade
| Esegui carichi di lavoro | Gestire i 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 un'interruzione dei carichi di lavoro esistenti. Se l'upgrade non va a buon fine su un nodo worker specifico, i carichi di lavoro su quel nodo verranno svuotati e spostati su altri nodi integri se c'è capacità aggiuntiva sui nodi integri. |
L'upgrade verrà interrotto se l'upgrade di uno dei nodi del control plane non va a buon fine. Il cluster è ancora funzionante se l'upgrade non riesce se il cluster utente è HA. | Se l'upgrade non va a buon fine sul control plane del cluster di amministrazione, si verifica un'interruzione fino al completamento dell'upgrade. | Se l'upgrade non va a buon fine sul control plane del cluster di amministrazione, si verifica un'interruzione fino al completamento dell'upgrade. |
| Recupero | — | — | L'upgrade può essere riprovato. Per saperne di più, scopri come diagnosticare i problemi di upgrade e riprendere. | L'upgrade può essere riprovato. Per saperne di più, scopri come diagnosticare i problemi di upgrade e riprendere. |
| Prevenzione | — | — | Per saperne di più, scopri come creare un backup prima dell'upgrade. | Per saperne di più, scopri come creare un backup prima dell'upgrade. |
Passaggi successivi
Per ulteriori informazioni sui problemi noti del prodotto e sulle soluzioni alternative, vedi Problemi noti di Google Distributed Cloud.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:
- Requisiti per l'apertura di una richiesta di assistenza.
- Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
- Componenti supportati.