Assicurati che i carichi di lavoro siano pronti per le interruzioni

Le applicazioni in esecuzione nei cluster Google Kubernetes Engine (GKE) devono essere preparate per interruzioni come gli upgrade dei nodi e altri eventi di manutenzione. Le applicazioni con stato, che spesso richiedono tempo per interrompere correttamente l'I/O e smontare dall'archiviazione, sono particolarmente vulnerabili alle interruzioni. Puoi utilizzare le funzionalità di Kubernetes come i budget di interruzione dei pod (PDB) e i sondaggi di idoneità per contribuire a mantenere disponibili le applicazioni durante gli upgrade.

GKE monitora i tuoi cluster e utilizza il servizio Recommender per fornire indicazioni su come ottimizzare l'utilizzo della piattaforma. GKE rileva le opportunità per preparare i carichi di lavoro alle interruzioni e fornisce indicazioni su come aggiornare i PDB o i controlli di idoneità per massimizzare la resilienza dei carichi di lavoro alle interruzioni. Ad esempio, se uno StatefulSet non è protetto da un PDB, il tuo cluster potrebbe rimuovere tutti i pod contemporaneamente durante un upgrade del nodo. Per evitare questo problema, GKE fornisce indicazioni per creare un PDB in modo che la maggior parte dei pod possa rimanere in esecuzione durante un upgrade.

Per conoscere le condizioni specifiche in cui GKE fornisce indicazioni relative alle interruzioni, consulta Quando GKE identifica i carichi di lavoro con vulnerabilità alle interruzioni.

Per scoprire di più su come gestire gli approfondimenti e i consigli dei Recommender, consulta Ottimizzare l'utilizzo di GKE con approfondimenti e consigli.

Identificare i carichi di lavoro con vulnerabilità alle interruzioni

GKE genera approfondimenti che identificano i carichi di lavoro del tuo cluster vulnerabili alle interruzioni. Per ottenere questi approfondimenti, segui le istruzioni per visualizzare approfondimenti e consigli utilizzando Google Cloud CLI o l'API Recommender. Utilizza i sottotipi elencati nella sezione seguente per filtrare in base a approfondimenti specifici. Queste informazioni non sono disponibili nella console Google Cloud.

Quando GKE identifica i carichi di lavoro con vulnerabilità alle interruzioni

Consulta la tabella seguente per gli scenari in cui GKE fornisce un'informazione e un consiglio, nonché il sottotipo pertinente:

Sottotipo di insight Descrizione Azione
PDB_UNPROTECTED_STATEFULSET Invia avvisi quando esiste uno StatefulSet in cui nessuna delle etichette PDB esistenti corrisponde alle etichette del selettore di pod dello StatefulSet. Ciò significa che tutti i pod nello StatefulSet possono essere disattivati durante un evento come l'upgrade di un nodo. Aggiungi un PDB le cui etichette corrispondano a quelle nel campo del selettore dei pod dello StatefulSet. Specifica in questo PDB la quantità di interruzione che può essere tollerata dallo StatefulSet. Il consiglio associato a questo insight suggerisce quali etichette deve impostare un PDB per coprire lo StatefulSet menzionato.
PDB_UNPERMISSIVE Invia avvisi quando non è possibile rispettare un PDB corrispondente a un pod per attività di manutenzione, ad esempio un upgrade del nodo. Un PDB deve consentire l'interruzione di almeno un pod, pertanto GKE viola questo PDB per la manutenzione necessaria dopo un'ora. Modifica l'impostazione minAvailable del PDB in modo che sia inferiore al conteggio totale dei pod oppure l'impostazione maxUnavailable in modo che sia maggiore di zero.
PDB_STATEFULSET_WITHOUT_PROBES Avvisa quando un set stateful è configurato con un PDB, ma non ha probe di idoneità, perciò il PDB non è utile per misurare l'idoneità dell'applicazione. I PDB rispettano i probe di idoneità quando considerano i pod da conteggiare come integri. Di conseguenza, se un pod coperto da un PDB non ha un probe di idoneità configurato, la visibilità del PDB sull'effettiva integrità del pod (idoneità a gestire traffico) è limitata e il pod viene riconosciuto solo come attivo e in esecuzione. Aggiungi probe di idoneità ai pod negli StatefulSet per il PDB menzionato nell'approfondimento. Ti consigliamo inoltre di aggiungere i controlli di presenza.
DEPLOYMENT_MISSING_PDB Invia avvisi quando esiste un deployment con un selettore di pod che non corrisponde a un PDB esistente e il deployment ha più di una replica o scalabilità automatica orizzontale dei pod è abilitata. Ciò significa che tutti i pod nel deployment possono essere disattivati durante un evento come un upgrade del nodo. Aggiungi un PDB le cui etichette corrispondano a quelle nel campo del selettore dei pod del deployment. Specifica in questo PDB la quantità di interruzione che può essere tollerata dal deployment. Il consiglio associato a questa informazione suggerisce quali etichette deve impostare un PDB per coprire il deployment menzionato.

Implementa le indicazioni per migliorare la preparazione alle interruzioni

Se hai ricevuto approfondimenti e consigli per i carichi di lavoro nel tuo cluster e vuoi migliorare la loro idoneità alle interruzioni, implementa le istruzioni descritte nel consiglio e nell'azione per quel sottotipo di informazioni, come mostrato nella sezione precedente.

I consigli vengono valutati una volta al giorno, pertanto potrebbero essere necessarie fino a 24 ore prima che vengano risolti dopo l'implementazione delle modifiche. Se sono trascorse meno di 24 ore dall'implementazione delle indicazioni del consiglio, puoi contrassegnarlo come risolto. Se non vuoi implementare il consiglio, puoi ignorarlo.

Passaggi successivi