Kubernetes 1.16: Nejdůležitější novinky

Dnes, ve středu, držený další vydání Kubernetes - 1.16. Podle tradice, která se pro náš blog rozvinula, je to již desáté výročí, kdy mluvíme o nejvýznamnějších změnách v nové verzi.

Informace použité k přípravě tohoto materiálu jsou převzaty z Tabulky sledování vylepšení Kubernetes, ZMĚNA-1.16 a související problémy, žádosti o stažení a návrhy vylepšení Kubernetes (KEP). Tak pojďme!..

Uzly

Skutečně velké množství pozoruhodných inovací (ve stavu alfa verze) je prezentováno na straně uzlů clusteru K8s (Kubelet).

Za prvé, tzv «efemérní nádoby» (Ephemeral Containers), navržený tak, aby zjednodušil procesy ladění v modulech. Nový mechanismus umožňuje spouštět speciální kontejnery, které začínají ve jmenném prostoru existujících podů a žijí po krátkou dobu. Jejich účelem je interakce s ostatními moduly a kontejnery za účelem řešení jakýchkoli problémů a ladění. Pro tuto funkci byl implementován nový příkaz kubectl debug, ve své podstatě podobný kubectl exec: pouze místo spuštění procesu v kontejneru (jako v exec) spustí kontejner v podu. Tento příkaz například připojí nový kontejner k podu:

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

Podrobnosti o pomíjivých kontejnerech (a příklady jejich použití) najdete v odpovídající KEP. Aktuální implementace (v K8s 1.16) je alfa verze a mezi kritérii pro její převedení do beta verze je „testování rozhraní API efemérních kontejnerů pro alespoň 2 vydání [Kubernetes].

NB: Ve své podstatě a dokonce i ve svém názvu tato funkce připomíná již existující plugin kubectl-debugo kterých my již napsal. Očekává se, že s příchodem efemérních kontejnerů ustane vývoj samostatného externího pluginu.

Další inovace - PodOverhead - navržen tak, aby poskytoval mechanismus pro výpočet režijních nákladů na pod, které se mohou značně lišit v závislosti na použitém runtime. Jako příklad autoři tento KEP výsledkem jsou kontejnery Kata, které vyžadují spuštění hostujícího jádra, agenta kata, init systému atd. Když je režie tak velká, nelze ji ignorovat, což znamená, že musí existovat způsob, jak ji vzít v úvahu pro další kvóty, plánování atd. Chcete-li to implementovat PodSpec pole přidáno Overhead *ResourceList (porovnává s údaji v RuntimeClass, pokud se používá).

Další pozoruhodnou novinkou je správce topologie uzlů (Správce topologie uzlů), navržený tak, aby sjednotil přístup k doladění alokace hardwarových prostředků pro různé komponenty v Kubernetes. Tato iniciativa je poháněna rostoucí potřebou různých moderních systémů (z oblasti telekomunikací, strojového učení, finančních služeb atd.) pro vysoce výkonné paralelní výpočty a minimalizaci zpoždění při provádění operací, k čemuž využívají pokročilé CPU a schopnosti hardwarové akcelerace. Takovéto optimalizace v Kubernetes byly doposud dosahovány díky nesourodým komponentám (CPU manager, Device manager, CNI) a nyní k nim přibude jednotné interní rozhraní, které sjednocuje přístup a zjednodušuje napojování nových podobných – tzv. topologie- vědomi - komponenty na straně Kubelet. Podrobnosti - v odpovídající KEP.

Diagram komponent správce topologie

Další funkce - kontrola kontejnerů za chodu (startovací sonda). Jak víte, u kontejnerů, jejichž spuštění trvá dlouho, je obtížné získat aktuální stav: buď jsou „zabity“ dříve, než skutečně začnou fungovat, nebo skončí na dlouhou dobu ve slepé uličce. Nová kontrola (povolená prostřednictvím funkce brány tzv StartupProbeEnabled) zruší – nebo spíše odloží – účinek jakýchkoli dalších kontrol až do okamžiku, kdy modul skončí. Z tohoto důvodu byla funkce původně nazvána pod-startup liveness-probe holdoff. U modulů, jejichž spuštění trvá dlouho, můžete stav dotazovat v relativně krátkých časových intervalech.

Kromě toho je ve stavu beta okamžitě k dispozici vylepšení pro RuntimeClass s podporou „heterogenních clusterů“. C Plánování RuntimeClass Nyní není vůbec nutné, aby každý uzel měl podporu pro každou třídu RuntimeClass: pro pody můžete vybrat třídu RuntimeClass, aniž byste přemýšleli o topologii clusteru. Dříve, aby se toho dosáhlo – aby pody skončily na uzlech s podporou všeho, co potřebují – bylo nutné přiřadit NodeSelectoru a tolerancím příslušná pravidla. V KEP Hovoří o příkladech použití a samozřejmě o detailech implementace.

Síť

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

