ProHoster > Blog > uprava > Kubernetes 1.16: Istaknuto što je novo

Kubernetes 1.16: Istaknuto što je novo

Kubernetes 1.16: Istaknuto što je novo

Danas, srijeda, će se održati sljedeće izdanje Kubernetesa - 1.16. Prema tradiciji koja se razvila za naš blog, ovo je deseta obljetnica da govorimo o najznačajnijim promjenama u novoj verziji.

Podaci korišteni za pripremu ovog materijala preuzeti su iz Kubernetes tablice praćenja poboljšanja, DNEVNIK PROMJENA-1.16 i povezani problemi, zahtjevi za povlačenjem i prijedlozi poboljšanja Kubernetesa (KEP). Pa, idemo!..

Čvorovi

Uistinu velik broj značajnih inovacija (u statusu alpha verzije) predstavljen je na strani čvorova klastera K8s (Kubelet).

Kao prvo, tzv «efemerne posude» (Efemerni spremnici), dizajniran za pojednostavljenje procesa otklanjanja pogrešaka u pods. Novi mehanizam omogućuje vam pokretanje posebnih spremnika koji počinju u imenskom prostoru postojećih podova i žive kratko vrijeme. Njihova je svrha interakcija s drugim podovima i spremnicima kako bi se riješili problemi i otklonile pogreške. Za ovu značajku implementirana je nova naredba kubectl debug, sličan u biti kubectl exec: samo umjesto pokretanja procesa u spremniku (kao u exec) pokreće spremnik u kapsuli. Na primjer, ova će naredba povezati novi spremnik s podom:

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

Pojedinosti o efemernim spremnicima (i primjerima njihove upotrebe) mogu se pronaći u odgovarajući KEP. Trenutna implementacija (u K8s 1.16) je alfa verzija, a među kriterijima za njezin prijenos u beta verziju je "testiranje Ephemeral Containers API-ja za najmanje 2 izdanja [Kubernetesa]."

NB: U svojoj biti, pa čak i po imenu, značajka podsjeća na već postojeći dodatak kubectl-debugo kojoj mi već napisao. Očekuje se da će s pojavom efemernih spremnika prestati razvoj zasebnog vanjskog dodatka.

Još jedna inovacija - PodOverhead - dizajniran za pružanje mehanizam za obračun režijskih troškova za pods, što može uvelike varirati ovisno o korištenom vremenu izvođenja. Kao primjer, autori ovaj KEP rezultirati Kata kontejnerima, koji zahtijevaju pokretanje gostujućeg kernela, kata agenta, init sustava itd. Kada opći troškovi postanu tako veliki, ne mogu se zanemariti, što znači da mora postojati način da se to uzme u obzir za daljnje kvote, planiranje itd. Da ga implementirate u PodSpec polje dodano Overhead *ResourceList (uspoređuje se s podacima u RuntimeClass, ako se koristi).

Još jedna značajna inovacija je upravitelj topologije čvora (Upravitelj topologije čvora), dizajniran za objedinjavanje pristupa finom podešavanju dodjele hardverskih resursa za različite komponente u Kubernetesu. Ova inicijativa je potaknuta sve većom potrebom raznih modernih sustava (iz područja telekomunikacija, strojnog učenja, financijskih usluga itd.) za paralelnim računalstvom visokih performansi i minimiziranjem kašnjenja u izvršavanju operacija, za što koriste napredni CPU i mogućnosti hardverskog ubrzanja. Takve optimizacije u Kubernetesu do sada su se postigle zahvaljujući disparatnim komponentama (CPU manager, Device manager, CNI), a sada će im biti dodano jedinstveno interno sučelje koje objedinjuje pristup i pojednostavljuje povezivanje novih sličnih – tzv. aware - komponente na Kubelet strani. Detalji - u odgovarajući KEP.

Kubernetes 1.16: Istaknuto što je novo
Dijagram komponenti upravitelja topologije

