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 stateful, che spesso hanno bisogno di tempo per interrompere correttamente l'I/O e smontare l'archiviazione, sono particolarmente vulnerabili alle interruzioni. Puoi utilizzare le funzionalità di Kubernetes come i budget di interruzione dei pod (PDB) e i probe di idoneità per mantenere la disponibilità delle applicazioni durante gli upgrade.
GKE monitora i 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 probe di idoneità per massimizzare la resilienza dei carichi di lavoro alle interruzioni. 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 carichi di lavoro con vulnerabilità alle interruzioni.
Per scoprire di più su come gestire gli insight e i consigli di Recommender, consulta Ottimizzare l'utilizzo di GKE con insight e consigli.
Identificare i carichi di lavoro con vulnerabilità alle interruzioni
GKE genera insight che identificano i carichi di lavoro vulnerabili alle interruzioni del cluster. Per ottenere questi insight, segui le istruzioni per visualizzare gli insight e i consigli utilizzando Google Cloud CLI o l'API Recommender. Utilizza i sottotipi elencati nella sezione seguente per filtrare insight specifici. Questi insight non sono disponibili nella Google Cloud console.
Quando GKE identifica i carichi di lavoro con vulnerabilità alle interruzioni
Consulta la tabella seguente per gli scenari in cui GKE fornisce un insight e un consiglio e il sottotipo pertinente:
| Sottotipo di insight | Descrizione | Azione |
|---|---|---|
PDB_UNPROTECTED_STATEFULSET |
Genera un avviso quando esiste uno StatefulSet in cui le etichette PDB esistenti non corrispondono alle etichette del selettore di pod dello StatefulSet. Ciò significa che tutti i pod nello StatefulSet possono essere disattivati durante un evento come un upgrade dei nodi. | Aggiungi un PDB le cui etichette corrispondano a quelle nel campo del selettore di pod dello StatefulSet. Specifica in questo PDB la quantità di interruzioni che possono essere tollerate dallo StatefulSet. Il consiglio associato a questo insight suggerisce le etichette che un PDB deve impostare per coprire lo StatefulSet menzionato. |
PDB_UNPERMISSIVE |
Genera un avviso quando un PDB corrispondente a un pod non può essere rispettato per le 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 |
Genera un avviso 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'insight. Ti consigliamo inoltre di aggiungere probe di attività. |
DEPLOYMENT_MISSING_PDB |
Genera un avviso 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 corrispondano a quelle nel campo del selettore di pod del deployment. Specifica in questo PDB la quantità di interruzioni che possono essere tollerate dal deployment. Il consiglio associato a questo insight suggerisce le etichette che un PDB deve impostare per coprire il deployment menzionato. |
Implementare le indicazioni per migliorare la preparazione alle interruzioni
Se hai ricevuto insight e consigli per i carichi di lavoro nel cluster e vuoi migliorarne la preparazione alle interruzioni, implementa le istruzioni descritte nel consiglio e l'azione per il sottotipo di insight, come indicato nella sezione precedente.
I consigli vengono valutati una volta al giorno, quindi 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
- Per scoprire di più su come garantire l'affidabilità e l'uptime del cluster GKE, consulta Best practice per le operazioni di GKE Day 2 Practices.
- Per scoprire di più sulle possibili interruzioni dei pod in Kubernetes, consulta Interruzioni.