Vývojový tým Kubernetes nedávno vydala prostřednictvím oznámení o vydání nová verze „Kubernetes 1.18“ ve kterém vývojový tým uvádí, že se jedná o verzi „vhodnou a hotovou“.
V této nové verzi byla provedena velká práce na vylepšení beta a stabilní funkčnosti zaručit a lepší uživatelská zkušenost. Stejné úsilí bylo vynaloženo na přidání nového vývoje a vzrušujících nových funkcí, které slibují další zlepšení uživatelského zážitku.
Pro ty, kteří nevědí Kubernetes, měli by to vědět je automatizovaný systém s otevřeným zdrojovým kódem implementace, změna měřítka a řízení kontejnerové aplikace.
To bylo původně navržen společností Google, i když jeho vývojem byla následně pověřena Open Source Cloud Computing Foundation (CNCF), která dnes díky příspěvkům technologických gigantů umožnila rychlou technologii orchestrace kontejnerů.
Co je nového v Kubernetes 1.18?
Tato nová verze vyniká tím, že má schopnost používat tokeny účtu služby jako obecná metoda ověřování. Například pokud chcete, aby pod spravoval další prostředky Kubernetes, jako je nasazení nebo služba, může být přidružen k účtu služby a vytvořit potřebné role a vazby rolí.
Účty služeb Kubernetes (KSA) odesílají webové tokeny JSON (JWT) na server API k ověření. Díky tomu je server API jediným zdrojem ověřování pro servisní účty.
Kubernetes 1.18 sposkytuje funkčnost že umožňuje serveru API poskytnout dokument zjišťování OpenID Connect A obsahující veřejné klíče tokenu kromě dalších metadat.
Další změnou, která vyčnívá z Kubernetes 1.81, je schopnost konfigurovat rychlost HPA pro konkrétní pody. Byl použit horizontální automatický škálovač (HPA)a umožnit clusteru Kubernetes automaticky reagovat na vysoký / nízký provoz. Pomocí HPA může uživatel požádat řadič, aby vytvořil více modulů v reakci na špičky CPU, jiná měření nebo měření poskytovaná aplikací.
Kubernetes 1.18 obsahuje přehled profilů pro spuštění více konfigurací plánovače. Obecně existují v Kubernetes dva typy pracovních zátěží: dlouhodobé služby (například webové servery, API atd.) A úkoly, které se dokončují (lépe známé jako název Úlohy).
Kvůli zjevným rozdílům mezi typy pracovní zátěže se někteří uživatelé uchylují k vytvoření úplných klastrů pro různé potřeby. Například jeden klastr pro správu dolování dat a druhý pro obsluhu aplikačních API.
Důvodem je, že potřebují odlišný rozhodovací proces. Například výchozí nastavení plánovače podporuje vysokou dostupnost.
Na druhou stranu můžeme také najít schopnost definovat pravidlo vysílání pod na úrovni klastru, jak umožnil zajistit, že lusky budou naplánovány v zónách dostupnosti (pokud používáte vícezónový klastr), abyste zajistili maximální dostupnost a využití zdrojů.
Funkce umožňuje specifikaci topologySpreadConstraints, která identifikuje oblasti hledáním uzlů se stejnou značkou topologyKey. Uzly se stejnou značkou TopologyKey patří do stejné oblasti. Konfigurace spočívala v rovnoměrném rozložení lusků v různých oblastech. Nevýhodou však je, že toto nastavení musí být použito na úrovni podu. Pody, které nemají konfiguraci, nebudou rovnoměrně distribuovány napříč doménami poruch.
V neposlední řadě, můžeme také najít schopnost ignorovat změnu ve vlastnosti hlasitosti. Ve výchozím nastavení je při připojení svazku v kontejneru v klastru Kubernetes u všech souborů a adresářů v tomto svazku jejich vlastnost změněna na hodnotu poskytovanou prostřednictvím fsGroup.
To vše umožňuje fsGroup číst a zapisovat svazek. Ukázalo se však, že toto chování je v některých případech nežádoucí.
Tato nová verze Kubernetes přichází s řadou změn a zmínili jsme jen několik nejdůležitějších. Chcete-li znát kompletní seznam, můžete to navštívit na stránce následující odkaz.