Sljedeća značajka - provjeravajući spremnike dok rade (sonda za pokretanje). Kao što znate, za kontejnere čije je pokretanje potrebno dugo vremena, teško je dobiti ažuran status: ili su "ubijeni" prije nego što stvarno počnu funkcionirati, ili završe u mrtvoj točki na duže vrijeme. Nova provjera (omogućena kroz vrata značajke tzv StartupProbeEnabled) poništava - ili bolje rečeno, odgađa - učinak svih drugih provjera do trenutka kada modul završi s radom. Iz tog razloga, značajka je izvorno pozvana pod-startup živahnost-probe holdoff. Za podove kojima treba dugo da se pokrenu, možete ispitati stanje u relativno kratkim vremenskim intervalima.

Osim toga, poboljšanje za RuntimeClass odmah je dostupno u beta statusu, dodajući podršku za "heterogene klastere". C RuntimeClass Scheduling Sada uopće nije potrebno da svaki čvor ima podršku za svaku RuntimeClass: za mahune možete odabrati RuntimeClass bez razmišljanja o topologiji klastera. Prethodno, da bi se to postiglo - tako da podovi završe na čvorovima s podrškom za sve što im je potrebno - bilo je potrebno dodijeliti odgovarajuća pravila NodeSelectoru i tolerancijama. U KEP Govori o primjerima korištenja i, naravno, detaljima implementacije.

Mreža

Dvije značajne značajke umrežavanja koje su se prvi put pojavile (u alfa verziji) u Kubernetesu 1.16 su:

  • podrška dvostruki mrežni stog - IPv4/IPv6 - i odgovarajuće "razumijevanje" na razini podova, čvorova, usluga. Uključuje interoperabilnost IPv4-na-IPv4 i IPv6-na-IPv6 između podova, od podova do vanjskih usluga, referentne implementacije (unutar Bridge CNI, PTP CNI i Host-Local IPAM dodataka), kao i obrnutu kompatibilnost s pokrenutim Kubernetes klasterima Samo IPv4 ili IPv6. Detalji implementacije su navedeni KEP.

    Primjer prikaza dviju vrsta IP adresa (IPv4 i IPv6) na popisu 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 točku - EndpointSlice API. Rješava probleme s performansama/skalabilnošću postojećeg Endpoint API-ja koji utječu na različite komponente u kontrolnoj ravnini (apiserver, etcd, endpoints-controller, kube-proxy). Novi API bit će dodan grupi Discovery API i moći će opsluživati ​​desetke tisuća pozadinskih krajnjih točaka na svakoj usluzi u klasteru koji se sastoji od tisuća čvorova. Da bi se to postiglo, svaka se usluga preslikava na N objekata EndpointSlice, od kojih svaka prema zadanim postavkama nema više od 100 krajnjih točaka (vrijednost se može konfigurirati). EndpointSlice API također će pružiti mogućnosti za svoj budući razvoj: podrška za više IP adresa za svaki pod, nova stanja za krajnje točke (ne samo Ready и NotReady), dinamički podskup za krajnje točke.

Onaj predstavljen u prošlom izdanju stigao je do beta verzije finalizator, imenovan service.kubernetes.io/load-balancer-cleanup i priložen svakoj usluzi s vrstom LoadBalancer. U trenutku brisanja takve usluge, onemogućuje stvarno brisanje resursa dok se ne dovrši "čišćenje" svih relevantnih resursa balansera.

API strojevi

Prava "prekretnica stabilizacije" je u području Kubernetes API poslužitelja i interakcije s njim. To se dogodilo velikim dijelom zahvaljujući prevođenje u stabilan status onih koje ne treba posebno predstavljati CustomResourceDefinitions (CRD), koji imaju beta status još od dalekih dana Kubernetesa 1.7 (a ovo je lipanj 2017.!). Ista stabilizacija došla je do povezanih značajki:

  • "podizvori" s /status и /scale za CustomResources;
  • transformacija verzije za CRD, temeljene na vanjskom webhooku;
  • nedavno predstavljen (u K8s 1.15) zadane vrijednosti (zadano) i automatsko uklanjanje polja (obrezivanje) za CustomResources;
  • prilika korištenje OpenAPI v3 sheme za stvaranje i objavljivanje OpenAPI dokumentacije koja se koristi za provjeru valjanosti CRD resursa na strani poslužitelja.

