ProHoster > Blog > Administrácia > Kubernetes 1.16: prehľad hlavných inovácií

Kubernetes 1.16: prehľad hlavných inovácií

Kubernetes 1.16: prehľad hlavných inovácií

Dnes, v stredu, sa uskutoční ďalšie vydanie Kubernetes - 1.16. Podľa tradície, ktorá sa vytvorila pre náš blog, je to už desiate výročie, čo hovoríme o najvýznamnejších zmenách v novej verzii.

Informácie použité na prípravu tohto materiálu sú prevzaté z Tabuľky sledovania vylepšení Kubernetes, ZMENA-1.16 a súvisiace problémy, požiadavky na stiahnutie a návrhy na vylepšenie Kubernetes (KEP). Tak, poďme!..

Uzly

Skutočne veľké množstvo pozoruhodných inovácií (v stave alfa verzie) je prezentovaných na strane uzlov klastra K8s (Kubelet).

Po prvé, tzv «efemérne nádoby» (Ephemeral Containers), navrhnutý na zjednodušenie procesov ladenia v moduloch. Nový mechanizmus vám umožňuje spúšťať špeciálne kontajnery, ktoré začínajú v mennom priestore existujúcich modulov a žijú krátky čas. Ich účelom je interagovať s inými modulmi a kontajnermi s cieľom vyriešiť akékoľvek problémy a ladiť. Pre túto funkciu bol implementovaný nový príkaz kubectl debug, vo svojej podstate podobný kubectl exec: iba namiesto spustenia procesu v kontajneri (ako v exec) spustí kontajner v kapsule. Napríklad tento príkaz pripojí nový kontajner k podu:

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

Podrobnosti o efemérnych kontajneroch (a príkladoch ich použitia) nájdete v zodpovedajúci KEP. Aktuálna implementácia (v K8s 1.16) je alfa verzia a medzi kritériá na jej prenos do beta verzie patrí „testovanie rozhrania Ephemeral Containers API pre najmenej 2 vydania [Kubernetes].

NB: Funkcia vo svojej podstate a dokonca aj vo svojom názve pripomína už existujúci plugin kubectl-debugo ktorých sme už napísal. Očakáva sa, že s príchodom efemérnych kontajnerov sa vývoj samostatného externého pluginu zastaví.

Ďalšia inovácia - PodOverhead - určený na poskytovanie mechanizmus výpočtu režijných nákladov na pod, ktorý sa môže značne líšiť v závislosti od použitého runtime. Ako príklad autori tento KEP výsledkom sú kontajnery Kata, ktoré vyžadujú spustenie hosťujúceho jadra, agenta kata, init systému atď. Keď je réžia taká veľká, nemožno ju ignorovať, čo znamená, že musí existovať spôsob, ako ju zohľadniť pri ďalších kvótach, plánovaní atď. Aby ste to implementovali v PodSpec pole pridané Overhead *ResourceList (v porovnaní s údajmi v RuntimeClass, ak sa používa).

Ďalšou pozoruhodnou inováciou je manažér topológie uzla (Správca topológie uzla), navrhnutý tak, aby zjednotil prístup k dolaďovaniu alokácie hardvérových zdrojov pre rôzne komponenty v Kubernetes. Táto iniciatíva je poháňaná rastúcou potrebou rôznych moderných systémov (z oblasti telekomunikácií, strojového učenia, finančných služieb atď.) pre vysokovýkonné paralelné výpočty a minimalizáciu oneskorení pri vykonávaní operácií, na ktoré využívajú pokročilé CPU a možnosti hardvérovej akcelerácie. Takéto optimalizácie v Kubernetes boli doteraz dosahované vďaka nesúrodým komponentom (CPU manager, Device manager, CNI) a teraz k nim pribudne jednotné interné rozhranie, ktoré zjednotí prístup a zjednoduší pripájanie nových podobných – tzv. vedomé - komponenty na strane Kubelet. Podrobnosti - v zodpovedajúci KEP.

Kubernetes 1.16: prehľad hlavných inovácií
Diagram komponentov manažéra topológie

