ProHoster > Блог > Administracija > Kubernetes 1.16: Najvažnije o tome šta je novo

Kubernetes 1.16: Najvažnije o tome šta je novo

Kubernetes 1.16: Najvažnije o tome šta je novo

Danas srijeda održat će se sljedeće izdanje Kubernetesa je 1.16. Prema tradiciji koja se razvila za naš blog, već desetu godišnjicu govorimo o najznačajnijim promjenama u novoj verziji.

Informacije korištene za pripremu ovog materijala su preuzete iz Tabele praćenja poboljšanja Kubernetesa, PROMJENA-1.16 i povezana pitanja, zahtjevi za povlačenje i predlozi za poboljšanje Kubernetesa (KEP). Dakle, idemo!..

Čvorovi

Zaista veliki broj zapaženih inovacija (u statusu alfa verzije) predstavljen je na strani čvorova K8s klastera (Kubelet).

Prvo, tu su tzv «efemerni kontejneri» (Efemerni kontejneri), dizajniran da pojednostavi procese otklanjanja grešaka u podovima. Novi mehanizam vam omogućava da pokrenete posebne kontejnere koji počinju u imenskom prostoru postojećih podova i žive kratko vrijeme. Njihova svrha je interakcija s drugim podovima i kontejnerima kako bi riješili sve probleme i otklonili greške. Nova komanda je implementirana za ovu funkciju kubectl debug, slično u suštini kubectl exec: samo umjesto pokretanja procesa u kontejneru (kao u slučaju exec) pokreće kontejner u pod. Na primjer, ova naredba će priložiti novi kontejner na pod:

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

Detalji o efemernim kontejnerima (i primjeri njihove upotrebe) mogu se pronaći u odgovarajući KEP. Trenutna implementacija (u K8s 1.16) je alfa verzija, a među kriterijumima za njen prelazak na beta verziju je "testiranje Ephemeral Containers API-ja za najmanje 2 izdanja [Kubernetes]".

NB: U svojoj suštini, pa čak i po imenu funkcije, podsjećaju na postojeći dodatak kubectl-debugo čemu mi već napisao. Pretpostavlja se da će s pojavom efemernih kontejnera prestati razvoj zasebnog vanjskog dodatka.

Još jedna inovacija - PodOverhead - namijenjeno pružanju Mehanizam proračuna nadzemnih jedinica, koji može biti veoma različit u zavisnosti od izvršnog okruženja (runtime) koji se koristi. Kao primjer, autori ovaj kep citirajte Kata kontejnere, koji zahtijevaju pokretanje gostujućeg kernela, kata agenta, init sistema, itd. Kada režijski troškovi postanu ovoliki, ne mogu se zanemariti, što znači da mora postojati način da se oni uzmu u obzir za dalje citiranje, zakazivanje itd. Za njegovu implementaciju u PodSpec polje dodano Overhead *ResourceList (uporedi sa podacima u RuntimeClass, ako se koristi).

Još jedna značajna inovacija je menadžer topologije čvora (Upravitelj topologije čvorova), dizajniran da objedini pristup finom podešavanju distribucije hardverskih resursa za različite komponente u Kubernetesu. Ova inicijativa je uzrokovana rastućom potrebom različitih savremenih sistema (iz oblasti telekomunikacija, mašinskog učenja, finansijskih usluga itd.) za paralelno računarstvo visokih performansi i minimiziranje kašnjenja u izvršavanju operacija, za šta koriste napredni CPU. i mogućnosti hardverskog ubrzanja. Takve optimizacije u Kubernetesu do sada su postignute zahvaljujući različitim komponentama (CPU manager, Device manager, CNI), a sada će dodati jedno interno sučelje koje objedinjuje pristup i pojednostavljuje povezivanje novih sličnih - tzv. topology-aware - komponente na strani Kubeleta. Detalji - in odgovarajući KEP.

Kubernetes 1.16: Najvažnije o tome šta je novo
Dijagram komponenti upravitelja topologije

