„Kubernetes“ kūrėjų komanda neseniai išleido paskelbdamas apie išleidimą nauja versija „Kubernetes 1.18“ kuriame kūrėjų komanda mini, kad tai „tinkama ir baigta“ versija.
Šioje naujoje versijoje buvo atliktas didelis darbas tobulinant beta versiją ir stabilų funkcionalumą garantuoti a geresnė vartotojo patirtis. Lygiai taip pat buvo stengiamasi pridėti naujų pokyčių ir įdomių naujų funkcijų, kurios žada dar labiau pagerinti vartotojo patirtį.
Tiems, kurie nežino Kubernetas, jie turėtų tai žinoti yra atviro kodo sistema, skirta automatizuoti - diegimas, mastelio keitimas ir valdymas konteinerių programos.
Buvo iš pradžių sukūrė „Google“, nors vėliau jos plėtra patikėta Atvirojo kodo debesų kompiuterijos fondui (CNCF), kuris šiandien leido konteinerių orkestravimo technologijai greitai subręsti dėka technologijų gigantų.
Kas naujo „Kubernetes 1.18“?
Ši nauja versija išsiskiria tuo, kad turi galimybė naudoti paslaugų sąskaitos žetonus kaip bendras autentifikavimo metodas. Pvz., Jei norite, kad „pod“ tvarkytų kitus „Kubernetes“ išteklius, pvz., Diegimą ar paslaugą, jis gali būti susietas su tarnybos paskyra ir sukurti reikalingus vaidmenis bei vaidmenų susiejimus.
„Kubernetes“ paslaugų abonementai (KSA) siunčia JSON žiniatinklio prieigos raktus (JWT) į API serverį, kad galėtų autentifikuoti. Tai daro API serverį vieninteliu autentifikavimo šaltiniu paslaugų sąskaitoms.
Kubernetes 1.18psuteikia funkcionalumą kad leidžia API serveriui pateikti „OpenID Connect“ atradimo dokumentą A, kuriame be kitų metaduomenų yra viešieji žetono raktai.
Kitas pokytis, išsiskiriantis iš „Kubernetes 1.81“, yra galimybė konfigūruoti HPA greitį konkrečioms ankštims. Buvo naudojamas horizontalusis „Pod Autoscaler“ (HPA)a, kad „Kubernetes“ klasteris galėtų automatiškai reaguoti į didelį / mažą srautą. Naudodamas HPA, vartotojas gali paprašyti valdiklio sukurti daugiau modulių, reaguodamas į procesoriaus šuolius, kitus matavimus ar programos pateiktus matavimus.
„Kubernetes 1.18“ turi profilių apžvalgą, kad būtų galima paleisti kelias konfigūracijas planuotojo. Paprastai „Kubernetes“ yra dviejų tipų darbo krūviai: ilgalaikės paslaugos (pvz., Žiniatinklio serveriai, API ir kt.) Ir iki galo vykdomos užduotys (geriau žinomos kaip pavadinimas Darbai).
Dėl akivaizdžių darbo krūvio tipų skirtumų kai kurie vartotojai kuria visas grupes skirtingiems poreikiams. Pavyzdžiui, vienas klasteris valdo duomenų gavybą, o kitas - programos API.
Priežastis ta, kad jiems reikia skirtingo sprendimo proceso. Pavyzdžiui, numatytieji tvarkaraščio nustatymai skatina aukštą prieinamumą.
Kita vertus, galime rasti ir gebėjimas apibrėžti „podcast“ taisyklę klasterio lygiu, kas leido užtikrinti, kad ankštys bus suplanuotos prieinamumo zonose (su sąlyga, kad naudojate kelių zonų klasterį), kad būtų užtikrintas maksimalus prieinamumas ir išteklių naudojimas.
Funkcionalumas įgalina topologySpreadConstraints specifikaciją, kuri identifikuoja sritis ieškodama mazgų su ta pačia topologyKey žyma. Mazgai su ta pačia „TopologyKey“ žyma priklauso tai pačiai sričiai. Konfigūracija buvo tolygiai paskirstyti ankštis skirtingose vietose. Tačiau minusas yra tas, kad šis nustatymas turi būti taikomas pod lygio. Podai, neturintys konfigūracijos, nebus tolygiai paskirstyti gedimų domenuose.
Paskutinis, bet ne prasčiausias, taip pat galime rasti galimybę nepaisyti tūrio savybės pokyčio. Pagal numatytuosius nustatymus, kai tūris yra sumontuotas į „Kubernetes“ sankaupos talpyklą, visų šio tomo failų ir katalogų ypatybės pakeičiamos į „fsGroup“ pateiktą vertę.
Visa tai, kad „fsGroup“ galėtų skaityti ir rašyti tomą. Tačiau kai kuriais atvejais toks elgesys buvo nepageidaujamas.
Ši nauja versija „Kubernetes“ turi daugybę pakeitimų ir mes paminėjome tik keletą svarbiausių. Jei norite sužinoti visą sąrašą, galite tai padaryti apsilankę sekanti nuoroda.