Kubernetes izstrādes komanda nesen izlaidusi ar paziņojumu par jaunā versija "Kubernetes 1.18" kurā izstrādes komanda min, ka tā ir versija “der un pabeigta”.
Šajā jaunajā versijā ir paveikts ievērojams darbs, lai uzlabotu beta versiju un stabilu funkcionalitāti garantēt a labāka lietotāja pieredze. Tikpat lielas pūles ir pieliktas, lai pievienotu jaunus uzlabojumus un aizraujošas jaunas funkcijas, kas sola vēl vairāk uzlabot lietotāju pieredzi.
Tiem, kas nezina Kubernetes, viņiem tas jāzina ir atvērta pirmkoda sistēma automatizēšanai - ieviešana, mērogošana un pārvaldība konteinerizētas lietojumprogrammas.
Fue sākotnēji izstrādājis Google, lai gan tā izstrāde vēlāk uzticēta Atvērtā koda mākoņdatošanas fondam (CNCF), kas šodien, pateicoties tehnoloģiju gigantu ieguldījumam, ļāva konteineru orķestrēšanas tehnoloģijai ātri nobriest.
Kas jauns Kubernetes 1.18 versijā?
Šī jaunā versija izceļas ar to, ka tai ir spēja izmantot pakalpojumu konta žetonus kā vispārēju autentifikācijas metodi. Piemēram, ja vēlaties, lai pāksts pārvaldītu citus Kubernetes resursus, piemēram, izvietošanu vai pakalpojumu, to var saistīt ar pakalpojuma kontu un izveidot nepieciešamās lomas un lomu piesaistes.
Kubernetes pakalpojumu konti (KSA) nosūta JSON tīmekļa marķierus (JWT) uz API serveri, lai tos autentificētu. Tas padara API serveri par vienīgo autentifikācijas avotu pakalpojumu kontiem.
Kubernetes 1.18 lppnodrošina funkcionalitāti ka ļauj API serverim nodrošināt OpenID Connect atklāšanas dokumentu A, kurā papildus citiem metadatiem ir marķiera publiskās atslēgas.
Vēl viena izmaiņa, kas izceļas no Kubernetes 1.81, ir spēja konfigurēt HPA ātrumu konkrētām pākstīm. Tika izmantots Horizontal Pod Autoscaler (HPA)a, lai ļautu Kubernetes kopai automātiski reaģēt uz lielu / zemu trafiku. Izmantojot HPA, lietotājs var lūgt kontrolieri izveidot vairāk moduļu, reaģējot uz procesora kāpumiem, citiem mērījumiem vai mērījumiem, ko nodrošina lietojumprogramma.
Kubernetes 1.18 ir profilu pārskats, lai palaistu vairākas konfigurācijas plānotāja. Parasti Kubernetes ir divu veidu darba slodzes: ilgtermiņa pakalpojumi (piemēram, tīmekļa serveri, API utt.) Un uzdevumi, kas darbojas līdz pabeigšanai (labāk pazīstams kā nosaukums Darbs).
Sakarā ar acīmredzamajām atšķirībām starp slodzes veidiem, daži lietotāji izmanto pilnu kopu izveidi dažādām vajadzībām. Piemēram, viena kopa datu ieguves pārvaldībai un otra lietojumprogrammu API apkalpošanai.
Iemesls ir tāds, ka viņiem ir nepieciešams atšķirīgs lēmumu pieņemšanas process. Piemēram, plānotāja noklusējuma iestatījumi veicina augstu pieejamību.
No otras puses, mēs varam arī atrast spēja definēt apraides kārtulas kopas līmenī, ko ir ļāvis nodrošināt pākšu plānošanu pieejamības zonās (ja vien izmantojat vairāku zonu kopu), lai nodrošinātu maksimālu pieejamību un resursu izmantošanu.
Funkcionalitāte ļauj topologySpreadConstraints specifikāciju, kas identificē apgabalus, meklējot mezglus ar to pašu topologyKey tagu. Mezgli ar vienu un to pašu TopologyKey tagu pieder vienai un tai pašai teritorijai. Konfigurācija bija vienmērīgi sadalīt pākstis dažādās vietās. Tomēr negatīvais ir tas, ka šis iestatījums jāpiemēro pod līmeņa līmenī. Pākstis, kurām nav konfigurācijas, netiks vienmērīgi sadalītas pa kļūdu domēniem.
Pēdējais bet ne sliktākais, mēs varam arī atrast iespēju ignorēt skaļuma rekvizīta izmaiņas. Pēc noklusējuma, kad sējums ir uzstādīts Kubernetes kopas konteinerā, visiem šī sējuma failiem un direktorijiem ir mainīts rekvizīts uz vērtību, ko nodrošina fsGroup.
Tas viss ļauj fsGroup lasīt un rakstīt sējumu. Tomēr dažos gadījumos šāda rīcība ir izrādījusies nevēlama.
Šī jaunā versija Kubernetes nāk ar vairākām izmaiņām, un mēs esam minējuši tikai dažas no vissvarīgākajām. Ja vēlaties uzzināt pilnu sarakstu, to varat izdarīt, apmeklējot vietni šī saite.