Vývojový tím Kubernetes nedávno vydala prostredníctvom oznámenia o vydaní nová verzia „Kubernetes 1.18“ v ktorom vývojový tím uvádza, že ide o verziu „vhodnú a hotovú“.
V tejto novej verzii významná práca sa urobila na zlepšení beta a stabilnej funkčnosti zaručiť a lepšia používateľská skúsenosť. Rovnaké úsilie bolo vynaložené na pridanie nového vývoja a vzrušujúcich nových funkcií, ktoré sľubujú ďalšie vylepšenie užívateľského zážitku.
Pre tých, ktorí o tom nevedia Kubernetes, mali by to vedieť je open source systém na automatizáciu implementácia, zmena mierky a správa systému kontajnerové aplikácie.
bolo pôvodne navrhnutý spoločnosťou Google, aj keď jeho vývojom bola následne poverená Open Source Cloud Computing Foundation (CNCF), ktorá dnes vďaka príspevkom technologických gigantov umožnila rýchlemu dozretiu technológie orchestrácie kontajnerov.
Čo je nové v Kubernetes 1.18?
Táto nová verzia vyniká tým, že schopnosť používať tokeny účtov služieb ako všeobecná metóda autentifikácie. Napríklad ak chcete, aby pod spravoval ďalšie prostriedky Kubernetes, napríklad nasadenie alebo službu, môže byť priradený k účtu služby a vytvárať potrebné roly a väzby rolí.
Služobné účty Kubernetes (KSA) odosielajú webové tokeny JSON (JWT) na server API na autentifikáciu. Toto robí server API jediným zdrojom autentifikácie pre účty služieb.
Kubernetes 1.18sposkytuje funkčnosť že umožňuje serveru API poskytnúť dokument zisťovania OpenID Connect A, ktorý okrem ďalších metaúdajov obsahuje verejné kľúče tokenu.
Ďalšou zmenou, ktorá sa odlišuje od Kubernetes 1.81, je schopnosť konfigurovať rýchlosť HPA pre konkrétne pody. Použil sa horizontálny podoskovač (HPA)a umožniť klastru Kubernetes automaticky reagovať na vysoký / nízky prenos. Pomocou HPA môže používateľ požiadať radič, aby vytvoril viac modulov v reakcii na špičky CPU, iné merania alebo merania poskytované aplikáciou.
Kubernetes 1.18 má prehľad profilov na spustenie viacerých konfigurácií plánovača. Spravidla existujú v Kubernetes dva typy pracovných záťaží: dlhodobé služby (napríklad webové servery, API atď.) A úlohy, ktoré sa dokončia (známejšie ako Jobs).
Kvôli zjavným rozdielom medzi typmi pracovného zaťaženia sa niektorí používatelia uchyľujú k vytváraniu úplných klastrov pre rôzne potreby. Napríklad jeden klaster na správu dolovania údajov a druhý na obsluhu aplikačných rozhraní API.
Dôvod je ten, že potrebujú, aby sa proces rozhodovania líšil. Napríklad predvolené nastavenia plánovača podporujú vysokú dostupnosť.
Na druhej strane nájdeme tiež schopnosť definovať pravidlo vysielania pod na úrovni klastra, ako umožnil zabezpečiť plánovanie podov v zónach dostupnosti (za predpokladu, že používate viaczónový klaster), aby ste zaistili maximálnu dostupnosť a využitie zdrojov.
Funkcia umožňuje špecifikáciu topologySpreadConstraints, ktorá identifikuje oblasti vyhľadaním uzlov s rovnakou značkou topologyKey. Uzly s rovnakou značkou TopologyKey patria do rovnakej oblasti. Konfigurácia spočívala v rovnomernom rozložení toboliek v rôznych oblastiach. Nevýhodou však je, že toto nastavenie sa musí použiť na úrovni podu. Pody, ktoré nemajú konfiguráciu, nebudú rovnomerne distribuované medzi chybovými doménami.
V neposlednom rade, nájdeme tiež schopnosť ignorovať zmenu vlastnosti objemu. Keď je zväzok pripojený v kontajneri v klastri Kubernetes, štandardne sa ich vlastnosť všetkých súborov a adresárov v tomto zväzku zmenila na hodnotu poskytovanú prostredníctvom fsGroup.
To všetko umožňuje fsGroup čítať a zapisovať zväzok. Ukázalo sa však, že toto správanie je v niektorých prípadoch nežiaduce.
Táto nová verzia Kubernetes prichádza s radom zmien a spomenuli sme iba niekoľko najdôležitejších. Ak chcete poznať celý zoznam, môžete tak urobiť navštívením nasledujúci odkaz.