Razvojni tim Kubernetesa je nedavno objavljen putem najave puštanje nova verzija "Kubernetes 1.18" u kojem razvojni tim spominje da je riječ o 'dovršenoj i dovršenoj' verziji.
U ovoj novoj verziji učinjen je značajan posao na poboljšanju beta i stabilne funkcionalnosti garantovati a bolje korisničko iskustvo. Uložen je jednak napor da se dodaju novi događaji i uzbudljive nove funkcije koje obećavaju da će dodatno poboljšati korisničko iskustvo.
Za one koji nisu svjesni Kubernetes, oni bi to trebali znati je sistem otvorenog koda za automatizaciju raspoređivanje, skaliranje i upravljanje kontejnerske aplikacije.
Fue izvorno dizajnirao Google, iako je njegov razvoj naknadno povjeren Open Source Cloud Computing Foundation (CNCF), koja je danas omogućila da tehnologija orkestracije kontejnera brzo sazrije, zahvaljujući doprinosu tehnoloških giganata.
Što je novo u Kubernetesu 1.18?
Ova nova verzija izdvaja se po tome što ima mogućnost korištenja žetona računa usluga kao opći metod provjere autentičnosti. Na primjer, ako želite da pod upravlja drugim Kubernetesovim resursima, poput postavljanja ili usluge, može se povezati s računom usluge i stvoriti potrebne uloge i povezivanja uloga.
Kubernetes računi usluga (KSA) šalju JSON web tokene (JWT) na API poslužitelj radi provjere autentičnosti. To čini API poslužitelj jedinim izvorom provjere autentičnosti za račune usluga.
Kubernetes 1.18 strpruža funkcionalnost Que omogućava API poslužitelju da pruži dokument otkrivanja OpenID Connect A koji sadrži javne ključeve tokena pored ostalih metapodataka.
Još jedna promjena koja se izdvaja od Kubernetes 1.81 je mogućnost konfiguriranja HPA brzine za određene mahune. Korišten je Horizontal Pod Autoscaler (HPA)a kako bi se Kubernetesovom klasteru omogućilo automatsko reagiranje na veliki / mali promet. Uz HPA, korisnik može zatražiti od kontrolera da kreira više modula kao odgovor na CPU skokove, druga mjerenja ili mjerenja koja pruža aplikacija.
Kubernetes 1.18 ima pregled profila za pokretanje više konfiguracija planera. Generalno postoje dvije vrste radnih opterećenja u Kubernetesu: dugoročne usluge (na primjer, web serveri, API-ji, itd.) I zadaci koji se izvršavaju do kraja (poznatiji kao naziv Poslovi).
Zbog očiglednih razlika između vrsta radnog opterećenja, neki korisnici pribjegavaju stvaranju punih klastera za različite potrebe. Na primjer, jedan klaster za upravljanje rudarstvom podataka, a drugi za opsluživanje API-ja aplikacije.
Razlog je taj što im je potreban postupak odlučivanja da se razlikuju. Na primjer, zadane postavke planera promoviraju visoku dostupnost.
S druge strane, takođe možemo pronaći sposobnost definiranja pravila emitiranja mahuna na razini klastera, šta je omogućio da se pods rasporedi u zonama dostupnosti (pod uvjetom da koristite višezonski klaster) kako biste osigurali maksimalnu dostupnost i korištenje resursa.
Funkcionalnost omogućava specifikaciju topologySpreadConstraints, koja identificira područja pretraživanjem čvorova s istom oznakom topologyKey. Čvorovi s istom oznakom TopologyKey pripadaju istom području. Konfiguracija je bila da se mahune ravnomjerno rasporede na različitim područjima. Međutim, loša strana je ta što se ova postavka mora primijeniti na razini mahune. Podovi koji nemaju konfiguraciju neće biti ravnomjerno raspoređeni po domenama grešaka.
Zadnji ali ne i posljednji, također možemo pronaći mogućnost ignoriranja promjene svojstva volumena. Prema zadanim postavkama, kada je volumen montiran u spremnik na Kubernetesovom klasteru, sve datoteke i direktoriji unutar ovog volumena mijenjaju svojstvo u vrijednost koja se pruža putem fsGroup.
Sve ovo kako bi fsGroup omogućio čitanje i pisanje volumena. Međutim, pokazalo se da je ovo ponašanje u nekim slučajevima nepoželjno.
Ova nova verzija Kubernetes dolazi s nizom promjena, a spomenuli smo samo nekoliko najvažnijih. Ako želite znati potpunu listu, to možete učiniti posjetom sljedeći link.