Ďalšia funkcia - kontrola kontajnerov počas ich prevádzky (štartovacia sonda). Ako viete, pre kontajnery, ktorých spustenie trvá dlho, je ťažké získať aktuálny stav: buď sú „zabité“ skôr, ako začnú skutočne fungovať, alebo sa na dlhý čas dostanú do slepej uličky. Nová kontrola (povolená prostredníctvom brány funkcie tzv StartupProbeEnabled) zruší – alebo skôr odloží – účinok akýchkoľvek iných kontrol až do okamihu, keď modul skončí. Z tohto dôvodu bola funkcia pôvodne tzv pod-startup liveness-probe holdoff. V prípade modulov, ktorých spustenie trvá dlho, môžete v relatívne krátkych časových intervaloch zisťovať stav.

Okrem toho je v stave beta okamžite k dispozícii vylepšenie RuntimeClass, ktoré pridáva podporu pre „heterogénne klastre“. C Plánovanie RuntimeClass Teraz už vôbec nie je potrebné, aby mal každý uzol podporu pre každú triedu RuntimeClass: pre moduly si môžete vybrať triedu RuntimeClass bez toho, aby ste premýšľali o topológii klastra. Predtým, aby sa to dosiahlo - aby pody skončili na uzloch s podporou pre všetko, čo potrebujú - bolo potrebné priradiť príslušné pravidlá pre NodeSelector a tolerancie. IN CAP Hovorí o príkladoch použitia a samozrejme o detailoch implementácie.

Sieť

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

  • Podpora duálny sieťový zásobník - IPv4/IPv6 - a jeho zodpovedajúce „pochopenie“ na úrovni modulov, uzlov, služieb. Zahŕňa interoperabilitu IPv4-IPv4 a IPv6-IPv6 medzi modulmi, od modulov po externé služby, referenčné implementácie (v rámci zásuvných modulov Bridge CNI, PTP CNI a Host-Local IPAM), ako aj spätnú kompatibilitu so spustenými klastrami Kubernetes Iba IPv4 alebo IPv6. Podrobnosti o implementácii sú v CAP.

    Príklad zobrazenia adries IP dvoch typov (IPv4 a IPv6) v zozname modulov:

    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 koncový bod - EndpointSlice API. Rieši problémy s výkonom/škálovateľnosťou existujúceho Endpoint API, ktoré ovplyvňujú rôzne komponenty v riadiacej rovine (apiserver, etcd, endpoints-controller, kube-proxy). Nové API bude pridané do skupiny Discovery API a bude schopné obsluhovať desiatky tisíc koncových bodov na každej službe v klastri pozostávajúcom z tisícok uzlov. Na tento účel je každá služba namapovaná na N objektov EndpointSlice, z ktorých každý štandardne nemá viac ako 100 koncových bodov (hodnota je konfigurovateľná). EndpointSlice API tiež poskytne príležitosti pre jeho budúci vývoj: podpora viacerých IP adries pre každý modul, nové stavy pre koncové body (nielen Ready и NotReady), dynamické podnastavenie pre koncové body.

Ten uvedený v poslednom vydaní dosiahol beta verziu finalizátor, pomenovaný service.kubernetes.io/load-balancer-cleanup a pripojené ku každej službe s typom LoadBalancer. V čase vymazania takejto služby zabraňuje skutočnému vymazaniu zdroja, kým sa nedokončí „vyčistenie“ všetkých relevantných zdrojov balancera.

API Machinery

Skutočný „stabilizačný míľnik“ je v oblasti servera Kubernetes API a interakcie s ním. Stalo sa tak z veľkej časti vďaka prechod do stabilného stavu tých, ktorí nepotrebujú špeciálne predstavenie CustomResourceDefinitions (CRD), ktoré majú beta status od dávnych čias Kubernetes 1.7 (a toto je jún 2017!). Rovnaká stabilizácia prišla k súvisiacim funkciám:

  • "podzdroje" s /status и /scale pre CustomResources;
  • premena verzie pre CRD, založené na externom webhooku;
  • nedávno predstavený (v K8s 1.15) predvolené hodnoty (predvolené) a automatické odstraňovanie poľa (prerezávanie) pre CustomResources;
  • príležitosť pomocou schémy OpenAPI v3 na vytvorenie a publikovanie dokumentácie OpenAPI používanej na overenie zdrojov CRD na strane servera.

