🥇Kubernetes 1.16: prehľad hlavných noviniek

Dnes, v stredu, sa uskutoční máme ďalší release Kubernetes — 1.16. Podľa tradície nášho blogu už po desiatykrát sa s vami podelíme o najdôležitejšie zmeny v novej verzii.

Informácie použité na prípravu tohto materiálu boli prevzaté z tabuľky sledovania vylepšení Kubernetes, CHANGELOG-1.16 a s príslušnými issues, pull requests a Kubernetes Enhancement Proposals (KEP). Tak teda, ideme na to! ..

Uzly

Naozaj veľké množstvo pozoruhodných noviniek (v alfa verzii) je predstavených na strane uzlov K8s-klastrov (Kubelet).

Po prvé, sú predstavené tzv. «efemérne kontajnery» (Ephemeral Containers), ktorých cieľom je zjednodušiť procesy ladenia v podoch. Nový mechanizmus umožňuje spustiť špeciálne kontajnery, ktoré sa spúšťajú v priestore názvov existujúcich podov a žijú len krátky čas. Ich určením je interakcia s inými podmi a kontajnermi na účely riešenia problémov a ladenia. Pre túto funkčnosť bola implementovaná nová príkazová funkcia kubectl debug, ktorá je podobná kubectl exec: iba namiesto spustenia procesu v kontajneri (ako v prípade exec) spúšťa kontajner v pode. Napríklad takýto príkaz pripojí nový kontajner k podu:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Podrobnosti o efemérnych kontajneroch (a príklady ich využitia) nájdete v príslušnom KEP. Aktuálna implementácia (v K8s 1.16) je alfa verzia a medzi kritériami jej prechodu do beta verzie sa uvádza „testovanie Ephemeral Containers API po dobu najmenej 2 releaseov [Kubernetes]“.

Poznámka: Po svojej podstate a dokonca názve funkcie pripomína už existujúci plugin kubectl-debug, o ktorom sme už písali. Predpokladá sa, že s príchodom efemérnych kontajnerov sa vývoj samostatného externého pluginu zastaví.

Ďalšou novinkou je PodOverhead , ktorá má poskytnúť mechanizmus na výpočet nákladov na pody, ktoré sa môžu výrazne líšiť v závislosti od používaného prostredia (runtime). Ako príklad autori tohto KEP uvádzajú Kata Containers, ktoré vyžadujú spustenie hosťovského jadra, agenta kata, init-systém atď. Keď náklady narastú do takej miery, že ich nemožno ignorovať, vyžaduje sa spôsob, ako ich zohľadniť pri ďalšom kvotovaní, plánovaní a podobne. Na ich implementáciu bolo do PodSpec pridané pole Overhead *ResourceList (ktoré sa mapuje s údajmi v RuntimeClass, ak je taký použitý).

Ešte jednou pozoruhodnou novinkou je manažér topológie uzla (Node Topology Manager), zavedený na zjednotenie prístupu k jemnému ladenie rozdelenia hardvérových zdrojov pre rôzne komponenty v Kubernetes. Táto iniciatíva je vyvolaná rastúcou potrebou rôznych moderných systémov (z oblasti telekomunikácií, strojového učenia, finančných služieb atď.) po vysoko výkonných paralelných výpočtoch a minimalizácii oneskorení pri vykonávaní operácií, na čo využívajú pokročilé možnosti CPU a hardvérovej akcelerácie. Takéto optimalizácie v Kubernetes boli doteraz dosahované prostredníctvom roztrhnutých komponentov (CPU manažér, správa zariadení, CNI), a teraz im pridajú jednotné vnútorné rozhranie, ktoré zjednotí prístup a zjednoduší pripojenie nových podobných — takzvaných topology-aware — komponentov na strane Kubelet. Podrobnosti — v príslušnom KEP.

Schéma komponentov Topology Manager

