Kubernetes 1.16: Uuden kohokohdat

Tänään, keskiviikkona, tapahtuu seuraava Kubernetesin julkaisu - 1.16. Blogillemme syntyneen perinteen mukaan tämä on XNUMX-vuotisjuhlapäivä, jolloin puhumme merkittävimmistä muutoksista uudessa versiossa.

Tämän materiaalin valmistuksessa käytetyt tiedot on otettu osoitteesta Kubernetes-parannukset seurantataulukot, MUUTOS-1.16 ja niihin liittyvät ongelmat, vetopyynnöt ja Kubernetes Enhancement Proposals (KEP). Mennään siis!..

Solmut

K8s-klusterisolmujen (Kubelet) puolella on esitetty todella suuri määrä merkittäviä innovaatioita (alfa-version tilassa).

Ensinnäkin ns «lyhytkestoisia säiliöitä» (Efemeraaliset säiliöt), suunniteltu yksinkertaistamaan virheenkorjausprosesseja podissa. Uuden mekanismin avulla voit käynnistää erityisiä säiliöitä, jotka alkavat olemassa olevien podien nimiavaruudesta ja elävät lyhyen aikaa. Niiden tarkoitus on olla vuorovaikutuksessa muiden koteloiden ja säiliöiden kanssa ongelmien ratkaisemiseksi ja virheenkorjauksen tekemiseksi. Tälle ominaisuudelle on otettu käyttöön uusi komento kubectl debug, pohjimmiltaan samanlainen kuin kubectl exec: vain prosessin suorittamisen sijaan säilössä (kuten exec) se laukaisee kontin kotelossa. Tämä komento esimerkiksi yhdistää uuden säilön koteloon:

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

Tietoja lyhytaikaisista säiliöistä (ja esimerkkejä niiden käytöstä) löytyy osoitteesta vastaava KEP. Nykyinen toteutus (K8s 1.16:ssa) on alfa-versio, ja sen beta-versioon siirtämisen kriteerien joukossa on "Ephemeral Containers APIn testaus vähintään kahdelle [Kubernetes]-julkaisulle".

NB: Pohjimmiltaan ja jopa nimensä mukaan ominaisuus muistuttaa jo olemassa olevaa laajennusta kubectl-debugjosta me jo kirjoittanut. On odotettavissa, että lyhytkestoisten säiliöiden myötä erillisen ulkoisen laajennuksen kehitys loppuu.

Toinen innovaatio - PodOverhead - suunniteltu tarjoamaan mekanismi palojen yleiskustannusten laskemiseksi, joka voi vaihdella suuresti käytetyn suoritusajan mukaan. Esimerkkinä kirjoittajat tämä KEP tuloksena on Kata Containers, jotka vaativat vierasytimen, kata-agentin, init-järjestelmän jne. Kun yleiskustannukset kasvavat niin suureksi, sitä ei voida jättää huomiotta, mikä tarkoittaa, että on oltava tapa ottaa ne huomioon lisäkiintiöissä, suunnittelussa jne. Sen toteuttamiseksi PodSpec kenttä lisätty Overhead *ResourceList (vertaa sisäänkirjautuviin tietoihin RuntimeClass, jos sellainen on käytössä).

Toinen merkittävä innovaatio on solmun topologian hallinta (Solmutopologian hallinta), joka on suunniteltu yhdistämään lähestymistapa laitteistoresurssien allokoinnin hienosäätöön Kubernetesin eri komponenteille. Aloitteen taustalla on erilaisten nykyaikaisten järjestelmien (televiestinnän, koneoppimisen, rahoituspalveluiden jne.) kasvava tarve tehokkaaseen rinnakkaislaskentaan ja toimintojen suorittamisen viivästysten minimoimiseen, joihin ne käyttävät kehittynyttä CPU:ta ja laitteistokiihdytysominaisuudet. Tällaisia ​​optimointeja Kubernetesissa on tähän mennessä saavutettu erilaisten komponenttien (CPU-hallinta, laitehallinta, CNI) ansiosta, ja nyt niihin lisätään yksi sisäinen käyttöliittymä, joka yhtenäistää lähestymistavan ja yksinkertaistaa uusien samanlaisten - ns. Aware - komponentit Kubelet-puolella. Tiedot - sisään vastaava KEP.

Topologian hallinnan komponenttikaavio

