Keď začnete vytvárať čoraz viac služieb Kubernetes, úlohy, ktoré boli pôvodne jednoduché, sa stávajú zložitejšími. Vývojové tímy napríklad nemôžu vytvárať služby alebo nasadenia pod rovnakým názvom. Ak máte tisíce strukov, ich jednoduchý zoznam zaberie veľa času, nehovoriac o ich správnom spravovaní. A toto je len špička ľadovca.
Pozrime sa, ako menný priestor uľahčuje správu zdrojov Kubernetes. Čo je teda menný priestor? Priestor názvov si možno predstaviť ako virtuálny klaster v rámci vášho klastra Kubernetes. V rámci jedného klastra Kubernetes môžete mať viacero priestorov názvov izolovaných od seba. Môžu vám a vašim tímom skutočne pomôcť s organizáciou, zabezpečením a dokonca aj výkonom systému.
Vo väčšine distribúcií Kubernetes sa klaster dodáva z krabice s menným priestorom nazývaným „predvolený“. V skutočnosti existujú tri menné priestory, s ktorými sa Kubernetes zaoberá: predvolený, kube-system a kube-public. V súčasnosti sa Kube-public veľmi často nepoužíva.
Ponechať priestor názvov kube na pokoji je dobrý nápad, najmä v spravovanom systéme, ako je Google Kubernetes Engine. Používa „predvolený“ menný priestor ako miesto, kde sa vytvárajú vaše služby a aplikácie. Nie je na tom absolútne nič zvláštne, okrem toho, že Kubernetes je nakonfigurovaný tak, aby ho používal, a nemôžete ho odstrániť. Je to skvelé pre začiatky a systémy s nízkym výkonom, ale neodporúčal by som používať predvolený priestor názvov na veľkých produkčných systémoch. V druhom prípade môže jeden vývojársky tím ľahko prepísať kód niekoho iného a prelomiť prácu iného tímu bez toho, aby si to uvedomoval.
Preto by ste mali vytvoriť viacero menných priestorov a použiť ich na segmentáciu vašich služieb do spravovateľných jednotiek. Menný priestor je možné vytvoriť jediným príkazom. Ak chcete vytvoriť menný priestor s názvom test, použite príkaz $ kubectl create namespace test alebo jednoducho vytvorte súbor YAML a použite ho ako akýkoľvek iný zdroj Kubernetes.
Všetky menné priestory môžete zobraziť pomocou príkazu $ kubectl get namespace.
Po dokončení uvidíte tri vstavané menné priestory a nový menný priestor s názvom „test“. Pozrime sa na jednoduchý súbor YAML na vytvorenie pod. Všimnete si, že tam nie je zmienka o mennom priestore.
Ak na spustenie tohto súboru použijete kubectl, vytvorí sa modul mypod v aktuálne aktívnom mennom priestore. Toto bude predvolený menný priestor, kým ho nezmeníte. Existujú 2 spôsoby, ako povedať Kubernetes, v akom mennom priestore chcete vytvoriť svoj zdroj. Prvým spôsobom je použitie príznaku menného priestoru pri vytváraní zdroja.
Druhým spôsobom je špecifikácia menného priestoru v deklarácii YAML.
Ak zadáte priestor názvov v YAML, zdroj sa vždy vytvorí v tomto priestore názvov. Ak sa pri používaní príznaku priestoru názvov pokúsite použiť iný priestor názvov, príkaz zlyhá. Ak sa teraz pokúsite nájsť svoj modul, už sa vám to nepodarí.
K tomu dochádza, pretože všetky príkazy sa vykonávajú mimo aktuálne aktívneho priestoru názvov. Ak chcete nájsť svoj modul, musíte použiť príznak priestoru názvov, ale to vás rýchlo omrzí, najmä ak ste vývojár v tíme, ktorý používa svoj vlastný priestor názvov a nechcete používať tento príznak pre každý jeden príkaz. Pozrime sa, ako to môžeme napraviť.
Po vybalení sa váš aktívny menný priestor nazýva predvolený. Ak nešpecifikujete menný priestor v prostriedku YAML, všetky príkazy Kubernetes budú používať tento aktívny predvolený menný priestor. Bohužiaľ, pokus o správu aktívneho menného priestoru pomocou kubectl môže zlyhať. Existuje však veľmi dobrý nástroj s názvom Kubens, ktorý tento proces značne uľahčuje. Keď spustíte príkaz kubens, uvidíte všetky menné priestory so zvýrazneným aktívnym menným priestorom.
Ak chcete prepnúť aktívny menný priestor na testovací menný priestor, jednoducho spustite príkaz $kubens test. Ak potom znova spustíte príkaz $kubens, uvidíte, že je teraz pridelený nový aktívny menný priestor - test.
To znamená, že na zobrazenie pod v testovacom priestore názvov nepotrebujete príznak názvového priestoru.
Týmto spôsobom sú menné priestory navzájom skryté, ale nie sú od seba izolované. Služba v jednom mennom priestore môže pomerne jednoducho komunikovať so službou v inom mennom priestore, čo je často veľmi užitočné. Schopnosť komunikovať cez rôzne menné priestory znamená, že vaša vývojárska služba môže komunikovať so službou iného vývojárskeho tímu v inom mennom priestore.
Zvyčajne, keď chce vaša aplikácia získať prístup k službe Kubernetes, použijete vstavanú službu zisťovania DNS a jednoducho dáte svojej aplikácii názov služby. Týmto spôsobom však môžete vytvoriť službu pod rovnakým názvom vo viacerých menných priestoroch, čo nie je prijateľné.
Našťastie sa to dá ľahko obísť pomocou rozšírenej formy adresy DNS. Služby v Kubernetes odhaľujú svoje koncové body pomocou spoločnej šablóny DNS. Vyzerá to asi takto:
Zvyčajne vám stačí názov služby a DNS automaticky určí celú adresu.
Ak však potrebujete pristupovať k službe v inom priestore názvov, jednoducho použite názov služby plus názov priestoru názvov:
Napríklad, ak sa chcete pripojiť k servisnej databáze v testovacom priestore názvov, môžete použiť adresu database.test
Ak sa chcete pripojiť k servisnej databáze v mennom priestore prod, použite database.prod.
Ak naozaj chcete izolovať a obmedziť prístup k priestoru názvov, Kubernetes vám to umožňuje pomocou pravidiel siete Kubernetes. O tom budem hovoriť v ďalšej epizóde.
Často dostávam otázku, koľko menných priestorov by som mal vytvoriť a na aký účel? Čo je to spravovaný údaj?
Ak vytvoríte príliš veľa menných priestorov, jednoducho vám budú prekážať. Ak ich bude príliš málo, prídete o všetky výhody takéhoto riešenia. Myslím si, že existujú štyri hlavné etapy, ktorými prechádza každá firma pri vytváraní svojej organizačnej štruktúry. V závislosti od štádia vývoja, v ktorom sa váš projekt alebo spoločnosť nachádza, možno budete chcieť prijať vhodnú stratégiu menného priestoru.
Predstavte si, že ste súčasťou malého tímu, ktorý pracuje na vývoji 5-10 mikroslužieb a môžete ľahko zhromaždiť všetkých vývojárov v jednej miestnosti. V tejto situácii má zmysel spúšťať všetky prod služby v predvolenom mennom priestore. Samozrejme, pre väčšiu flexibilitu môžete použiť 2 menné priestory – samostatne pre prod a dev. A s najväčšou pravdepodobnosťou testujete svoj vývoj na lokálnom počítači pomocou niečoho ako Minikube.
Povedzme, že sa veci menia a teraz máte rýchlo rastúci tím, ktorý pracuje na viac ako 10 mikroslužbách súčasne. Prichádza čas, kedy je potrebné použiť niekoľko klastrov alebo menných priestorov, zvlášť pre prod a dev. Tím môžete rozdeliť do niekoľkých podtímov, takže každý z nich má svoje vlastné mikroslužby a každý z týchto tímov si môže vybrať svoj vlastný menný priestor na uľahčenie procesu riadenia vývoja a vydania softvéru.
Ako každý člen tímu získava prehľad o tom, ako systém ako celok funguje, je čoraz ťažšie koordinovať každú zmenu so všetkými ostatnými vývojármi. Pokúšať sa roztočiť plný zásobník na lokálnom počítači je každým dňom ťažšie.
Vo veľkých spoločnostiach vývojári vo všeobecnosti nevedia, kto presne na čom pracuje. Tímy komunikujú pomocou servisných zmlúv alebo využívajú technológiu service mesh, ktorá pridáva abstrakciu cez sieť, ako je napríklad konfiguračný nástroj Istio. Pokúsiť sa spustiť celý zásobník lokálne jednoducho nie je možné. Dôrazne odporúčam použiť platformu kontinuálneho doručovania (CD), ako je Spinnaker na Kubernetes. Takže prichádza bod, kedy každý príkaz určite potrebuje svoj vlastný menný priestor. Každý tím si môže dokonca vybrať viacero menných priestorov pre vývojárske prostredie a prod prostredie.
Napokon existujú veľké podnikateľské spoločnosti, v ktorých jedna skupina developerov ani nevie o existencii iných skupín. Takáto spoločnosť môže vo všeobecnosti najať vývojárov tretích strán, ktorí s ňou komunikujú prostredníctvom dobre zdokumentovaných rozhraní API. Každá takáto skupina obsahuje niekoľko tímov a niekoľko mikroslužieb. V tomto prípade musíte použiť všetky nástroje, o ktorých som hovoril skôr.
Programátori by nemali manuálne nasadzovať služby a nemali by mať prístup k priestorom názvov, ktoré sa ich netýkajú. V tejto fáze je vhodné mať niekoľko klastrov, aby sa zmenšil „polomer výbuchu“ zle nakonfigurovaných aplikácií, aby sa zjednodušili fakturačné procesy a správa zdrojov.
Správne používanie menných priestorov vašou organizáciou vám teda umožňuje urobiť Kubernetes spravovateľnejším, kontrolovateľnejším, bezpečnejším a flexibilnejším.
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com