Sljedeća karakteristika je provjeravanje kontejnera dok rade (startup sonda). Kao što znate, za kontejnere kojima je potrebno dugo da se lansiraju, teško je dobiti ažuran status: ili su "ubijeni" čak i prije nego što stvarno počnu funkcionirati, ili padaju u ćorsokak na duže vrijeme . Nova provjera (omogućena preko funkcije kapije tzv StartupProbeEnabled) poništava—ili bolje rečeno, odlaže—sve druge provjere dok pod ne završi s radom. Iz tog razloga, ova karakteristika je prvobitno nazvana pod-startup zaustavljanje liveness-probe. Za podove kojima je potrebno mnogo vremena da se pokrenu, možete ispitati status u relativno kratkim vremenskim intervalima.

Pored toga, poboljšanje za RuntimeClass je uvedeno odmah u beta statusu, dodajući podršku za "heterogene klastere". C RuntimeClass Scheduling sada uopšte nije neophodno da svaki čvor ima podršku za svaku RuntimeClass: za podove, možete izabrati RuntimeClass bez razmišljanja o topologiji klastera. Ranije, da biste to postigli - tako da su podovi završili na čvorovima s podrškom za sve što im je potrebno - morali ste dodijeliti odgovarajuća pravila za NodeSelector i tolerancije. IN KEP govori o primjerima upotrebe i, naravno, detaljima implementacije.

Mreža

Dvije značajne mrežne karakteristike koje su se pojavile po prvi put (u alfa verziji) u Kubernetesu 1.16 su:

  • podrška dvostruki mrežni stog - IPv4/IPv6 - i njegovo odgovarajuće "razumijevanje" na nivou podova, čvorova, usluga. Uključuje IPv4-to-IPv4 i IPv6-to-IPv6 interakciju između podova, od podova do eksternih usluga, referentne implementacije (unutar Bridge CNI, PTP CNI i Host-Local IPAM dodataka), kao i obrnutu kompatibilnost s Kubernetes klasterima koji rade samo preko IPv4 ili IPv6. Detalji implementacije su u KEP.

    Primjer prikaza dvije vrste IP adresa (IPv4 i IPv6) na listi podova:

    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#

  • Novi API za krajnju tačku - EndpointSlice API. On rješava probleme performansi/skalabilnosti postojećeg Endpoint API-ja koji utiču na različite komponente u kontrolnoj ravni (apiserver, etcd, endpoints-controller, kube-proxy). Novi API će biti dodat Discovery API grupi i moći će opsluživati ​​desetine hiljada pozadinskih krajnjih tačaka na svakoj usluzi u klasteru koji se sastoji od hiljadu čvorova. Da biste to učinili, svaka usluga je mapirana na N objekata EndpointSlice, od kojih svaka nema više od 100 krajnjih tačaka prema zadanim postavkama (vrijednost se može konfigurirati). EndpointSlice API će također pružiti mogućnosti za njegov budući razvoj: podršku za više IP adresa za svaki pod, nova stanja za krajnje tačke (ne samo Ready и NotReady), dinamička podskupina za krajnje tačke.

Onaj predstavljen u posljednjem izdanju napredovao je u beta verziju finalizatorimenovan service.kubernetes.io/load-balancer-cleanup i priložen uz svaku uslugu sa tipom LoadBalancer. U trenutku uklanjanja takve usluge, ona sprečava stvarno uklanjanje resursa sve dok se ne završi "čišćenje" svih relevantnih resursa balansera.

API mašinerije

Prava "prekretnica stabilizacije" je u oblasti Kubernetes API servera i interakcije sa njim. To je uglavnom bilo zbog prelazak u status stabilnih kojima nije potrebno posebno predstavljanje CustomResourceDefinitions (CRD), koji imaju beta status od dalekog Kubernetesa 1.7 (a ovo je jun 2017!). Ista stabilizacija došla je i do povezanih karakteristika:

  • "podizvori" (podizvori) sa /status и /scale za CustomResources;
  • konverzija verzije za CRD zasnovane na eksternom webhooku;
  • nedavno uveden (u K8s 1.15) podrazumevano (zadano) i automatsko brisanje polja (orezivanje) za CustomResources;
  • prilika koristeći OpenAPI v3 shemu za kreiranje i objavljivanje OpenAPI dokumentacije koja se koristi za validaciju CRD resursa na strani servera.