Seuraava ominaisuus - konttien tarkistaminen niiden ollessa käynnissä (käynnistysanturi). Kuten tiedätte, konteille, joiden laukaisu kestää kauan, on vaikea saada ajan tasalla olevaa tilaa: ne joko "tappataan" ennen kuin ne alkavat varsinaisesti toimia, tai ne päätyvät umpikujaan pitkäksi aikaa. Uusi tarkistus (käytössä ominaisportin kautta StartupProbeEnabled) peruuttaa - tai pikemminkin lykkää - muiden tarkistusten vaikutusta siihen hetkeen asti, kun pod on päättynyt. Tästä syystä ominaisuutta kutsuttiin alun perin pod-startup liveness-probe holdoff. Jos podien käynnistyminen kestää kauan, voit tehdä kyselyn tilan suhteellisen lyhyin aikavälein.

Lisäksi RuntimeClass-parannukset ovat heti saatavilla beta-tilassa, mikä lisää "heterogeenisten klustereiden" tuen. C RuntimeClass-aikataulu Nyt ei ole ollenkaan välttämätöntä, että jokaisella solmulla on tukea jokaiselle RuntimeClassille: podille voit valita RuntimeClassin ajattelematta klusterin topologiaa. Aikaisemmin tämän saavuttamiseksi - jotta podit päätyivät solmuihin, jotka tukevat kaikkea tarvitsemaansa - oli tarpeen määrittää asianmukaiset säännöt NodeSelectorille ja toleraatioille. SISÄÄN KEP Siinä puhutaan käyttöesimerkeistä ja tietysti toteutuksen yksityiskohdista.

Сеть

Kaksi merkittävää verkkoominaisuutta, jotka ilmestyivät ensimmäistä kertaa (alfaversiossa) Kubernetes 1.16:ssa, ovat:

• Tukea kaksoisverkkopino - IPv4/IPv6 - ja sitä vastaava "ymmärrys" koteloiden, solmujen ja palveluiden tasolla. Se sisältää IPv4-IPv4- ja IPv6-IPv6-yhteensopivuuden podien välillä podista ulkoisiin palveluihin, referenssitoteutuksia (Bridge CNI-, PTP CNI- ja Host-Local IPAM-laajennuksissa) sekä käänteisen yhteensopivan käynnissä olevien Kubernetes-klusterien kanssa. Vain IPv4 tai IPv6. Toteutustiedot löytyvät KEP.

  Esimerkki kahden tyyppisten IP-osoitteiden (IPv4 ja IPv6) näyttämisestä pod-luettelossa:

  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#

• Uusi API Endpointille - EndpointSlice API. Se ratkaisee olemassa olevan Endpoint API:n suorituskyky-/skaalautuvuusongelmat, jotka vaikuttavat ohjaustason eri komponentteihin (apiserver, etcd, endpoints-controller, kube-proxy). Uusi API lisätään Discovery API -ryhmään, ja se pystyy palvelemaan kymmeniä tuhansia taustapäätepisteitä kussakin palvelussa tuhansista solmuista koostuvassa klusterissa. Tätä varten jokainen palvelu kartoitetaan N objektiin EndpointSlice, joista kullakin oletuksena on enintään 100 päätepistettä (arvo on määritettävissä). EndpointSlice API tarjoaa myös mahdollisuuksia sen tulevalle kehitykselle: tuki useille IP-osoitteille jokaiselle podille, uusia tiloja päätepisteille (ei vain Ready и NotReady), dynaaminen osajoukko päätepisteille.

Edellisessä julkaisussa esitetty on saavuttanut beta-version viimeistely, nimetty service.kubernetes.io/load-balancer-cleanup ja liitetään jokaiseen palveluun tyypin mukaan LoadBalancer. Kun tällainen palvelu poistetaan, se estää resurssin todellisen poistamisen, kunnes kaikkien asiaankuuluvien tasapainotusresurssien "puhdistus" on valmis.

API-koneet

Todellinen "vakauttamisen virstanpylväs" on Kubernetes API -palvelimen ja vuorovaikutuksen alueella. Tämä tapahtui suurelta osin kiitos siirtämällä vakaaseen asemaan ne, jotka eivät tarvitse erityistä esittelyä CustomResourceDefinitions (CRD), jotka ovat olleet beta-tilassa Kubernetes 1.7:n kaukaisista ajoista lähtien (ja tämä on kesäkuu 2017!). Sama vakaus tuli liittyviin ominaisuuksiin:

• "aliresurssit" kanssa /status и /scale CustomResourcesille;
• muutos CRD:n versiot, jotka perustuvat ulkoiseen webhookiin;
• äskettäin esitelty (K8s 1.15:ssä) oletusarvot (oletus) ja automaattinen kentän poisto (leikkaus) CustomResourcesille;
• tilaisuus käyttämällä OpenAPI v3 -skeemaa OpenAPI-dokumentaation luomiseen ja julkaisemiseen, jota käytetään CRD-resurssien vahvistamiseen palvelinpuolella.

