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 hanno bisogno di tempo per interrompere correttamente l'I/O e smontare l'archiviazione, sono particolarmente vulnerabili alle interruzioni. Puoi utilizzare funzionalità di Kubernetes come Pod Disruption Budgets (PDB) e Readiness Probes per mantenere le applicazioni disponibili 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 all'interruzione e fornisce indicazioni su come aggiornare i PDB o i probe di preparazione per massimizzare la resilienza dei carichi di lavoro all'interruzione. Ad esempio, se uno StatefulSet non è protetto da un PDB, il cluster potrebbe rimuovere tutti i pod contemporaneamente durante un upgrade dei nodi. 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 visualizzare le condizioni specifiche in cui GKE fornisce indicazioni relative alle interruzioni, consulta Quando GKE identifica i workload con vulnerabilità alle interruzioni.

Per scoprire di più su come gestire approfondimenti e suggerimenti di Recommenders, consulta Ottimizzare l'utilizzo di GKE con approfondimenti e suggerimenti.

Identificare i workload vulnerabili alle interruzioni

GKE genera approfondimenti che identificano i workload del 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 approfondimenti specifici. Queste informazioni non sono disponibili nella console Google Cloud .

Quando GKE identifica i workload con vulnerabilità all'interruzione

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

Sottotipo di insight Descrizione Azione
PDB_UNPROTECTED_STATEFULSET Avvisi quando esiste uno StatefulSet in cui nessuna etichetta PDB esistente 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 dei nodi. Aggiungi un PDB le cui etichette corrispondano a quelle nel campo del selettore dei pod dello StatefulSet. Specifica nel PDB la quantità di interruzioni che possono essere tollerate dallo StatefulSet. Il suggerimento associato a questo insight indica le etichette che un PDB deve impostare per coprire lo StatefulSet menzionato.
PDB_UNPERMISSIVE Avvisi quando è impossibile rispettare un PDB corrispondente a un pod per qualsiasi attività di manutenzione, ad esempio un upgrade dei nodi. Un PDB deve consentire l'interruzione di almeno un pod, quindi 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 Avvisi quando uno StatefulSet è 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 è 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 probe di attività.
DEPLOYMENT_MISSING_PDB 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 la scalabilità automatica orizzontale dei pod è abilitata. Ciò significa che tutti i pod nel deployment possono essere disattivati durante un evento come un upgrade dei nodi. Aggiungi un PDB le cui etichette corrispondono a quelle nel campo del selettore dei pod del deployment. Specifica nel PDB la quantità di interruzioni tollerabili 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 preparazione alle interruzioni, implementa le istruzioni descritte nel consiglio e nell'azione per quel sottotipo di approfondimento, 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 non vuoi implementare il consiglio, puoi ignorarlo.

Passaggi successivi