Nasledujúca funkcia — overenie kontajnerov počas ich spúšťania (startup probe). Ako je známe, pre kontajnery, ktoré sa dlhšie spúšťajú, je ťažké získať aktuálny stav: buď ich „zabijú“ ešte pred skutočným začiatkom fungovania, alebo sa na dlhú dobu dostanú do deadlocku. Nové overenie (zapína sa prostredníctvom feature gate nazvanej StartupProbeEnabled) ruší — presnejšie, odkladá — platnosť akýchkoľvek iných overení do momentu, kedy pod dokončil svoje spúšťanie. Z tohto dôvodu sa funkcia pôvodne nazývala pod-startup liveness-probe holdoff. Pre pody, ktoré sa pomaly spúšťajú, je možné vykonávať dotazovanie stavu v relatívne krátkych časových intervaloch.

Okrem toho je ihneď v beta verzii predstavené vylepšenie pre RuntimeClass, ktoré pridáva podporu „heterogénnych klastrov“. S RuntimeClass Scheduling už nie je vôbec potrebné, aby každý uzol mal podporu každého RuntimeClassu: pre pody si môžete vyberať RuntimeClass, aniž by ste museli premýšľať o topológii klastrov. Predtým na dosiahnutie tohto — aby pody boli na uzloch s podporou všetkého, čo potrebujú — bolo potrebné priradiť príslušné pravidlá k NodeSelector a toleranciám. V KEP sa rozpráva o príkladoch použitia a, samozrejme, podrobnostiach implementácie.

Sieť

Dve významné sieťové funkcie, ktoré sa prvýkrát objavili (v alfa verzii) v Kubernetes 1.16 — to sú:

Podpora dvojitého sieťového zásobníka — IPv4/IPv6 — a jeho „porozumenie“ na úrovni podov, uzlov a služieb. Zapojuje do seba interakciu IPv4-to-IPv4 a IPv6-to-IPv6 medzi podmi, z podov do externých služieb, referenčné implementácie (v rámci pluginov Bridge CNI, PTP CNI a Host-Local IPAM), ako aj spätnú kompatibilitu s klastrami Kubernetes, ktoré pracujú iba na IPv4 alebo IPv6. Podrobnosti implementácie nájdete v KEP.
Príklad výstupu IP adries dvoch typov (IPv4 a IPv6) v zozname podov:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nové API pre Endpoint — EndpointSlice API. Rieši problémy existujúceho Endpoint API týkajúce sa výkonu/škálovateľnosti, ktoré zasahujú do rôznych komponentov v control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Nové API bude pridané do API skupiny Discovery a bude schopné obsluhovať desiatky tisíc backend endpointov na každej službe v klastri tvoreným tisíckami uzlov. Na tento účel sa každá služba mapuje na N objekty EndpointSlice, pričom každý z nich má predvolene nie viac ako 100 endpointov (toto nastavenie je prispôsobiteľné). V EndpointSlice API sa predpokladajú aj možnosti pre jeho budúci rozvoj: podpora viacerých IP adries pre každý pod, nové stavy pre endpointy (nielen Pripravené a NotReady), dynamické rozdeľovanie pre endpointy.

Do beta-verzie pokročil predložený v minulom releasu finalizer, nazvaný service.kubernetes.io/load-balancer-cleanup a pripojený k každej službe typu LoadBalancer. V okamihu odstránenia takejto služby bráni skutočnému odstráneniu zdroja, kým sa neskončila „údržba“ všetkých súvisiacich zdrojov vyrovnávača zaťaženia.

API Machinery

Skutočný „míľnik stabilizácie“ bol zaznamenaný v oblasti API servera Kubernetes a jeho interakcie. V značnej miere sa to stalo vďaka prevodu do stavu stable dôležitých CustomResourceDefinitions (CRD), ktoré mali status beta od čias vzdialeného Kubernetes 1.7 (a to je jún 2017!). Rovnaká stabilizácia prišla aj k príbuzným funkciám:

„podresursy“ (subresources) so /status a /scale pre CustomResources;
konverzia verzií pre CRD, založené na externom webhooku;
nedávno predstavené (v K8s 1.15) predvolené hodnoty (defaulting) a automatické odstraňovanie polí (pruning) pre CustomResources;
možnosť používanie schémy OpenAPI v3 na vytvorenie a publikovanie OpenAPI dokumentácie, ktorá sa používa na validáciu CRD zdrojov na strane servera.

