Ako začnete vytvárať stále viac a viac služieb Kubernetes, jednoduché úlohy na začiatku sa začínajú komplikovať. Napríklad vývojové tímy nemôžu vytvárať služby alebo nasadenia s rovnakým menom. Ak máte tisíce podov, ich jednoduché vypísanie zabere veľa času, nieto ešte zabezpečiť riadne spravovanie. A to je len špička ľadovca.
Poďme sa pozrieť, ako namespace uľahčuje správu zdrojov Kubernetes. Čo je teda namespace? Namespace môžeme považovať za virtuálny klaster vo vnútri vášho klastera Kubernetes. Môžete mať niekoľko navzájom izolovaných namespaces v rámci jedného klastera Kubernetes. Skutočne vám môžu a vašim tímom pomôcť s organizáciou, bezpečnosťou a dokonca aj výkonom systému.
Vo väčšine distribúcií Kubernetes je klaster 'out of the box' so namespace nazvaným 'default'. V skutočnosti existujú tri namespaces, s ktorými Kubernetes pracuje: default, kube-system a kube-public. Kube-public sa aktuálne používa pomerne zriedka.
Nedotýkať sa namespace kube je dobrý nápad, najmä v takto spravovanej sústave ako Google Kubernetes Engine. Používa namespace 'default' ako miesto, kde sú vytvárané vaše služby a aplikácie. Nie je tam absolútne nič zvláštne, okrem toho, že Kubernetes je 'out of the box' nastavený na jeho použitie a nemôžete ho odstrániť. To je skvelé na začiatok a pre systémy s nízkym výkonom, ale neodporúčal by som používanie namespace default vo veľkých produkčných systémoch. V poslednom prípade môže jeden tím vývojárov ľahko prepísať kód iného tímu a narušiť prácu iného tímu, aniž by si to uvedomovali.
Preto by ste mali vytvoriť niekoľko namespaces a použiť ich na segmentáciu vašich služieb do spravovaných celkov. Namespace môžete vytvoriť pomocou jedného príkazu. Ak chcete vytvoriť namespace s názvom test, použite príkaz $ kubectl create namespace test alebo jednoducho vytvorte YAML súbor a použite ho ako akýkoľvek iný zdroj Kubernetes.
Všetky namespaces môžete zobraziť pomocou príkazu $ kubectl get namespace.
Po jej úspešnom vykonaní uvidíte tri zabudované menové priestory a nový menový priestor s názvom „test“. Pozrime sa na jednoduchý YAML súbor, ktorý je určený na vytvorenie podu. Je zaujímavé, že v ňom nie je žiadna zmienka o menovom priestore.
Ak použijete kubectl na spustenie tohto súboru, vytvorí modul mypod v aktuálnom aktívnom menovom priestore. Tento menový priestor bude predvolený, pokým ho nezmeníte. Existujú dva spôsoby, ako povedať Kubernetes, v akom menovom priestore chcete vytvoriť svoj zdroj. Prvý spôsob je použitím vlajky menového priestoru pri vytváraní zdroja.
Druhý spôsob spočíva v uvedení menového priestoru v deklarácii YAML.
Ak uvediete menový priestor v YAML, bude sa zdroj vždy vytvárať v tomto priestore. Ak sa pokúsite použiť iný menový priestor pri použití vlajky menového priestoru, príkaz skončí chybou. Teraz, ak sa pokúsite nájsť svoj pod, nebude sa vám to podariť.
To sa deje, pretože všetky príkazy sa vykonávajú mimo aktuálneho aktívneho menového priestoru. Aby ste našli svoj pod, musíte použiť vlajku menového priestoru, avšak to rýchlo otravuje, najmä ak pracujete ako vývojár v skupine, ktorá používa vlastný menový priestor a nechce používať túto vlajku pre každý jednotlivý príkaz. Pozrime sa, ako to môžete opraviť.
Z predpokladom sa váš aktívny menový priestor nazýva default. Ak v YAML zdroja neurčíte menový priestor, všetky príkazy Kubernetes budú používať tento aktívny predvolený menový priestor. Bohužiaľ, pokusy o správu aktívneho menového priestoru pomocou kubectl môžu skončiť neúspechom. Existuje však veľmi dobrý nástroj s názvom Kubens, ktorý tento proces značne zjednodušuje. Keď spustíte príkaz kubens, uvidíte všetky menové priestory s vyznačeným aktívnym menovým priestorom.
Na prepnutie aktívneho menového priestoru na menový priestor test jednoducho spustíte príkaz $ kubens test. Ak potom znova zadáte príkaz $ kubens, môžete vidieť, že sa teraz zvýraznil nový aktívny menový priestor – test.
To znamená, že na zobrazenie podu v testovacom priestore mien nepotrebujete vlajku priestoru mien.
Takto sú priestory mien skryté navzájom, ale nie sú od seba izolované. Služba z jedného priestoru mien môže pomerne ľahko komunikovať so službou v inom priestore mien, čo býva velmi užitočné. Možnosť komunikácie medzi rôznymi priestormi mien znamená, že služba vašich vývojárov môže interagovať so službou iného dev-tímu v inom priestore mien.
Zvyčajne, keď vaša aplikácia chce komunikovať so službou Kubernetes, používate zabudovanú službu objavovania DNS a jednoducho svojim aplikáciám uvediete meno služby. Avšak môžete vytvoriť službu s rovnakým menom v rôznych priestoroch mien, čo je neprípustné.
Našťastie to možno ľahko obísť použitím rozšírenej formy DNS adresy. Služby v Kubernetes vystavujú svoje koncové body pomocou spoločnej šablóny DNS. To vyzerá asi takto:
Vo všeobecnosti potrebujete len meno služby a DNS automaticky určí plnú adresu.
Ak však potrebujete pristupovať k službe v inom priestore mien, jednoducho použite meno služby plus názov priestoru mien:
Napríklad, ak chcete pripojiť k databáze služby v testovacom priestore mien, môžete použiť adresu database.test.
Ak sa však chcete pripojiť k databáze služby v priestore mien prod, použijete database.prod.
Ak naozaj chcete izolovať a obmedziť prístup k priestoru mien, Kubernetes to umožňuje prostredníctvom sieťových politík Kubernetes Network Policies. O tom sa zmienim v nasledujúcej sérii.
Často sa ma pýtajú, koľko priestorov mien treba vytvoriť a na aké účely? Čo teda predstavuje riadený fragment údajov?
Ak vytvoríte príliš veľa priestorov názvov, len 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, že existujú štyri základné etapy, ktorými prechádza každá spoločnosť pri vytváraní svojej organizačnej štruktúry. V závislosti od etapy vývoja, na ktorej sa vaše projekty alebo spoločnosti nachádzajú, si môžete zvoliť príslušnú stratégiu pre vytváranie priestorov názvov.
Predstavte si, že ste súčasťou malej tímu, ktorý pracuje na vývoji 5-10 mikroslužieb a všetkých vývojárov môžete ľahko zhromaždiť v jednej miestnosti. V tejto situácii má zmysel spúšťať všetky produkčné služby v priestore názvov default. Samozrejme, pre väčšie možnosti môžete použiť dva priestory názvov — jeden pre produkciu a druhý pre vývoj. A pravdepodobne testujete svoj vývoj na lokálnom počítači pomocou niečoho ako Minikube.
Predpokladajme, že sa podmienky zmenili a teraz máte rýchlo rastúci tím, ktorý súčasne pracuje na viac ako 10 mikroslužbách. Nastáva moment, keď je potrebné použiť niekoľko klastrov alebo priestorov názvov, samostatne pre produkciu a vývoj. Môžete rozdeliť tím na niekoľko podskupín tak, aby každá z nich mala svoje vlastné mikroslužby a každá z týchto tímov si mohla vybrať svoje vlastné priestory názvov na zjednodušenie procesu riadenia vývoja a vydávania softvéru.
Ako každý člen tímu získava predstavu o tom, ako systém funguje ako celok, koordinovať každú zmenu so všetkými ostatnými vývojármi sa stáva čoraz ťažším. Pokus o rozbehnutie celého stacku na vašom lokálnom počítači sa s každým dňom stáva zložitejším.
V veľkých spoločnostiach vývojári často ani nevedia, kto konkrétne na čom pracuje. Tímy komunikujú prostredníctvom servisných zmlúv alebo používajú technológiu Service mesh, ktorá pridáva nad sieťou úroveň abstrakcie, ako nástroj na konfiguráciu Istio. Pokus spustiť celý stack lokálne je jednoducho nemožný. Dôrazne odporúčam používať v Kubernetes platformu kontinuálneho dodávania (CD) ako Spinnaker. Tak prichádza okamih, keď každému tímu určite treba vlastný namespace. Každý tím si dokonca môže vybrať niekoľko namespace-ov pre prostredie dev a prostredie prod.
Nakoniec existujú veľké podnikateľské spoločnosti, v ktorých jedna skupina vývojárov ani nevie o existencii iných skupín. Takáto spoločnosť môže dokonca zamestnať externých vývojárov, ktorí spolupracujú prostredníctvom dobre zdokumentovaných API. V každej takejto skupine je niekoľko tímov a niekoľko mikroslužieb. V tomto prípade je potrebné využiť všetky nástroje, o ktorých som hovoril skôr.
Programátori by nemali nasadzovať služby ručne a nemali by mať prístup k namespace-om, ktoré sa ich netýkajú. V tejto fáze je vhodné mať niekoľko klastrov na zníženie "radii explózie" zle nastavených aplikácií, na zjednodušenie procesov fakturácie a spravovania zdrojov.
Takže správne používanie namespace-ov vo vašej organizácii umožňuje spraviť Kubernetes viac spravovateľným, kontrolovateľným, bezpečným a flexibilným.
Trochu reklamy 🙂
Ďakujeme, že ostávate s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavých materiálov? Podporte nás, vytvorením objednávky alebo odporúčaním známym, , unikátny ekvivalent entry-level serverov, ktorý sme pre vás vytvorili: (k dispozícii varianty s RAID1 a RAID10, až 24 jadier a až 40GB DDR4).
Dell R730xd je dvakrát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len u nás v Holandsku! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolárov! Prečítajte si o tom
Zdroj: habr.com