Toinen mekanismi, joka on jo pitkään tullut tutuksi Kubernetes-järjestelmänvalvojille: sisäänpääsy webhook - pysyi myös beta-tilassa pitkään (K8s 1.9:stä lähtien) ja on nyt julistettu vakaaksi.

Kaksi muuta ominaisuutta on saavuttanut betavaiheen: palvelinpuolen käyttöön и katsella kirjanmerkkejä.

Ja ainoa merkittävä innovaatio alfaversiossa oli vika alkaen SelfLink — erityinen URI, joka edustaa määritettyä objektia ja on osa sitä ObjectMeta и ListMeta (eli osa mitä tahansa objektia Kubernetesissa). Miksi he hylkäävät sen? Motivaatio yksinkertaisella tavalla äänet todellisten (ylivoimaisten) syiden puuttumisena tämän alan edelleen olemassaololle. Muodollisempia syitä ovat suorituskyvyn optimointi (poistamalla tarpeeton kenttä) ja geneerisen apiserverin työn yksinkertaistaminen, joka on pakotettu käsittelemään tällaista kenttää erityisellä tavalla (tämä on ainoa kenttä, joka asetetaan juuri ennen objektia on sarjoitettu). Todellinen vanhentuminen (beta-vaiheessa) SelfLink tapahtuu Kubernetes-versiolla 1.20 ja lopullisella - 1.21.

Tietovarasto

Pääasiallinen työ varastointialueella, kuten aikaisemmissakin julkaisuissa, havaitaan alueella CSI-tuki. Tärkeimmät muutokset tässä olivat:

• ensimmäistä kertaa (alfa-versiossa) ilmestyi tuki CSI-laajennuksille työsolmuille, joissa on Windows: nykyinen tapa työskennellä tallennustilan kanssa korvaa myös Kubernetes-ytimen puun sisäiset laajennukset ja Microsoftin Powershelliin perustuvat FlexVolume-laajennukset;

  
  CSI-laajennusten toteutuskaavio Kubernetesissa Windows

• tilaisuus CSI-taltioiden koon muuttaminen, joka esiteltiin K8s 1.12:ssa, on kasvanut beta-versioksi;
• Samanlainen "promootio" (alfasta betaan) saavutettiin kyvyllä käyttää CSI:tä paikallisten lyhytaikaisten volyymien luomiseen (CSI Inline Volume -tuki).

Esitelty Kubernetesin edellisessä versiossa tilavuuden kloonaustoiminto (käyttäen olemassa olevaa PVC:tä esim DataSource uuden PVC:n luomiseksi) on myös nyt saanut beta-statuksen.

Ajastin

Kaksi merkittävää muutosta aikatauluun (molemmat alfassa):

• EvenPodsSpreading - tilaisuus käytä podeja loogisten sovellusyksiköiden sijasta kuormien "oikeudenmukaiseen jakautumiseen". (kuten Deployment ja ReplicaSet) ja tämän jakelun säätäminen (kova vaatimuksena tai pehmeänä ehtona, eli prioriteettina). Ominaisuus laajentaa suunniteltujen podien olemassa olevia jakeluominaisuuksia, joita tällä hetkellä rajoittavat vaihtoehdot PodAffinity и PodAntiAffinity, antaa järjestelmänvalvojille tarkemman hallinnan tässä asiassa, mikä tarkoittaa parempaa korkeaa käytettävyyttä ja optimoitua resurssien kulutusta. Tiedot - sisään KEP.
• Käyttää BestFit-käytäntö в RequestedToCapacityRatio Priority Function pod-suunnittelun aikana, mikä mahdollistaa käyttää roskakoriin pakkaus ("pakkaus säiliöihin") sekä perusresursseille (prosessori, muisti) että laajennetuille (kuten GPU). Katso lisätietoja KEP.

  
  Ajoitustyypit: ennen parhaan istuvuuden käytännön käyttöä (suoraan oletusaikataulun kautta) ja sen käytön yhteydessä (aikataulun laajentimen kautta)

Lisäksi, edustaa mahdollisuus luoda omia ajoituslaajennuksia Kubernetesin pääkehityspuun ulkopuolelle (puun ulkopuolinen).

Muut muutokset

Myös Kubernetes 1.16 -julkaisussa voit huomata aloite tuomalla saatavilla olevat mittarit täydessä järjestyksessätai tarkemmin sanoen mukaisesti virallisia määräyksiä K8s-instrumentointiin. He luottavat suurelta osin vastaavaan Prometheus-dokumentaatio. Epäjohdonmukaisuuksia syntyi useista syistä (esimerkiksi jotkin mittarit luotiin yksinkertaisesti ennen nykyisten ohjeiden ilmestymistä), ja kehittäjät päättivät, että oli aika saattaa kaikki yhteen standardiin, "mukaan muun Prometheus-ekosysteemin kanssa". Tämän aloitteen nykyinen toteutus on alfa-tilassa, ja sitä edistetään asteittain seuraavissa Kubernetesin versioissa beta-versioksi (1.17) ja vakaaksi (1.18).

