Kubernetes 1.17 — come aggiornare senza esaurire l'intero budget di errori

Il 9 dicembre è stata rilasciata una nuova versione di Kubernetes - 1.17. Il suo motto è «Stabilità», molte funzionalità hanno ottenuto lo stato GA, e diverse funzionalità obsolete sono state rimosse…

E, come sempre, la nostra sezione preferita Action Required del file CHANGELOG-1.17.md richiede attenzione.

Mettiamoci al lavoro…

Attenzione, Storage!

L'aggiornamento di kubelet a caldo nella versione 1.17 non è supportato, poiché è cambiato il percorso per i block volumes. Prima di aggiornare il nodo, è necessario evacuare tutti i pod da esso usando il comando kubectl drain.

Flag e gate…

Nel changelog si scrive solitamente che un certo flag o feature gate è stato rimosso o aggiunto, ma stranamente non viene mai specificata l'applicazione che ha subito questa modifica…:

• Flag rimosso --include-uninitialized a kubectl;
• Le funzionalità precedentemente autorizzate dai feature gates GCERegionalPersistentDisk, EnableAggregatedDiscoveryTimeout e VolumiLocaliPersistenti, ora sono sempre utilizzate e non possono essere disattivate. Queste opzioni sono state rimosse dalle chiavi possibili api-server e controller-manager;
• La rete degli indirizzi IP per i servizi ora non è assegnata di default. È necessario specificarla utilizzando il flag --service-cluster-ip-range quando si avvia l'API server e il controller-manager.

kubeadm

• Kubeadm ha imparato a configurare l'aggiornamento automatico dei certificati per kubelet su tutti i nodi del cluster, incluso il primo master, dove è stato eseguito il comando kubeadm init. L'effetto collaterale è stato la necessità di un file di configurazione iniziale per kubelet bootstrap-kubelet.conf invece di kubelet.conf durante l'esecuzione kubeadm init;
• Con l'aggiunta dei metodi di autorizzazione all'API un server kubeadm non inserisce più i metodi Node, RBAC nel manifesto del pod statico, consentendo di modificare completamente la configurazione.

RBAC

Rimosse le cluster roles incorporate system:csi-external-provisioner e system:csi-external-attacher.

Deprecato…

Alcune funzionalità sono state dichiarate obsolete, ma sono ancora supportate. Tuttavia, è importante notare il passaggio all'utilizzo di ContainerStorageInterface. Gli amministratori che hanno distribuito i propri cluster (non gestiti) in AWS e GCE devono pianificare il passaggio all'uso di CSI Driver per lavorare con volumi persistenti - piuttosto che con driver integrati in Kubernetes. Dovrebbero essere aiutati dalla procedura CSIMigration - aspettiamo una guida passo passo. Gli amministratori che utilizzano altri provider per collegare dischi persistenti devono cercare e leggere la documentazione: nella versione 1.21 si promette di rimuovere definitivamente tutti i driver integrati.

Fonte: habr.com