Još jedan mehanizam koji je odavno poznat administratorima Kubernetesa: pristup webhook - također je ostao u beta statusu dugo vremena (od K8s 1.9) i sada je proglašen stabilnim.

Još dvije značajke dosegle su beta verziju: primijeniti na strani poslužitelja и oznake gledati.

A jedina značajna novost u alfa verziji bila je neuspjeh iz SelfLink — poseban URI koji predstavlja navedeni objekt i dio je ObjectMeta и ListMeta (tj. dio bilo kojeg objekta u Kubernetesu). Zašto ga napuštaju? Motivacija na jednostavan način zvukovi kao nepostojanje stvarnih (prekomjernih) razloga da ovo polje još postoji. Formalniji razlozi su optimizacija performansi (uklanjanjem nepotrebnog polja) i pojednostavljenje rada generic-apiservera, koji je prisiljen rukovati takvim poljem na poseban način (ovo je jedino polje koje je postavljeno neposredno prije objekta je serijaliziran). Prava zastarjelost (unutar beta verzije) SelfLink dogodit će se do Kubernetes verzije 1.20, a konačna - 1.21.

Pohrana podataka

Glavni rad u području skladištenja, kao iu prethodnim izdanjima, promatra se u području CSI podrška. Glavne promjene ovdje bile su:

  • prvi put (u alfa verziji) pojavio Podrška za CSI dodatak za Windows radne čvorove: trenutni način rada s pohranom također će zamijeniti in-tree dodatke u Kubernetes jezgri i FlexVolume dodatke iz Microsofta temeljene na Powershell-u;

    Kubernetes 1.16: Istaknuto što je novo
    Shema za implementaciju CSI dodataka u Kubernetes za Windows

  • prilika promjena veličine CSI volumena, predstavljen još u K8s 1.12, narastao je do beta verzije;
  • Slično "promaknuće" (iz alfe u beta) postignuto je mogućnošću korištenja CSI-ja za stvaranje lokalnih efemernih svezaka (CSI Inline Volume podrška).

Predstavljeno u prethodnoj verziji Kubernetesa funkcija kloniranja volumena (koristeći postojeći PVC kao DataSource za stvaranje novog PVC-a) sada je također dobio beta status.

Planer

Dvije značajne promjene u rasporedu (obje u alfa):

  • EvenPodsSpreading - prilika koristiti mahune umjesto logičnih aplikacijskih jedinica za “pravednu raspodjelu” opterećenja (kao što su Deployment i ReplicaSet) i prilagođavanje ove distribucije (kao čvrsti zahtjev ili kao meki uvjet, tj. prioritet). Značajka će proširiti postojeće mogućnosti distribucije planiranih podova, trenutno ograničene opcijama PodAffinity и PodAntiAffinity, dajući administratorima finiju kontrolu u ovom pitanju, što znači bolju visoku dostupnost i optimiziranu potrošnju resursa. Detalji - u KEP.
  • Koristiti Politika BestFit в Funkcija prioriteta RequestedToCapacityRatio tijekom planiranja mahuna, što će omogućiti primijeniti pakiranje u kantu ("pakiranje u kontejnere") za osnovne resurse (procesor, memorija) i one proširene (poput GPU-a). Za više detalja pogledajte KEP.

    Kubernetes 1.16: Istaknuto što je novo
    Podovi za zakazivanje: prije korištenja pravila najboljeg pristajanja (izravno putem zadanog planera) i s njegovom upotrebom (putem proširenja planera)

Osim toga, predstavljeni mogućnost stvaranja vlastitih dodataka planera izvan glavnog Kubernetes razvojnog stabla (izvan stabla).

Ostale promjene

