Kubernetes 1.17 - cum să faceți upgrade și să nu cheltuiți întregul buget de eroare

Pe 9 decembrie a fost lansată următoarea versiune de Kubernetes - 1.17. Motto-ul său este „Stabilitate”, multe funcții au primit statutul GA, o serie de caracteristici învechite au fost eliminate...

Și, ca întotdeauna, secțiunea noastră preferată este fișierul Action Required CHANGELOG-1.17.md necesită atenție.

Să lucrăm cu mâinile noastre...

Atentie, depozitare!

Actualizarea kubelet din mers nu este acceptată în versiunea 1.17, deoarece calea de blocare a volumelor s-a schimbat. Înainte de a actualiza un nod, trebuie să evacuați toate podurile din acesta folosind comanda kubectl drain.

Steaguri și porți...

În jurnalul de modificări ei scriu, de obicei, că un astfel de steag sau o poartă caracteristică a fost eliminată sau adăugată, dar din anumite motive nu scriu niciodată aplicația pentru care a avut loc această modificare...:

• Steagul a fost eliminat --include-uninitialized у kubectl;
• Funcționalitate care prezintă porți permise GCERegionalPersistentDisk, EnableAggregatedDiscoveryTimeout и PersistentLocalVolumes, este acum întotdeauna folosit și nu poate fi dezactivat. Aceste opțiuni au fost eliminate din posibilele chei api-server и controller-manager;
• Rețeaua de adrese IP pentru servicii nu mai este atribuită implicit. Trebuie specificat folosind steag --service-cluster-ip-range la pornirea serverului API și controler-manager.

kubeadm

• Kubeadm a învățat cum să configureze reînnoirea automată a certificatelor pentru kubelet pe toate nodurile clusterului, inclusiv primul master unde a fost executată comanda kubeadm init. Un efect secundar a fost cerința pentru un fișier cu configurația kubelet inițială bootstrap-kubelet.conf în loc de kubelet.conf in timpul executiei kubeadm init;
• Când adăugați moduri de autorizare la API, serverul kubeadm nu mai înlocuiește modurile Node, RBAC în manifestul pod static, permițându-vă să schimbați complet configurația.

RBAC

S-au eliminat rolurile de cluster încorporate system:csi-external-provisioner и system:csi-external-attacher.

Depreciat…

O serie de funcții au fost depreciate, dar sunt încă acceptate. Dar aș dori în special să notez procesul de tranziție la utilizarea ContainerStorageInterface. Administratorii care și-au implementat propriile clustere (negestionate) pe AWS și GCE ar trebui să plănuiască să migreze la utilizarea driverului CSI pentru a lucra cu volume persistente în loc de driverele încorporate în Kubernetes. Procedura CSIMigration ar trebui să-i ajute în acest sens - așteptăm să apară ghidul pas cu pas. Pentru administratorii care folosesc alți furnizori pentru a conecta discuri persistente, este timpul să caute și să citească documentația: versiunea 1.21 promite să elimine definitiv toate driverele încorporate.

Sursa: www.habr.com