Lisäksi voidaan huomioida seuraavat muutokset:

• Tuen kehittäminen Windows с ulkomuoto Kubeadm-apuohjelmat tälle käyttöjärjestelmälle (alfa-versio), tilaisuus RunAsUserName varten Windows- säilöt (alfa-versio), parannus Group Managed Service Account (gMSA) -tuki beta-versioon asti, tuki kiinnitä/kiinnitä vSphere-taltioille.
• Kierrätetty tietojen pakkausmekanismi API-vastauksissa. Aikaisemmin näihin tarkoituksiin käytettiin HTTP-suodatinta, joka asetti joukon rajoituksia, jotka estivät sen oletuksena olevan käytössä. "Läpinäkyvä pyyntöpakkaus" toimii nyt: asiakkaat lähettävät Accept-Encoding: gzip otsikossa ne saavat GZIP-pakatun vastauksen, jos sen koko ylittää 128 kt. Go-asiakkaat tukevat automaattisesti pakkausta (lähettää vaaditun otsikon), joten he huomaavat välittömästi liikenteen vähenemisen. (Muut kielet voivat vaatia pieniä muutoksia.)
• Tuli mahdolliseksi HPA:n skaalaus nollasta/nollaan ulkoisten mittareiden perusteella. Jos skaalaat objektien/ulkoisten mittareiden perusteella, voit skaalata resurssien säästämiseksi automaattisesti 0-kopioon, kun työkuormat ovat käyttämättömänä. Tämän ominaisuuden pitäisi olla erityisen hyödyllinen tapauksissa, joissa työntekijät pyytävät GPU-resursseja ja erityyppisten käyttämättömien työntekijöiden määrä ylittää käytettävissä olevien GPU:iden määrän.
• Uusi asiakas - k8s.io/client-go/metadata.Client — "yleistettyyn" pääsyyn esineisiin. Se on suunniteltu helposti hakemaan metatiedot (eli alaosion metadata) klusterin resursseista ja suorittaa niillä roskien keräys- ja kiintiötoimintoja.
• Rakenna Kubernetes nyt voit ilman vanhoja ("sisäänrakennettuja" puun sisäisiä) pilvipalveluntarjoajia (alfaversio).
• Kubeadm-apuohjelmaan lisätty kokeellinen (alfa-versio) kyky käyttää mukautettuja korjaustiedostoja toiminnan aikana init, join и upgrade. Lue lisää lipun käytöstä --experimental-kustomize, katso sisään KEP.
• Uusi päätepiste apiserverille - readyz, - voit viedä tietoja sen valmiudesta. API-palvelimella on nyt myös lippu --maximum-startup-sequence-duration, jolloin voit säädellä sen uudelleenkäynnistystä.
• kaksi ominaisuuksia Azurelle julistettu vakaaksi: tuki saatavuusalueet (Saatavuusalueet) ja resurssien välinen ryhmä (RG). Lisäksi Azure on lisännyt:
  • todennustuki AAD ja ADFS;
  • abstrakti service.beta.kubernetes.io/azure-pip-name määrittää kuormantasaajan julkisen IP-osoitteen;
  • tilaisuus настройки LoadBalancerName и LoadBalancerResourceGroup.
• AWS on nyt tukea EBS:lle Windows и optimoitu EC2 API -kutsut DescribeInstances.
• Kubeadm on nyt itsenäinen siirtyy CoreDNS-kokoonpano päivitettäessä CoreDNS-versiota.
• Binaarit jne vastaavassa Docker-kuvassa ovat tehneet world-executable, jonka avulla voit suorittaa tämän kuvan ilman pääkäyttäjän oikeuksia. Myös etcd-siirtokuva lakkasi etcd2-version tuki.
• В Cluster Autoscaler 1.16.0 siirryttiin käyttämään distrolessia peruskuvana, parantunut suorituskyky, lisätty uusia pilvipalveluntarjoajia (DigitalOcean, Magnum, Packet).
• Päivitykset käytettyihin/riippuvaisiin ohjelmistoihin: Siirry 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS.

Lue myös blogistamme:

• «Kubernetes 1.15: Uuden kohokohdat";
• «Kubernetes 1.14: Uuden kohokohdat";
• «Kubernetes 1.13: Uuden kohokohdat";
• «Kubernetes 1.12: Uuden kohokohdat'.

Lähde: will.com