Kubernetes 1.17 - kiel ĝisdatigi kaj ne elspezi la tutan eraran buĝeton

La 9-an de decembro, la sekva versio de Kubernetes estis publikigita - 1.17. Ĝia moto estas "Stabileco", multaj funkcioj ricevis GA-statuson, kelkaj malmodernaj trajtoj estis forigitaj...

Kaj, kiel ĉiam, nia plej ŝatata sekcio estas la Ago Bezonata dosiero ŜANĜOLOGO-1.17.md postulas atenton.

Ni laboru per niaj manoj...

Atentu, Stokado!

Ĝisdatigi kubelet sur la flugo ne estas subtenata en versio 1.17 ĉar la vojo por bloki volumojn ŝanĝiĝis. Antaŭ ĝisdatigi nodon, vi devas evakui ĉiujn podojn de ĝi per la komando kubectl drain.

Flagoj kaj pordegoj...

En la ŝanĝprotokolo oni kutime skribas, ke tia kaj tia flago aŭ ĉefpordego estis forigita aŭ aldonita, sed ial ili neniam skribas la aplikaĵon, por kiu ĉi tiu ŝanĝo okazis...:

• Flago forigita --include-uninitialized у kubectl;
• Funkcioj kiuj prezentas pordegojn permesis GCERegionalPersistentDisk, EnableAggregatedDiscoveryTimeout и PersistentLocalVolumes, nun estas ĉiam uzata kaj ne povas esti malŝaltita. Ĉi tiuj opcioj estis forigitaj de eblaj ŝlosiloj api-server и controller-manager;
• La reto de IP-adresoj por servoj ne plu estas asignita defaŭlte. Ĝi devas esti specifita uzante la flagon --service-cluster-ip-range kiam oni ekfunkciigas la API-servilon kaj regilon-manaĝeron.

kubeadm

• Kubeadm lernis kiel agordi aŭtomatan renovigon de atestiloj por kubelet sur ĉiuj grapolnodoj, inkluzive de la unua majstro kie la komando estis efektivigita. kubeadm init. Flanka efiko estis la postulo por dosiero kun la komenca kubelet-agordo bootstrap-kubelet.conf anstataŭ kubelet.conf dum ekzekuto kubeadm init;
• Aldonante rajtigajn reĝimojn al la API, la kubeadm-servilo ne plu anstataŭigas la reĝimojn Node, RBAC en la statikan pod manifeston, permesante al vi tute ŝanĝi la agordon.

RBAC

Forigitaj enkonstruitaj cluster-roloj system:csi-external-provisioner и system:csi-external-attacher.

Malrekomendita…

Kelkaj funkcioj estis malrekomenditaj, sed ili ankoraŭ estas subtenataj. Sed mi precipe ŝatus noti la procezon de transiro al uzado de ContainerStorageInterface. Administrantoj, kiuj deplojis siajn proprajn (neadministratajn) aretojn sur AWS kaj GCE, devus plani migri al uzado de la CSI-Ŝoforo por labori kun konstantaj volumoj anstataŭ la ŝoforoj enkonstruitaj en Kubernetes. La proceduro CSIMigration devus helpi ilin pri tio - ni atendas la paŝon post paŝo aperos. Por administrantoj, kiuj uzas aliajn provizantojn por konekti persistajn diskojn, estas tempo serĉi kaj legi la dokumentaron: versio 1.21 promesas konstante forigi ĉiujn enkonstruitajn ŝoforojn.

fonto: www.habr.com