• Podpora duální síťový zásobník - IPv4/IPv6 - a jeho odpovídající „porozumění“ na úrovni modulů, uzlů, služeb. Zahrnuje interoperabilitu IPv4-to-IPv4 a IPv6-IPv6 mezi pody, od podů po externí služby, referenční implementace (v rámci zásuvných modulů Bridge CNI, PTP CNI a Host-Local IPAM) a také zpětnou kompatibilitu s běžícími clustery Kubernetes Pouze IPv4 nebo IPv6. Podrobnosti o implementaci jsou v KEP.

  Příklad zobrazení 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 koncový bod - EndpointSlice API. Řeší problémy s výkonem/škálovatelností stávajícího Endpoint API, které ovlivňují různé komponenty v řídicí rovině (apiserver, etcd, endpoints-controller, kube-proxy). Nové API bude přidáno do skupiny Discovery API a bude schopno obsluhovat desítky tisíc koncových bodů backend na každé službě v clusteru sestávajícím z tisíců uzlů. Za tímto účelem je každá služba mapována na N objektů EndpointSlice, z nichž každý standardně nemá více než 100 koncových bodů (hodnota je konfigurovatelná). EndpointSlice API také poskytne příležitosti pro jeho budoucí vývoj: podpora více IP adres pro každý modul, nové stavy pro koncové body (nejen Ready и NotReady), dynamické podnastavení pro koncové body.

Ten uvedený v posledním vydání dosáhl beta verze finalizátorpojmenovaný service.kubernetes.io/load-balancer-cleanup a připojené ke každé službě s typem LoadBalancer. V okamžiku smazání takové služby zabrání skutečnému smazání zdroje, dokud není dokončeno „vyčištění“ všech příslušných prostředků balanceru.

API stroje

Skutečný „stabilizační milník“ je v oblasti serveru Kubernetes API a interakce s ním. Stalo se tak z velké části díky převedení do stabilního stavu těch, kteří nepotřebují zvláštní představování CustomResourceDefinitions (CRD), které mají beta status od dávných dob Kubernetes 1.7 (a to je červen 2017!). Stejná stabilizace přišla na související funkce:

• "podzdroje" s /status и /scale pro CustomResources;
• konverze verze pro CRD, založené na externím webhooku;
• nedávno představena (v K8s 1.15) výchozí hodnoty (výchozí) a automatické odstranění pole (prořezávání) pro CustomResources;
• příležitost pomocí schématu OpenAPI v3 k vytvoření a publikování dokumentace OpenAPI používané k ověření zdrojů CRD na straně serveru.

Další mechanismus, který je správcům Kubernetes již dlouho známý: přijímací webhook - také zůstal po dlouhou dobu ve stavu beta (od K8s 1.9) a nyní je prohlášen za stabilní.

Dvě další funkce dosáhly beta verze: platí na straně serveru и sledovat záložky.

A jediná významná novinka v alfa verzi byla selhání z SelfLink — speciální URI představující určený objekt a tvořící jeho součást ObjectMeta и ListMeta (tj. část jakéhokoli objektu v Kubernetes). Proč to opouštějí? Motivace jednoduchým způsobem zvuky jako absenci skutečných (drtivých) důvodů, proč tento obor stále existuje. Formálnějšími důvody je optimalizace výkonu (odstraněním nepotřebného pole) a zjednodušení práce generic-apiserveru, který je nucen s takovým polem zacházet zvláštním způsobem (toto je jediné pole, které je nastaveno přímo před objekt je serializován). Skutečná zastaralost (v rámci beta) SelfLink stane se Kubernetes verze 1.20 a konečná - 1.21.

Ukládání dat

Hlavní práce v oblasti skladování, stejně jako v předchozích verzích, je pozorována v této oblasti podpora CSI. Hlavní změny zde byly:

• poprvé (v alfa verzi) se objevil Podpora zásuvných modulů CSI pro pracovní uzly Windows: současný způsob práce s úložištěm nahradí také in-tree pluginy v jádře Kubernetes a FlexVolume pluginy od Microsoftu založené na Powershell;

  
  Schéma implementace pluginů CSI v Kubernetes pro Windows

• příležitost změna velikosti svazků CSI, představený zpět v K8s 1.12, se rozrostl do beta verze;
• Podobného „povýšení“ (z alfa na beta) bylo dosaženo schopností používat CSI k vytváření místních efemérních svazků (CSI Inline Volume Support).

Zavedeno v předchozí verzi Kubernetes funkce klonování objemu (s použitím stávajícího PVC jako DataSource k vytvoření nového PVC) nyní také získal status beta.

Планировщик

Dvě významné změny v plánování (obě v alfa verzi):

• EvenPodsSpreading - příležitost použijte pody místo logických aplikačních jednotek pro „spravedlivé rozdělení“ zátěže (jako Deployment a ReplicaSet) a úpravu této distribuce (jako tvrdý požadavek nebo jako měkký stav, tj. prioritu). Tato funkce rozšíří stávající distribuční možnosti plánovaných modulů, které jsou v současné době omezené možnostmi PodAffinity и PodAntiAffinity, což správcům poskytuje jemnější kontrolu v této záležitosti, což znamená lepší vysokou dostupnost a optimalizovanou spotřebu zdrojů. Podrobnosti - v KEP.
• Použití Zásady BestFit в Funkce priority RequestedToCapacityRatio při plánování podu, což umožní platí popelnicové balení (“balení do kontejnerů”) pro základní zdroje (procesor, paměť) i rozšířené (jako GPU). Další podrobnosti viz KEP.

  
  Plánování modulů: před použitím zásady nejlepšího přizpůsobení (přímo prostřednictvím výchozího plánovače) a s jeho použitím (prostřednictvím rozšíření plánovače)