Još jedan mehanizam koji je odavno poznat Kubernetes administratorima: admission webhook - takođe je dugo bio u beta statusu (od K8s 1.9) i sada je proglašen stabilnim.

Druge dvije funkcije su dostigle beta verziju: primjenjuju se na strani servera и watch bookmarks.

A jedina značajna inovacija u alfa verziji bila je neuspeh iz SelfLink — poseban URI koji predstavlja navedeni objekt i dio je ObjectMeta и ListMeta (tj. dio bilo kojeg objekta u Kubernetesu). Zašto ga odbijaju? Motivacija "na jednostavan način" zvucima kao odsustvo stvarnih (neodoljivih) razloga da ovo polje i dalje postoji. Formalniji razlozi su optimizacija performansi (uklanjanje nepotrebnog polja) i pojednostavljenje rada generičkog-apiservera, koji je primoran da obrađuje takvo polje na poseban način (ovo je jedino polje koje se postavlja neposredno prije objekta). serijalizovan). Prava "zastarelost" (u beta verziji) SelfLink desiće se Kubernetes 1.20, a konačni će biti 1.21.

Pohrana podataka

Glavni posao u oblasti skladištenja, kao iu prethodnim izdanjima, uočen je u tom području CSI podrška. Glavne promjene ovdje su:

  • po prvi put (u alfa verziji) pojavila podrška za CSI dodatke za Windows radne čvorove: trenutni način rada sa skladištima će također zamijeniti dodatke u stablu u Kubernetes jezgru i FlexVolume dodatke iz Microsofta zasnovane na Powershell-u;

    Kubernetes 1.16: Najvažnije o tome šta je novo
    Kubernetes za Windows implementacija CSI dodataka

  • prilika promjena veličine CSI volumena, uveden još u K8s 1.12, narastao je u beta;
  • slična "elevacija" (od alfa do beta) postignuta je mogućnošću korištenja CSI za stvaranje lokalnih prolaznih volumena (CSI Inline Volume Support).

Uvedeno u prethodnoj verziji Kubernetesa funkcija kloniranja volumena (koristeći postojeće PVC-e kao DataSource za kreiranje novih PVC-ova) je takođe sada u beta statusu.

Planer

Dvije značajne promjene planiranja (obje u alfa verziji):

  • EvenPodsSpreading - prilika koristite podove umjesto logičkih jedinica aplikacije za "pravednu raspodjelu" opterećenja (kao Deployment i ReplicaSet) i prilagođavanje ove distribucije (kao čvrsti zahtjev ili kao meki uvjet, tj. prioritet). Ova funkcija će proširiti postojeće opcije distribucije za planirane podove, trenutno ograničene na opcije PodAffinity и PodAntiAffinity, dajući administratorima detaljniju kontrolu po ovom pitanju, što znači bolju visoku dostupnost i optimizovanu potrošnju resursa. Detalji - in KEP.
  • Koristite BestFit politika в Funkcija prioriteta RequestedToCapacityRatio tokom zakazivanja pod, što će omogućiti da se prijave bin pakovanje (“pakiranje u kontejnere”) i za osnovne resurse (procesor, memorija) i za proširene (kao što je GPU). Za detalje pogledajte KEP.

    Kubernetes 1.16: Najvažnije o tome šta je novo
    Pod zakazivanje: prije korištenja pravila najboljeg uklapanja (direktno preko zadanog planera) i korištenja (preko proširivača rasporeda)

Osim toga, predstavljen mogućnost kreiranja vlastitih dodataka za planer izvan glavnog stabla Kubernetes razvoja (van stabla).

Ostale promjene