Može se primijetiti i u izdanju Kubernetesa 1.16 inicijativa za dovodeći dostupne metrike u punom redu, točnije, u skladu sa službeni propisi na instrumentaciju K8s. Oni se velikim dijelom oslanjaju na odgovarajuće Prometejeva dokumentacija. Nedosljednosti su se pojavile iz različitih razloga (na primjer, neke su metrike jednostavno stvorene prije nego što su se pojavile trenutne upute), a programeri su odlučili da je vrijeme da sve dovedu na jedinstveni standard, "u skladu s ostatkom Prometheus ekosustava". Trenutna implementacija ove inicijative je u alfa statusu, koji će se postupno promovirati u sljedećim verzijama Kubernetesa u beta (1.17) i stabilnu (1.18).

Osim toga, mogu se primijetiti sljedeće promjene:

  • Razvoj podrške za Windows с izgled Kubeadm pomoćni programi za ovaj OS (alfa verzija), prilika RunAsUserName za Windows kontejnere (alfa verzija), poboljšanje Podrška za grupni upravljani račun usluge (gMSA) do beta verzije, podrška montiranje/pripajanje za vSphere volumene.
  • Reciklirano mehanizam kompresije podataka u API odgovorima. Prethodno se u te svrhe koristio HTTP filtar, što je nametalo brojna ograničenja koja su sprječavala njegovo uključivanje prema zadanim postavkama. "Transparentna kompresija zahtjeva" sada radi: klijenti šalju Accept-Encoding: gzip u zaglavlju, primaju GZIP-komprimirani odgovor ako njegova veličina premašuje 128 KB. Go klijenti automatski podržavaju kompresiju (slanje potrebnog zaglavlja), tako da će odmah primijetiti smanjenje prometa. (Možda će biti potrebne male izmjene za druge jezike.)
  • Postalo moguće skaliranje HPA od/na nulte mahune na temelju vanjske metrike. Ako skalirate na temelju objekata/vanjske metrike, tada kada su radna opterećenja u stanju mirovanja, možete automatski skalirati na 0 replika radi uštede resursa. Ova bi značajka trebala biti posebno korisna u slučajevima kada radnici traže GPU resurse, a broj različitih tipova neaktivnih radnika premašuje broj dostupnih GPU-ova.
  • Novi klijent - k8s.io/client-go/metadata.Client — za “generalizirani” pristup objektima. Dizajniran je za jednostavno dohvaćanje metapodataka (tj. pododjeljka metadata) iz resursa klastera i s njima izvodi operacije skupljanja smeća i kvote.
  • Izgradite Kubernetes sada možeš bez naslijeđenih (“ugrađenih” in-tree) cloud providera (alpha verzija).
  • Uslužni program kubeadm dodano eksperimentalna (alfa verzija) mogućnost primjene prilagođenih zakrpa tijekom operacija init, join и upgrade. Saznajte više o tome kako koristiti zastavu --experimental-kustomize, vidi u KEP.
  • Nova krajnja točka za apiserver - readyz, - omogućuje vam izvoz informacija o njegovoj spremnosti. API poslužitelj također sada ima oznaku --maximum-startup-sequence-duration, što vam omogućuje reguliranje njegovih ponovnih pokretanja.
  • Dva značajke za Azure proglašen stabilnim: podrška zone dostupnosti (Zone dostupnosti) i cross resource group (RG). Osim toga, Azure je dodao:
  • AWS sada ima podržati za EBS na Windowsima i optimizirano EC2 API pozivi DescribeInstances.
  • Kubeadm je sada neovisan migrira Konfiguracija CoreDNS-a prilikom nadogradnje verzije CoreDNS-a.
  • Binarne datoteke itd na odgovarajućoj Docker slici gotovo world-executable, koji vam omogućuje pokretanje ove slike bez potrebe za root pravima. Također, etcd migracijska slika prestao podrška za etcd2 verziju.
  • В Cluster Autoscaler 1.16.0 prešli na korištenje distrolessa kao osnovne slike, poboljšane performanse, dodani novi pružatelji usluga oblaka (DigitalOcean, Magnum, Packet).
  • Ažuriranja korištenog/ovisnog softvera: 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