Ďalší mechanizmus, ktorý sa už stal bežným pre správcov Kubernetes: admission webhook — tiež dlhý čas bol v beta verzii (s K8s 1.9) a teraz bol vyhlásený za stabilný.

Dve ďalšie funkcie dosiahli beta verziu: server-side apply a watch bookmarks.

A jediným významným novým prvkom v alfa verzii bol zrušenie od SelfLink — špeciálny URI, predstavujúci daný objekt a súčasť ObjectMeta a ListMeta (t.j. súčasť akéhokoľvek objektu v Kubernetes). Prečo sa od toho upúšťa? Motivácia „zjednodušene“ znamená neexistenciu skutočných (neprekonateľných) dôvodov, prečo by toto pole malo naďalej existovať. Formálnejšie dôvody — optimalizovať výkon (odstránením nepotrebného poľa) a zjednodušiť prácu generic-apiserver, ktorý musí spracovávať také pole osobitným spôsobom (je to jediné pole, ktoré sa nastavuje priamo pred serializáciou objektu). Skutočné „zastaranie“ (v rámci beta verzie) SelfLink sa uskutoční do verzie Kubernetes 1.20, a konečné — 1.21.

Ukladanie dát

Hlavná práca v oblasti storage, ako aj v predchádzajúcich vydaniach, sa pozoruje v oblasti podpory CSI. Hlavnými zmenami tu boli:

po prvýkrát (v alfa verzii) sa objavila podpora CSI pluginov pre pracovné uzly s Windows: aktuálny spôsob práce s úložiskami, ktorý nahradí in-tree pluginy v jadre Kubernetes a FlexVolume pluginy od Microsoftu na báze Powershell;

Schéma implementácie CSI pluginov v Kubernetes pre Windows
možnosť zmeny veľkosti CSI zväzkov, predstavená ešte v K8s 1.12, dosiahla beta verziu;
rovnakého „zvýšenia“ (z alfa na beta verziu) dosiahla možnosť využitia CSI pre vytváranie lokálnych efemérnych zväzkov (CSI Inline Volume Support).

Funkcia klonovania zväzkov, ktorá sa objavila v predchádzajúcej verzii Kubernetes, (využitie existujúcich PVC ako DataSource pre vytváranie nových PVC) tiež teraz získala status beta verzie.

Plánovač

Dve významné zmeny v plánovaní (obe v alfa verzii):

EvenPodsSpreading — možnosť využívať na „fair distribution“ zaťaženia pod’y namiesto logických jednotiek aplikácie (ako Deployment a ReplicaSet) a regulácia tohto rozdelenia (ako prísne požiadavky alebo ako mäkké podmienky, t.j. priorita). Funkcia rozšíri súčasné možnosti distribúcie plánovaných pod’ov, ktoré sú v súčasnosti obmedzené voľbami PodAffinity a PodAntiAffinity, poskytujúc administrátorom jemnejšiu kontrolu v tejto oblasti, čo znamená - lepšiu vysokú dostupnosť a optimalizované využitie zdrojov. Podrobnosti - v KEP.
Použitie Politika BestFit v Funkcia priority RequestedToCapacityRatio počas plánovania podov, čo umožní používať bin packing („balenie do kontajnerov“) ako pre základné zdroje (procesor, pamäť), tak aj pre rozšírené (napríklad GPU). Viac informácií nájdete v KEP.

Plánovanie podov: pred použitím politiky najlepšieho prispôsobenia (priamo cez predvoleného plánovača) a s jej použitím (cez rozšírenie plánovača)

Okrem toho, je predstavená možnosť vytvárať svoje pluginy pre plánovač mimo hlavného vývoja Kubernetes (out-of-tree).

Ďalšie zmeny

Taktiež v vydaní Kubernetes 1.16 môžeme spomenúť iniciatívu na usporiadanie existujúcich metrík do plného poriadku, a ak presnejšie - v súlade s oficiálnymi predpismi k nástrojom K8s. Tieto sú do veľkej miery založené na zodpovedajúcej dokumentácii Prometheus. Nesúlad vznikol z rôznych dôvodov (napríklad niektoré metriky boli jednoducho vytvorené ešte predtým, ako sa objavili súčasné inštrukcie), a vývojári sa rozhodli, že nastal čas uviesť všetko do jedného štandardu, „v súlade s ostatnou ekosystémou Prometheus“. Súčasná implementácia tejto iniciatívy má status alfa verzie, ktorý sa postupne zvýši v nasledujúcich verziách Kubernetes na beta (1.17) a stabilnú (1.18).

