Jakmile začnete vytvářet stále více služeb Kubernetes, jednoduché úkoly, které byly na začátku, se začnou komplikovat. Například vývojové týmy nemohou vytvářet služby nebo nasazení se stejným názvem. Pokud máte tisíce podů, jejich jednoduché vyjmenování zabere spoustu času, natož abyste zajistili jejich správu. A to je jen špička ledovce.
Pojďme se podívat na to, jak prostor názvů usnadňuje správu zdrojů Kubernetes. Co je vlastně prostor názvů? Prostor názvů lze považovat za virtuální cluster uvnitř vašeho clusteru Kubernetes. Můžete mít několik oddělených prostorů názvů v jednom clusteru Kubernetes. Opravu vám a vašim týmům mohou pomoci s organizací, bezpečností a dokonce výkonem systému.
Ve většině distribucí Kubernetes cluster „vyjde z krabice“ s prostorem názvů nazvaným „default“. Ve skutečnosti existují tři prostory názvů, se kterými Kubernetes pracuje: default, kube-system a kube-public. V současnosti je kube-public používán poměrně zřídka.
Nedotýkat se prostoru názvů kube je dobrý nápad, zejména v tak řízeném systému, jako je Google Kubernetes Engine. Používá prostor názvů „default“ jako místo, kde se vytvářejí vaše služby a aplikace. Neexistuje v něm vůbec nic zvláštního, kromě toho, že je Kubernetes „z krabice“ nakonfigurován pro jeho používání a nemůžete ho smazat. To je skvělé pro začátek a systémy s malým výkonem, ale nedoporučoval bych používat prostor názvů default ve velkých produkčních systémech. V posledním případě si může jeden vývojový tým snadno přepsat kód jiného a narušit tím práci jiného týmu, aniž by si to uvědomil.
Proto byste měli vytvořit několik prostorů názvů a používat je k segmentaci vašich služeb do spravovaných celků. Prostor názvů lze vytvořit pomocí jednoho příkazu. Pokud chcete vytvořit prostor názvů s názvem test, použijte příkaz $ kubectl create namespace test nebo jednoduše vytvořte YAML soubor a použijte ho jako jakýkoli jiný zdroj Kubernetes.
Všechny prostory názvů lze zobrazit pomocí příkazu $ kubectl get namespace.
Po jeho provedení uvidíte tři zabudované prostory názvů a nový prostor názvů s názvem „test“. Pojďme se podívat na jednoduchý YAML soubor určený k vytvoření podu. Můžete si všimnout, že v něm není žádná zmínka o prostoru názvů.
Pokud použijete kubectl k spuštění tohoto souboru, vytvoří modul mypod v aktuálním aktivním prostoru názvů. Tímto prostorem názvů bude výchozí prostor, dokud ho nezměníte. Existují dva způsoby, jak oznámit Kubernetes, v jakém prostoru názvů chcete vytvořit svůj zdroj. První způsob je použití příznaku prostoru názvů při vytváření zdroje.
Druhý způsob spočívá v uvedení prostoru názvů v deklaraci YAML.
Pokud uvedete prostor názvů v YAML, bude zdroj vždy vytvářen v tomto prostoru. Pokud se pokusíte použít jiný prostor názvů s použitím příznaku prostoru názvů, příkaz selže. Nyní, pokud se pokusíte najít svůj pod, nebudete moci.
To se děje proto, že všechny příkazy se provádějí mimo aktuální aktivní prostor názvů. Abyste našli svůj pod, musíte použít příznak prostoru názvů, což však rychle omrzí, zejména pokud pracujete jako vývojář ve skupině, která používá svůj vlastní prostor názvů a nechce tento příznak používat pro každý jednotlivý příkaz. Pojďme se podívat, jak to lze opravit.
Z výroby se váš aktivní prostor názvů nazývá default. Pokud neupřesníte prostor názvů v YAML zdroje, budou všechny příkazy Kubernetes používat tento aktivní default namespace. Bohužel pokus o správu aktivního prostoru názvů pomocí kubectl může vést k neúspěchu. Nicméně existuje velmi dobrý nástroj s názvem Kubens, který tento proces výrazně zjednodušuje. Když spustíte příkaz kubens, vidíte všechny prostory názvů se zvýrazněným aktivním prostorem názvů.
Pro přepnutí aktivního prostoru názvů na prostor názvů test stačí spustit příkaz $ kubens test. Pokud poté znovu zadáte příkaz $ kubens, můžete vidět, že nyní je zvýrazněn nový aktivní prostor názvů – test.
To znamená, že nepotřebujete flag prostoru názvů, abyste viděli pod v prostoru názvů test.
Tímto způsobem jsou prostory názvů vzájemně skryté, ale neizolované. Služba z jednoho prostoru názvů může docela snadno komunikovat se službou v jiném prostoru názvů, což bývá velmi užitečné. Schopnost komunikace mezi různými prostory názvů znamená, že služba vašich vývojářů může interagovat se službou jiné vývojářské skupiny v jiném prostoru názvů.
Obvykle, když vaše aplikace chce přistupovat k službě Kubernetes, používáte vestavěnou službu pro objevování DNS a jednoduše říkáte své aplikaci název služby. Nicméně tímto způsobem můžete vytvořit službu se stejným názvem ve více prostorech názvů, což je nepřípustné.
Naštěstí to lze snadno obejít pomocí rozšířené formy DNS adresy. Služby v Kubernetes vystavují své koncové body pomocí společného vzoru DNS. Vypadá to přibližně takto:
Obecně potřebujete pouze název služby, a DNS automaticky určí celou adresu.
Pokud však potřebujete přistupovat ke službě v jiném prostoru názvů, jednoduše použijte název služby plus název prostoru názvů:
Například, pokud chcete připojit k databázové službě v testovacím prostoru názvů, můžete použít adresu database.test.
Pokud se však chcete připojit k databázové službě v prostoru názvů prod, použijete database.prod.
Pokud opravdu chcete izolovat a omezit přístup k prostoru názvů, Kubernetes to umožňuje pomocí síťových politik Kubernetes Network Policies. O tom budu hovořit v příští sérii.
Často se mě ptají, kolik prostorů názvů je třeba vytvořit a za jakým účelem? Co vlastně představuje spravovaný fragment dat?
Pokud vytvoříte příliš mnoho prostorů názvů, jen vám budou překážet. Naopak, pokud jich bude příliš málo, přijdete o všechny výhody takového řešení. Myslím, že existují čtyři hlavní fáze, kterými si každá společnost projde při vytváření své organizační struktury. V závislosti na fázi vývoje, na které se váš projekt nebo společnost nachází, můžete přijmout odpovídající strategii pro vytváření prostorů názvů.
Představte si, že jste součástí malého týmu, který pracuje na vývoji 5-10 mikroslužeb, a můžete snadno shromáždit všechny vývojáře v jedné místnosti. V této situaci dává smysl spouštět všechny produkční služby ve výchozím prostoru názvů. Samozřejmě, pokud potřebujete více prostoru pro aktivity, můžete použít 2 prostory názvů — jeden pro produkci a druhý pro vývoj. A pravděpodobně testujete svůj vývoj na místním počítači pomocí něčeho jako Minikube.
Předpokládejme, že se podmínky změnily a nyní máte rychle rostoucí tým, který současně pracuje na více než 10 mikroslužbách. Přichází okamžik, kdy je nutné použít několik klastrů nebo prostorů názvů, odděleně pro produkci a vývoj. Můžete rozdělit tým na několik podskupin, tak aby každá z nich měla své vlastní mikroslužby a každá z těchto týmů si mohla vybrat své vlastní prostředí pro usnadnění procesu správy vývoje a vydávání softwaru.
Jak každý člen týmu získává představu o tom, jak systém funguje jako celek, koordinace každé změny se všemi ostatními vývojáři se stává stále obtížnější a obtížnější. Pokus o rozjetí celého stacku na vašem místním počítači se s každým dnem stává složitějším.
Ve velkých firmách vývojáři vůbec nevědí, kdo konkrétně na čem pracuje. Týmy komunikují prostřednictvím servisních smluv nebo používají technologii Service mesh, která přidává nad sítí úroveň abstrakce, jako je konfigurační nástroj Istio. Pokus o spuštění celého stacku lokálně je jednoduše nemožný. Důrazně doporučuji využít v Kubernetes platformu pro nepřetržité dodávání (CD) jako Spinnaker. A tak přichází okamžik, kdy každému týmu rozhodně potřebuje vlastní prostor jmen. Každý tým si dokonce může zvolit několik prostor jmen pro prostředí dev a prod.
Nakonec existují velké podnikatelské společnosti, ve kterých jedna skupina vývojářů dokonce nezná existenci jiných skupin. Taková firma může vůbec najmout externí vývojáře, kteří komunikují prostřednictvím dobře zdokumentovaných API. V každé takové skupině je několik týmů a několik mikroslužeb. V takovém případě je nutné použít všechny nástroje, o kterých jsem mluvil dříve.
Programátoři by neměli nasazovat služby ručně a neměli by mít přístup k jménům prostor, které se jich netýkají. V této fázi je rozumné mít několik klastrů pro snížení "radioaktivního dosahu" špatně nakonfigurovaných aplikací, pro zjednodušení procesů fakturace a správy zdrojů.
Tímto způsobem správné použití jmen prostor vaší organizací umožňuje učinit Kubernetes více říditelným, kontrolovaným, bezpečným a pružným.
Malá reklama 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
