Kubernetes arendusmeeskond hiljuti välja antud avaldamise kaudu uus versioon "Kubernetes 1.18" milles arendusmeeskond mainib, et see on sobiv ja valmis versioon.
Selles uues versioonis beeta ja stabiilse funktsionaalsuse parandamiseks on tehtud märkimisväärset tööd tagama a parem kasutuskogemus. Võrdselt on püütud lisada uusi arendusi ja põnevaid uusi funktsioone, mis lubavad kasutajakogemust veelgi täiustada.
Neile, kes seda ei tea Kubernetes, nad peaksid seda teadma on avatud lähtekoodiga süsteem automatiseerimiseks - rakendamine, laiendamine ja haldamine konteinerirakendused.
Fue algselt kujundas Google kuigi selle arendamine on hiljem usaldatud avatud lähtekoodiga pilvandmetöötluse sihtasutusele (CNCF), mis tänapäeval on tänu tehnoloogiahiiglaste panusele võimaldanud konteinerorkestratsiooni tehnoloogial kiiresti küpseda.
Mida uut on Kubernetes 1.18-s?
See uus versioon paistab silma selle omamise poolest võimalus kasutada teenuse konto märke üldise autentimismeetodina. Näiteks kui soovite, et pod haldaks teisi Kubernetese ressursse, näiteks juurutamist või teenust, saab selle seostada teenusekontoga ning luua vajalikud rollid ja rollisidemed.
Kubernetese teenuse kontod (KSA-d) saadavad JSON-i veebimärgid (JWT) autentimiseks API-serverile. See muudab API-serveri ainsaks autentimise allikaks teenuse kontode jaoks.
Kubernetes 1.18 lkpakub funktsionaalsust et võimaldab API-serveril pakkuda OpenID Connecti avastamisdokumenti A, mis sisaldab märgi avalikke võtmeid lisaks muudele metaandmetele.
Teine muudatus, mis paistab silma Kubernetes 1.81-st, on võime konfigureerida HPA kiirust konkreetsete kaunade jaoks. Kasutati horisontaalset kauna automaatskalerit (HPA)a võimaldab Kubernetese klastril reageerida automaatselt suurele / madalale liiklusele. HPA abil saab kasutaja paluda kontrolleril luua rohkem mooduleid vastuseks protsessori tõusule, muudele mõõtmistele või rakenduse pakutavatele mõõtmistele.
Kubernetes 1.18-l on ülevaade profiilidest mitme konfiguratsiooni käitamiseks planeerija. Üldiselt on Kubernetes kahte tüüpi töökoormusi: pikaajalised teenused (näiteks veebiserverid, API-d jms) ja lõpuni töötavad ülesanded (paremini tuntud kui nimi Jobs).
Töökoormuse tüüpide ilmsete erinevuste tõttu loovad mõned kasutajad täielike klastrite loomise erinevatele vajadustele. Näiteks üks klaster andmekaevanduse haldamiseks ja teine rakenduse API-de teenindamiseks.
Põhjus on see, et nad vajavad otsustamisprotsessi erinevust. Näiteks soodustavad ajakava vaikesätted kõrget kättesaadavust.
Teiselt poolt võime leida ka võime määratleda klastri tasemel pod-ülekande reegel, kui on võimaldanud tagada, et kaunad planeeritakse kättesaadavustsoonidesse (eeldusel, et kasutate mitmetsoonilist klastrit), et tagada maksimaalne kättesaadavus ja ressursside kasutamine.
Funktsionaalsus võimaldab topologySpreadConstraints spetsifikatsiooni, mis tuvastab alad sama topologyKey märgendiga sõlmede otsimisega. Sama TopologyKey märgendiga sõlmed kuuluvad samasse piirkonda. Konfiguratsioon pidi kaunad jaotuma erinevatesse piirkondadesse ühtlaselt. Negatiivne külg on see, et seda sätet tuleb rakendada kauna tasemel. Kaunad, millel pole konfiguratsiooni, ei jaotata veadomeenide vahel ühtlaselt.
Last but not least võime leida ka võimaluse mahuomaduse muutust eirata. Vaikimisi muudetakse Kubernetesi klastri konteinerisse mahtudes vaikimisi kõigi selle köite failide ja kataloogide omadust fsGroupi kaudu pakutavaks väärtuseks.
Kõik see võimaldab fsGroupil köidet lugeda ja kirjutada. Kuid see käitumine on osutunud mõnel juhul ebasoovitavaks.
See uus versioon Kubernetesega kaasnevad mitmed muudatused ja me oleme maininud vaid mõnda kõige olulisemat. Kui soovite teada täielikku loendit, saate seda teha aadressil järgmine link.