🥇Kubernetes 1.16: přehled hlavních novinek

Dnes, ve středu, se uskuteční další vydání Kubernetes — 1.16. Podle tradice našeho blogu již po desáté představujeme nejvýznamnější změny v nové verzi.

Informace použité k přípravě tohoto materiálu byly převzaty z tabulka sledování zlepšení Kubernetes, CHANGELOG-1.16 a příslušných issues, pull requests a také Kubernetes Enhancement Proposals (KEP). Tak tedy, jdeme na to!..

Uzly

Opravdu velký počet pozoruhodných novinek (ve stavu alfa verze) je prezentován na straně uzlů K8s klastrů (Kubelet).

Nejprve byly představeny takzvané «efemérní kontejnery» (Ephemeral Containers), které mají usnadnit procesy ladění v podech. Nový mechanismus umožňuje spouštění speciálních kontejnerů, které se spouštějí v jmenném prostoru existujících podů a žijí jen krátkou dobu. Jejich účelem je interakce s ostatními podmi a kontejnery za účelem řešení problémů a ladění. Pro tuto funkci byla implementována nová příkazová řádka kubectl debug, která je v podstatě podobná kubectl exec: jen místo spuštění procesu v kontejneru (jak je tomu u exec) spouští kontejner v podu. Například takový příkaz připojí nový kontejner k podu:

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

Podrobnosti o efemérních kontejnerech (a příklady jejich použití) lze nalézt v příslušném KEP. Aktuální implementace (v K8s 1.16) je alfa verze a mezi kritérii jejího převodu do beta verze je uvedeno „testování Ephemeral Containers API po dobu nejméně 2 vydání [Kubernetes]“.

NB: V podstatě a dokonce i podle názvu funkce připomíná již existující plugin kubectl-debug, o kterém jsme již psali. Předpokládá se, že s příchodem efemérních kontejnerů se vývoj samostatného externího pluginu zastaví.

Další novinkou je PodOverhead — který má poskytnout mechanismus pro výpočet režijních nákladů na pod, které se mohou výrazně lišit v závislosti na používaném běhovém prostředí (runtime). Jako příklad autoři tohoto KEP uvádějí Kata Containers, které vyžadují spuštění hostitelského jádra, agenta kata, init systému atd. Když se režie stává tak vysokou, že ji nelze ignorovat, je třeba způsob, jak ji zohlednit pro další kvótování, plánování atd. Pro její implementaci bylo do PodSpec přidáno pole Overhead *ResourceList (je přiřazeno k datům v RuntimeClass, pokud se používá).

Další výraznou novinkou je správce topologie uzlu (Node Topology Manager), který má za cíl sjednotit přístup k jemnému ladění rozdělení hardwarových zdrojů pro různé komponenty v Kubernetes. Tato iniciativa je reakcí na rostoucí potřebu různých moderních systémů (v oblasti telekomunikací, strojového učení, finančních služeb atd.) po vysoce výkonných paralelních výpočtech a minimalizaci latencí během provádění operací, pro které využívají pokročilé schopnosti CPU a hardwarové akcelerace. Takové optimalizace v Kubernetes byly dosud dosahovány díky rozptýleným komponentům (CPU manager, Device manager, CNI), a nyní bude přidán jednotný vnitřní rozhraní, které sjednotí přístup a usnadní připojení nových podobných – takzvaných topology-aware – komponent na straně Kubelet. Podrobnosti najdete v příslušném KEP.

Schéma komponentů Topology Manager

Další funkcí je kontrola kontejnerů při jejich spuštění (startup probe). Jak bylo známo, pro kontejnery, které se dlouho spouštějí, je obtížné získat aktuální stav: buď jsou "zabity" ještě před skutečným začátkem fungování, nebo na dlouhou dobu uvíznou v deadlocku. Nová kontrola (aktivuje se přes feature gate s názvem StartupProbeEnabled) zruší – nebo lépe řečeno, odloží – provádění jakýchkoli dalších kontrol do doby, kdy pod dokončil svůj start. Z tohoto důvodu byla funkce původně nazvána pod-startup liveness-probe holdoff. Pro pod’y, které se dlouho startují, je možné provádět dotazy o stavu v relativně krátkých časových intervalech.

Kromě toho je ihned ve statusu beta-version k dispozici vylepšení pro RuntimeClass, které přidává podporu „heterogenních klastrů“. S RuntimeClass Scheduling nyní není nutné, aby každý uzel měl podporu každého RuntimeClass’u: pro pod’y lze vybírat RuntimeClass, aniž by se přemýšlelo o topologii klastru. Dříve bylo třeba pro dosažení tohoto cíle – aby pod’y byly na uzlech, které podporují vše, co potřebují – přidávat odpovídající pravidla do NodeSelector a tolerations. V KEP se popisují příklady použití a samozřejmě podrobnosti implementace.

Síť

Dvě významné síťové funkce, které poprvé vznikly (v alfa verzi) v Kubernetes 1.16 – jsou:

Podpora dvojitého síťového zásobníku – IPv4/IPv6 — a odpovídající jeho «pochopení» na úrovni podů, uzlů a služeb. Zahrnuje interakci IPv4-to-IPv4 a IPv6-to-IPv6 mezi pody, z podů do externích služeb, referenční implementace (v rámci pluginů Bridge CNI, PTP CNI a Host-Local IPAM), a také zpětnou kompatibilitu s кластерами Kubernetes, které fungují pouze přes IPv4 nebo IPv6. Podrobnosti implementace — v KEP.
Příklad výstupu IP adres dvou typů (IPv4 a IPv6) v seznamu podů:
```
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 pro Endpoint — EndpointSlice API. Řeší problémy stávajícího Endpoint API s výkonem/škálovatelností, což ovlivňuje různé komponenty v control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Nové API bude přidáno do API skupiny Discovery a bude schopno obsluhovat desítky tisíc backend endpointů na každé službě v clusterech, které se skládají z tisíců uzlů. Každá Služba bude mapována do N objektů EndpointSlice, z nichž každý má ve výchozím nastavení maximálně 100 endpointů (hodnota je konfigurovatelná). V EndpointSlice API jsou zahrnuty i možnosti pro jeho budoucí rozvoj: podpora mnoha IP adres pro každý pod, nové stavy pro endpointy (nejen Ready a NotReady), dynamické subsetování pro endpointy.

Do beta verze postoupil prezentovaný v minulém vydání finalizer, nazvaný service.kubernetes.io/load-balancer-cleanup a připojený ke každé službě typu LoadBalancer. Při odstranění takové služby zabrání skutečnému odstranění zdroje, dokud není dokončeno „úklid“ všech souvisejících zdrojů vyrovnávače zatížení.

API Machinery

Skutečný „milník stabilizace“ byl zaznamenán v oblasti API serveru Kubernetes a jeho interakce. K tomu do značné míry přispělo převedení do stavu stable nepotřebujících zvláštní prezentaci CustomResourceDefinitions (CRD), které měly stav beta od dob vzdáleného Kubernetes 1.7 (a to je červen 2017!). Stejná stabilizace přišla i k souvisejícím funkcím:

„podzdroje“ (subresources) s /status a /scale pro CustomResources;
konverze verzí pro CRD, založená na externím webhooku;
nedávno představené (v K8s 1.15) výchozí hodnoty (defaulting) a automatické odstranění polí (pruning) pro CustomResources;
možnost aplikace schéma OpenAPI v3 pro vytváření a publikaci OpenAPI dokumentace, která se používá k validaci CRD zdrojů na straně serveru.

Další mechanismus, který se stal známým pro správce Kubernetes: admission webhook — který dlouhou dobu zůstal v beta verzi (s K8s 1.9) a nyní byl prohlášen za stabilní.

Dvě další funkce se dostaly do beta verze: server-side apply a watch bookmarks.

A jedinou významnou novinkou v alpha verzi bylo odklon od SelfLink — speciální URI představující daný objekt a tvořící součást ObjectMeta a ListMeta (tj. součást jakéhokoli objektu v Kubernetes). Proč se od něj ustupuje? Motivace „zjednodušeně“ zní jako absence skutečných (nepřekonatelných) důvodů, proč by toto pole mělo i nadále existovat. Formálnější důvody — optimalizace výkonu (odstraněním nepotřebného pole) a zjednodušení práce generic-apiserveru, který musí toto pole zpracovávat zvláštním způsobem (je to jediné pole, které se nastavuje těsně před serializací objektu). Skutečné „zastarání“ (v rámci beta verze) SelfLink nastane s verzí Kubernetes 1.20, a konečné — 1.21.

Ukládání dat

Hlavní práce v oblasti storage, stejně jako v předchozích vydáních, se soustředí na podporu CSI. Hlavními změnami zde bylo:

poprvé (v alpha verzi) se objevila podpora CSI pluginů pro pracovní uzly s Windows: moderní způsob práce s úložišti, který nahradí in-tree pluginy v jádře Kubernetes a FlexVolume pluginy od Microsoftu založené na Powershellu;

Schéma implementace CSI pluginů v Kubernetes pro Windows
možnost změna velikosti CSI svazků, představená už v K8s 1.12, dosáhla beta verze;
analogického „zvýšení“ (z alpha na beta verzi) dosáhla možnost použití CSI pro vytváření lokálních efemérních svazků (CSI Inline Volume Support).

Fnukce klonování svazků, která se objevila v předchozí verzi Kubernetes (využití existujících PVC jako DataSource pro vytváření nových PVC) také nyní získala status beta verze. Dvě významné změny v plánování (obe jsou v alpha verzi):

Plánovač

EvenPodsSpreading

— možnost použít pro „férové rozložení“ zátěže pody místo logických jednotek aplikace (jako Deployment a ReplicaSet) a regulaci tohoto rozložení (jako tvrdou podmínku nebo jako měkkou podmínku, tj. prioritu). Funkce rozšíří stávající možnosti rozložení plánovaných podů, které jsou nyní omezeny volbami PodAffinity PodAntiAffinity a PodAntiAffinity, což poskytuje správcům jemnější kontrolu v této oblasti, což znamená lepší vysokou dostupnost a optimalizovanou spotřebu zdrojů. Podrobnosti najdete v KEP.
Použití Politika BestFit v Funkce priority RequestedToCapacityRatio během plánování podů, což umožní aplikovat bin packing („balení do kontejnerů“) jak pro základní zdroje (procesor, paměť), tak i pro rozšířené (například GPU). Více informací najdete v KEP.

Plánování podů: před použitím politiky best fit (přímo přes výchozí plánovač) a s jejím použitím (přes rozšiřovač plánovače)

Kromě toho, byla představena možnost vytvářet vlastní pluginy pro plánovač mimo hlavní vývojovou větev Kubernetes (out-of-tree).

Další změny

Také v verzi Kubernetes 1.16 lze zaznamenat iniciativu pro sjednocení existujících metrik do pořádku, nebo přesněji — do souladu s oficiálními předpisy pro instrumentaci K8s. Ty se ve velké míře opírají o odpovídající dokumentaci Prometheus. Nesrovnalosti vznikly z různých důvodů (například některé metriky byly jednoduše vytvořeny ještě před tím, než se objevily aktuální pokyny), a vývojáři se rozhodli, že nastal čas sjednotit všechno na jeden standard, "v souladu s ostatními ekosystémy Prometheus". Aktuální implementace této iniciativy má status alfa verze, který bude postupně zvyšován ve dalších verzích Kubernetes na beta (1.17) a stabilní (1.18).

Kromě toho lze zaznamenat následující změny:

Rozvoj podpory Windows s zavedením nástroje Kubeadm pro tento operační systém (verze alfa), možnost RunAsUserName pro Windows kontejnery (verze alfa), zlepšením podporu Group Managed Service Account (gMSA) do beta verze, podporou mount/attach pro svazky vSphere.
Přehodnocený mechanismus komprese dat v odpovědích API. Dříve se k těmto účelům používal HTTP filtr, který měl řadu omezení, bránících jeho povolení ve výchozím nastavení. Nyní funguje "průhledná komprese požadavků": klienti, kteří posílají Accept-Encoding: gzip v hlavičce, dostanou zkomprimovanou odpověď ve formátu GZIP, pokud její velikost překročila 128 kB. Klienti na Go automaticky podporují kompresi (odesílají potřebnou hlavičku), takže si okamžitě všimnou snížení provozu. (Pro jiné jazyky mohou být potřeba drobné úpravy.)
Bylo možné škálování HPA z/do nulových podů na základě externích metrikPokud je škálování prováděno na základě objektů/externích metrik, je možné při nečinnosti pracovních zátěží automaticky zmenšit počet replik na 0, aby se ušetřily zdroje. Tato funkce bude zvlášť užitečná v případech, kdy pracovníci požadují GPU zdroje a počet různých typů nečinných pracovníků překračuje dostupné GPU.
Nový klient — k8s.io/client-go/metadata.Client — pro „generalizovaný“ přístup k objektům. Je určen pro snadný přístup k metadatům (tj. podřízené metadata) z prostředků clusteru a provádění operací, jako je úklid a kvótování.
Sběr Kubernetes nyní lze bez zastaralých („vestavěných“ do in-tree) cloudových poskytovatelů (beta verze).
Do nástroje kubeadm přidali byla přidána experimentální (beta verze) možnost aplikovat kustomizované patche při operacích init, připojit a upgrade. Podrobnosti o použití příznaku --experimental-kustomize, viz KEP.
Nový endpoint pro apiserver — readyz, — který umožňuje exportovat informace o jeho připravenosti (readiness). Také api-server dostal příznak --maximum-startup-sequence-duration, který umožňuje regulovat jeho restartování.
Dvě funkce pro Azure byly vyhlášeny za stabilní: podpora oblastí dostupnosti (Availability Zones) a cross resource group (RG). Kromě toho byla do Azure přidána podpora:
- autentizace AAD a ADFS;
- annotations service.beta.kubernetes.io/azure-pip-name pro určení veřejné IP u vyrovnávače zatížení;
- možnost nastavení LoadBalancerName a LoadBalancerResourceGroup.
AWS nyní nabízí podpora pro EBS ve Windows a optimalizované API volání EC2 DescribeInstances.
Kubeadm nyní sám migruje konfiguraci CoreDNS při aktualizaci verze CoreDNS.
Binárky etcd ve správném Docker obraze přispěli world-executable, což umožňuje spouštět tento obraz bez nutnosti práv root. Navíc obraz migrace etcd natrvalo ukončil podporuje verzi etcd2.
V Cluster Autoscaler 1.16.0 přešel na používání distroless jako základního obrazu, zlepšil výkon, přidal nové cloudové poskytovatele (DigitalOcean, Magnum, Packet).
Aktualizace v používaném/závislém softwaru: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Přečtěte si také náš blog:

Zdroj: habr.com