Ďalší mechanizmus, ktorý je už dlho známy správcom Kubernetes: prijímací webhook - tiež zostal dlho v beta stave (od K8s 1.9) a teraz je vyhlásený za stabilný.

Dve ďalšie funkcie dosiahli beta verziu: použiť na strane servera и sledovať záložky.

A jedinou výraznou inováciou v alfa verzii bola zlyhanie od SelfLink — špeciálne URI, ktoré predstavuje špecifikovaný objekt a je jeho súčasťou ObjectMeta и ListMeta (t. j. súčasť akéhokoľvek objektu v Kubernetes). Prečo to opúšťajú? Motivácia jednoduchým spôsobom zvuky ako absencia skutočných (prevažujúcich) dôvodov, prečo táto oblasť stále existuje. Formálnejšie dôvody sú optimalizácia výkonu (odstránením nepotrebného poľa) a zjednodušenie práce generic-apiserveru, ktorý je nútený s takýmto poľom zaobchádzať špeciálnym spôsobom (toto je jediné pole, ktoré je nastavené priamo pred objektom je serializovaný). Skutočné zastaranie (v rámci beta verzie) SelfLink stane sa Kubernetes verzia 1.20 a konečná - 1.21.

Ukladanie údajov

Hlavná práca v oblasti skladovania, ako v predchádzajúcich vydaniach, sa pozoruje v tejto oblasti podpora CSI. Hlavné zmeny tu boli:

  • prvýkrát (v alfa verzii) objavil Podpora doplnkov CSI pre pracovné uzly Windows: súčasný spôsob práce s úložiskom nahradí aj in-tree pluginy v jadre Kubernetes a FlexVolume pluginy od Microsoftu založené na Powershell;

    Kubernetes 1.16: prehľad hlavných inovácií
    Schéma implementácie doplnkov CSI v Kubernetes pre Windows

  • príležitosť zmena veľkosti zväzkov CSI, predstavený už v K8s 1.12, sa rozrástol na beta verziu;
  • Podobná „propagácia“ (z alfa na beta) bola dosiahnutá možnosťou použiť CSI na vytváranie lokálnych efemérnych objemov (CSI Inline Volume Support).

Zavedené v predchádzajúcej verzii Kubernetes funkcia klonovania objemu (použitím existujúceho PVC ako DataSource vytvoriť nový PVC) teraz tiež získal status beta.

Plánovač

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

  • EvenPodsSpreading - príležitosť použite pody namiesto logických aplikačných jednotiek na „spravodlivé rozloženie“ záťaže (ako Deployment a ReplicaSet) a prispôsobenie tejto distribúcie (ako tvrdá požiadavka alebo ako mäkká podmienka, t. j. priorita). Táto funkcia rozšíri existujúce možnosti distribúcie plánovaných modulov, ktoré sú momentálne obmedzené možnosťami PodAffinity и PodAntiAffinity, čo dáva administrátorom jemnejšiu kontrolu v tejto záležitosti, čo znamená lepšiu vysokú dostupnosť a optimalizovanú spotrebu zdrojov. Podrobnosti - v CAP.
  • Použitie Pravidlá BestFit в Prioritná funkcia RequestedToCapacityRatio pri plánovaní pod, čo umožní platiť balenie do koša („balenie do kontajnerov“) pre základné zdroje (procesor, pamäť) aj rozšírené zdroje (napríklad GPU). Ďalšie podrobnosti nájdete v časti CAP.

    Kubernetes 1.16: prehľad hlavných inovácií
    Plánovanie modulov: pred použitím zásady najlepšieho prispôsobenia (priamo cez predvolený plánovač) a s jeho použitím (prostredníctvom rozširovača plánovača)

Okrem toho, zastúpené možnosť vytvárať si vlastné doplnky plánovača mimo hlavného vývojového stromu Kubernetes (mimo stromu).

Ďalšie zmeny

