Best practice per l'aggiornamento

Best Practice: utilizza la versione più recente di Kubernetes

Le nuove release di Kubernetes in genere includono molti aggiornamenti, funzionalità aggiuntive e, soprattutto, patch per risolvere i problemi di sicurezza nelle versioni precedenti. Kubernetes Engine fornisce il supporto per tre versioni secondarie di Kubernetes, con la versione patch più recente per ciascuna di queste versioni.

Si raccomanda pertanto di:

• I cluster di produzione eseguono sempre la versione stabile più recente di Kubernetes.
• Quando crei i cluster con Kubernetes Engine, specifichi la versione meno recente supportata di Kubernetes.
• Esegui l'upgrade dei cluster esistenti quando Oracle annuncia il supporto di Kubernetes Engine per una versione major, minor o patch di Kubernetes. L'upgrade regolare dei cluster consente di evitare situazioni in cui i cluster eseguono versioni precedenti di Kubernetes che non includono le funzioni e le correzioni più recenti.

Vedere Versioni Kubernetes e Kubernetes Engine (OKE), Aggiornamento dei cluster alle versioni Kubernetes più recenti.

Best Practice: impostazione degli ambienti di test e produzione

Ti consigliamo di utilizzare più ambienti Kubernetes Engine come parte di un flusso di lavoro per distribuire e rilasciare le applicazioni. L'utilizzo di più ambienti consente di ridurre al minimo i rischi e i tempi di inattività indesiderati, consentendo di testare gli aggiornamenti di software e infrastruttura in un ambiente separato dall'ambiente di produzione. È consigliabile disporre almeno di un ambiente di produzione e di un ambiente di pre-produzione o di test.

Prima di eseguire l'upgrade di un cluster a una nuova versione di Kubernetes, è consigliabile eseguire il test di qualsiasi applicazione distribuita nel cluster per verificare che le applicazioni siano compatibili con la nuova versione di Kubernetes. Dopo aver eseguito l'upgrade dei nodi del piano di controllo a una versione più recente di Kubernetes, non è possibile eseguire il downgrade dei nodi del piano di controllo a una versione precedente di Kubernetes. Di qui l'importanza di eseguire il test delle applicazioni prima di eseguire l'upgrade del cluster a una nuova versione di Kubernetes. Ad esempio, prima di eseguire l'upgrade di un cluster, è possibile creare un cluster separato che esegue la nuova versione di Kubernetes e le applicazioni di test su tale cluster.

Vedere Aggiornamento dei cluster alle versioni Kubernetes più recenti.

Best Practice: Usa una strategia di implementazione blu-verde

Ti consigliamo di utilizzare una strategia di implementazione blu-verde per ridurre i rischi e ridurre al minimo i tempi di inattività durante l'upgrade dei cluster Kubernetes. Le implementazioni blu-verde utilizzano due ambienti di produzione, noti come "blu" e "verde", per fornire test affidabili, aggiornamenti continui senza interruzioni e rollback istantanei. L'utilizzo di una strategia di distribuzione blu-verde garantisce agli utenti l'accesso a un ambiente di produzione mentre l'altro ambiente di produzione viene aggiornato.

Best Practice: pianificare le finestre di manutenzione

Si consiglia di pianificare le attività di manutenzione durante le ore non di punta per limitare l'impatto sulle applicazioni che non gestiscono in modo normale l'interruzione dei pod causata dagli aggiornamenti e dalla manutenzione del cluster/nodo.

Ad esempio, durante gli aggiornamenti, possono verificarsi interruzioni temporanee quando i carichi di lavoro vengono spostati per ricreare i nodi. Per garantire che tali interruzioni causino un impatto minimo, ove possibile:

• pianificare gli aggiornamenti per le ore non di punta
• progettare distribuzioni di applicazioni per gestire interruzioni parziali senza problemi

Best Practice: considera i nodi di lavoro come immutabili

Si consiglia di considerare i nodi di lavoro esistenti come entità immutabili.

Le modifiche apportate alle proprietà dei nodi di lavoro di un pool di nodi si applicano solo ai nuovi nodi di lavoro creati successivamente. Impossibile modificare le proprietà dei nodi di lavoro esistenti.

Ad esempio, anziché aggiornare l'immagine del sistema operativo in esecuzione sui nodi di lavoro esistenti, considerare la possibilità di creare un nuovo pool di nodi con nodi di lavoro con l'immagine del sistema operativo aggiornata. Avendo specificato il cordone e le opzioni di rimozione per il pool di nodi originale per impedire l'avvio e l'eliminazione di nuovi pod esistenti, è possibile spostare il lavoro dal pool di nodi originale al nuovo pool di nodi. È quindi possibile eliminare il pool di nodi originale.

Vedere Creazione di nodi di lavoro con proprietà aggiornata.

Best Practice: Cordon e drenaggio dei nodi di lavoro in preparazione alla manutenzione

Si consiglia di collegare e rimuovere un nodo di lavoro prima della manutenzione pianificata su tale nodo.

Il cordoning contrassegna un nodo di lavoro come non programmabile e impedisce al kube-scheduler di posizionare nuovi pod su quel nodo. Il drenaggio evita in modo sicuro i pod da un nodo di lavoro, il che garantisce che i container vengano terminati in modo normale ed eseguano qualsiasi pulizia necessaria.

Vedere Cordonizzazione e rimozione dei nodi gestiti prima dell'arresto o della cessazione. Vedere anche Amministrazione nodo manuale e Scarica un nodo in modo sicuro nella documentazione di Kubernetes.