Kromě toho, zastoupená možnost vytvářet vlastní pluginy plánovače mimo hlavní vývojový strom Kubernetes (mimo strom).

Další změny

Také ve verzi Kubernetes 1.16 to lze poznamenat iniciativa pro přinášení dostupné metriky v plném pořadí, přesněji v souladu s úřední předpisy na přístrojové vybavení K8s. Z velké části se spoléhají na odpovídající Dokumentace Prometheus. Nesrovnalosti vznikly z různých důvodů (například některé metriky byly jednoduše vytvořeny dříve, než se objevily aktuální pokyny), a vývojáři se rozhodli, že je čas uvést vše do jednotného standardu, „v souladu se zbytkem ekosystému Prometheus“. Aktuální implementace této iniciativy je ve stavu alfa, který bude v následujících verzích Kubernetes postupně povýšen na beta (1.17) a stabilní (1.18).

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

• Windows podporují vývoj с vzhled Nástroje Kubeadm pro tento OS (alfa verze), příležitost RunAsUserName pro kontejnery Windows (verze alfa), zlepšení Podpora Group Managed Service Account (gMSA) až do beta verze, Podpěra, podpora připojit/připojit pro svazky vSphere.
• Recyklovaný mechanismus komprese dat v odpovědích API. Dříve se pro tyto účely používal HTTP filtr, který ukládal řadu omezení, která bránila jeho výchozímu povolení. "Transparentní komprese požadavků" nyní funguje: klienti odesílají Accept-Encoding: gzip v hlavičce obdrží GZIP komprimovanou odpověď, pokud její velikost přesáhne 128 KB. Klienti Go automaticky podporují kompresi (odeslání požadované hlavičky), takže okamžitě zaznamenají snížení provozu. (U jiných jazyků mohou být nutné drobné úpravy.)
• Stal se možným škálování HPA od/do nulových modulů na základě externích metrik. Pokud škálujete na základě objektů/externích metrik, pak při nečinnosti úloh můžete automaticky škálovat na 0 replik, abyste ušetřili zdroje. Tato funkce by měla být užitečná zejména v případech, kdy pracovníci požadují zdroje GPU a počet různých typů nečinných pracovníků převyšuje počet dostupných GPU.
• Nový klient - k8s.io/client-go/metadata.Client — pro „generalizovaný“ přístup k objektům. Je navržen tak, aby snadno získal metadata (tj metadata) z klastrových zdrojů a provádět s nimi operace úklidu a kvót.
• Sestavte Kubernetes teď můžeš bez starších ("vestavěných" in-tree) poskytovatelů cloudu (alfa verze).
• K nástroji kubeadm přidal experimentální (alfa verze) schopnost aplikovat přizpůsobené záplaty během operací init, join и upgrade. Zjistěte více o tom, jak používat vlajku --experimental-kustomize, viz v KEP.
• Nový koncový bod pro apiserver - readyz, - umožňuje exportovat informace o jeho připravenosti. Server API má nyní také příznak --maximum-startup-sequence-duration, což vám umožní regulovat jeho restarty.
• Dva funkce pro Azure prohlášen za stabilní: podpora zóny dostupnosti (Zóny dostupnosti) a křížová skupina zdrojů (RG). Kromě toho Azure přidal:
  • podporu autentizace AAD a ADFS;
  • anotace service.beta.kubernetes.io/azure-pip-name specifikovat veřejnou IP load balanceru;
  • příležitost настройки LoadBalancerName и LoadBalancerResourceGroup.
• AWS nyní má podpora pro EBS na Windows a optimalizované EC2 API volání DescribeInstances.
• Kubeadm je nyní nezávislý migruje Konfigurace CoreDNS při upgradu verze CoreDNS.
• Binární soubory atd v odpovídajícím obrázku Dockeru udělali world-executable, který umožňuje spouštět tento obraz bez potřeby práv root. Také obrázek migrace etcd přestal podpora verze etcd2.
• В Cluster Autoscaler 1.16.0 přešel na používání distroless jako základního obrazu, zlepšil se výkon, přidali se noví poskytovatelé cloudu (DigitalOcean, Magnum, Packet).
• Aktualizace použitého/závislého softwaru: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Přečtěte si také na našem blogu:

• «Kubernetes 1.15: Nejdůležitější novinky";
• «Kubernetes 1.14: Nejdůležitější novinky";
• «Kubernetes 1.13: Nejdůležitější novinky";
• «Kubernetes 1.12: Nejdůležitější novinky".

Zdroj: www.habr.com