Môžete si všimnúť aj vo vydaní Kubernetes 1.16 iniciatíva pre prinášanie dostupné metriky v úplnom poradí, alebo presnejšie v súlade s úradných predpisov na prístrojové vybavenie K8s. Vo veľkej miere sa spoliehajú na zodpovedajúce Dokumentácia Prometheus. Nezrovnalosti vznikli z rôznych dôvodov (napríklad niektoré metriky boli jednoducho vytvorené skôr, ako sa objavili aktuálne pokyny) a vývojári sa rozhodli, že je čas uviesť všetko do jedného štandardu, „v súlade so zvyškom ekosystému Prometheus“. Aktuálna implementácia tejto iniciatívy je v stave alfa, ktorý bude postupne povýšený v nasledujúcich verziách Kubernetes na beta (1.17) a stabilnú (1.18).

Okrem toho je možné zaznamenať nasledujúce zmeny:

  • Windows podporuje vývoj с vznik Pomôcky Kubeadm pre tento OS (verzia alfa), príležitosť RunAsUserName pre kontajnery Windows (verzia alfa), zlepšenie Podpora Group Managed Service Account (gMSA) až do verzie beta, podpora pripojiť/pripojiť zväzky vSphere.
  • Recyklované mechanizmus kompresie údajov v odpovediach API. Predtým sa na tieto účely používal HTTP filter, ktorý ukladal množstvo obmedzení, ktoré bránili jeho štandardnému zapnutiu. Teraz funguje "transparentná kompresia požiadaviek": klienti odosielajú Accept-Encoding: gzip v hlavičke dostanú GZIP komprimovanú odpoveď, ak jej veľkosť presiahne 128 KB. Klienti Go automaticky podporujú kompresiu (odoslanie potrebnej hlavičky), takže si okamžite všimnú zníženie návštevnosti. (Pre iné jazyky môžu byť potrebné mierne úpravy.)
  • Stalo sa možným škálovanie HPA od/do nuly na základe externých metrík. Ak škálujete na základe objektov/externých metrík, potom, keď sú pracovné zaťaženia nečinné, môžete automaticky škálovať na 0 replík, aby ste ušetrili zdroje. Táto funkcia by mala byť užitočná najmä v prípadoch, keď pracovníci požadujú zdroje GPU a počet rôznych typov nečinných pracovníkov prevyšuje počet dostupných GPU.
  • Nový klient - k8s.io/client-go/metadata.Client — pre „všeobecný“ prístup k objektom. Je navrhnutý tak, aby ľahko získal metadáta (t. j. podsekciu metadata) zo zdrojov klastra a vykonávať s nimi operácie zbierania odpadu a kvót.
  • Zostavte Kubernetes teraz môžeš bez starších ("vstavaných" in-tree) poskytovateľov cloudu (alfa verzia).
  • K obslužnému programu kubeadm dodal experimentálna (alfa verzia) schopnosť aplikovať prispôsobené záplaty počas operácií init, join и upgrade. Prečítajte si viac o tom, ako používať vlajku --experimental-kustomize, vidieť v CAP.
  • Nový koncový bod pre apiserver - readyz, - umožňuje exportovať informácie o jeho pripravenosti. Server API má teraz tiež príznak --maximum-startup-sequence-duration, čo vám umožní regulovať jeho reštarty.
  • dva funkcie pre Azure vyhlásený za stabilný: podpora zóny dostupnosti (zóny dostupnosti) a krížová skupina zdrojov (RG). Okrem toho Azure pridal:
  • AWS teraz má podpora pre EBS v systéme Windows a optimalizované EC2 API volania DescribeInstances.
  • Kubeadm je teraz nezávislý migruje Konfigurácia CoreDNS pri inovácii verzie CoreDNS.
  • Binárne súbory atď v príslušnom obrázku Docker urobili world-executable, ktorý vám umožňuje spustiť tento obrázok bez potreby práv root. Tiež obrázok migrácie etcd prestali podpora verzie etcd2.
  • В Cluster Autoscaler 1.16.0 prešiel na používanie distroless ako základného obrazu, zlepšil sa výkon, pridali sa noví poskytovatelia cloudu (DigitalOcean, Magnum, Packet).
  • Aktualizácie používaného/závislého softvéru: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Prečítajte si aj na našom blogu:

Zdroj: hab.com

Pridať komentár