Okrem toho môžeme spomenúť nasledujúce zmeny:

Rozvoj podpory systému Windows s súvisí s nástrojom Kubeadm pre tento OS (alfa verzia), možnosťou RunAsUserName pre kontajnery Windows (alfa verzia), vylepšenie podporou Group Managed Service Account (gMSA) až do beta verzie, podporou mount/attach pre zväzky vSphere.
Prepracovaný mechanizmus kompresie dát v odpovediach API. Skôr sa na tieto účely používal HTTP filter, ktorý ukladal niekoľko obmedzení, brániac jeho zapnutiu predvolene. Teraz funguje „priehľadná kompresia požiadaviek“: klienti, ktorí posielajú Accept-Encoding: gzip v hlavičke, dostanú odpoveď komprimovanú s GZIP, ak jej veľkosť presiahla 128 KB. Klienti v Go automaticky podporujú kompresiu (posielajú potrebnú hlavičku), takže okamžite spoznajú pokles prenosu. (Pre iné jazyky môžu byť potrebné malé úpravy.)
Stala sa možnou škálovanie HPA z/do nuly podov na základe externých metríkAk sa škálovanie vykonáva na základe objektov/vonkajších metrik, môže sa automaticky zmenšiť na 0 replík, keď pracovné zaťaženia odpočívajú, aby sa ušetrili zdroje. Táto funkcia by mala byť mimoriadne užitočná najmä v prípadoch, keď pracovníci požadujú GPU zdroje a počet rôznych typov nečinných pracovníkov presahuje počet dostupných GPU.
Nový klient — k8s.io/client-go/metadata.Client — pre 'generický' prístup k objektom. Je určený na to, aby bolo jednoduché získať metadáta (t.j. pododdiel metadata) zo zdrojov klastra a vykonávať s nimi operácie, ako sú zbieranie odpadu a kvótovanie.
Zbierať Kubernetes teraz môžete bez zastaraných ("vstavaných" do in-tree) cloudových poskytovateľov (alfa verzia).
Do nástroja kubeadm bol pridaný bola pridaná experimentálna (alfa verzia) možnosť aplikovať kustomizované patche počas operácií init, join a upgrade. Viac informácií o tom, ako používať flag --experimental-kustomize, nájdete v KEP.
Nový endpoint pre apiserver — readyz, — umožňuje exportovať informácie o jeho pripravenosti (readiness). Tiež sa objavil flag API servera --maximum-startup-sequence-duration, ktorý umožňuje regulovať jeho reštarty.
Dve funkcie pre Azure boli vyhlásené za stabilné: podpora zón dostupnosti (Availability Zones) a cross resource group (RG). Okrem toho sa v Azure pridala:
- podpora autentifikácie AAD a ADFS;
- annotácia service.beta.kubernetes.io/azure-pip-name na určenie verejnej IP adresy pre vyrovnávač záťaže;
- možnosť nastavenia LoadBalancerName a LoadBalancerResourceGroup.
AWS dostal podpora pre EBS na Windows a optimalizované API volania EC2 DescribeInstances.
Kubeadm teraz samostatne migruje konfiguráciu CoreDNS pri aktualizácii verzie CoreDNS.
Binárky etcd v príslušnom Docker obraze uskutočnili sú world-executable, čo umožňuje spúšťať tento obraz bez potreby práv root. Okrem toho, obraz migrácie etcd prestala podporovať verziu etcd2.
V Cluster Autoscaler 1.16.0 prešiel na používanie distroless ako základného obrazu, zlepšil výkonnosť, pridal nových poskytovateľov cloudu (DigitalOcean, Magnum, Packet).
Aktualizácie v používanom/závislom softvéri: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Prečítajte si tiež na našom blogu:

Zdroj: habr.com