Također u izdanju Kubernetes 1.16, možete primijetiti inicijativa na dovođenje dostupne metrike u punom redu, tačnije u skladu sa zvaničnim propisima na K8s instrumentaciju. Oni se u velikoj mjeri oslanjaju na odgovarajuće Prometejeva dokumentacija. Nedosljednosti su nastale iz raznih razloga (na primjer, neke metrike su jednostavno kreirane i prije nego što su se pojavile trenutne upute), a programeri su odlučili da je vrijeme da sve dovedu na jedinstveni standard, "u skladu sa ostatkom Prometheus ekosistema". Trenutna implementacija ove inicijative je alfa i progresivno će biti nadograđena na beta (1.17) i stabilnu (1.18) u budućim Kubernetes izdanjima.

Osim toga, mogu se primijetiti sljedeće promjene:

  • Razvoj podrške za Windows с pojava Kubeadm uslužni programi za ovaj OS (alfa verzija), priliku RunAsUserName za Windows kontejnere (alfa verzija), poboljšanje Podrška za grupno upravljani uslužni račun (gMSA) do beta, podrška montirati/priključiti za vSphere volumene.
  • reciklirano mehanizam kompresije podataka u API odgovorima. Ranije je u ove svrhe korišten HTTP filter, koji je nametnuo niz ograničenja koja su spriječila njegovo uključivanje prema zadanim postavkama. Sada radi "transparentna kompresija zahtjeva": slanje klijenata Accept-Encoding: gzip u zaglavlju primi GZIP komprimiran odgovor ako njegova veličina prelazi 128 KB. Go klijenti automatski podržavaju kompresiju (pošaljite desno zaglavlje), tako da će odmah primijetiti smanjenje prometa. (Male modifikacije mogu biti potrebne za druge jezike.)
  • Postalo je moguće skaliranje HPA od/na nula podova na osnovu eksternih metrika. Ako je skaliranje zasnovano na objektima/eksternim metrikama, onda kada su radna opterećenja u mirovanju, možete automatski skalirati na 0 replika da biste uštedjeli resurse. Ova funkcija bi trebala biti posebno korisna u slučajevima kada radnici zahtijevaju GPU resurse, a broj različitih tipova neaktivnih radnika premašuje broj dostupnih GPU-ova.
  • Novi klijent - k8s.io/client-go/metadata.Client - za "generalizovani" pristup objektima. Dizajniran je da lako dohvati metapodatke (tj. pododjeljak metadata) iz resursa klastera i obavljaju operacije sa njima iz kategorije odvoza smeća i kvote.
  • Napravi Kubernetes sada možeš bez zastarjelih („ugrađenih“ u stablu) dobavljača oblaka (alfa verzija).
  • U pomoćni program kubeadm dodano eksperimentalna (alfa) sposobnost primjene prilagođenih zakrpa tokom operacija init, join и upgrade. Saznajte više o tome kako koristiti zastavu --experimental-kustomize, vidi u KEP.
  • Nova krajnja tačka za apiserver - readyz, - omogućava vam da izvezete informacije o njegovoj spremnosti (spremnosti). Takođe, API server ima zastavicu --maximum-startup-sequence-duration, što vam omogućava da kontrolišete njegovo ponovno pokretanje.
  • Dva funkcije za Azure proglašen stabilnim: podrška zone dostupnosti (Zone dostupnosti) i unakrsna grupa resursa (RG). Osim toga, Azure je dodao:
  • AWS ima podrška za EBS na Windows i optimizirano EC2 API pozivi DescribeInstances.
  • Kubeadm je sada sam migrira CoreDNS konfiguracija prilikom ažuriranja CoreDNS verzije.
  • Binarnosti itdd u odgovarajućoj Docker slici uradio world-executable, što vam omogućava da pokrenete ovu sliku bez potrebe za root privilegijama. Također, etcd slika migracije prestao podrška za etcd2 verziju.
  • В Cluster Autoscaler 1.16.0 prešao na korištenje distroless-a kao osnovne slike, poboljšane performanse, dodani novi provajderi oblaka (DigitalOcean, Magnum, Packet).
  • Ažuriranja u korištenom/zavisnom softveru: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Pročitajte i na našem blogu:

izvor: www.habr.com

Dodajte komentar