Dobrý deň, volám sa Dmitrij Krasnov. Viac ako päť rokov spravujem klastre Kubernetes a budujem komplexné architektúry mikroslužieb. Začiatkom tohto roka sme spustili službu na správu klastrov Kubernetes na báze Containerum. Pri tejto príležitosti vám poviem, čo je Kubernetes a ako sa integrácia s dodávateľom líši od open source.
Na začiatok, čo je . Toto je systém na správu kontajnerov na veľkom počte hostiteľov. Mimochodom, z gréčtiny sa prekladá ako „pilot“ alebo „kormidelník“. Pôvodne vyvinutý spoločnosťou Google a potom darovaný ako technologický príspevok Cloud Native Computing Foundation, medzinárodnej neziskovej organizácii, ktorá spája popredných svetových vývojárov, koncových používateľov a poskytovateľov kontajnerových technológií.
Spravujte veľké množstvo kontajnerov
Teraz poďme zistiť, aké druhy kontajnerov sú. Ide o aplikáciu s celým prostredím – hlavne knižnicami, na ktorých je program závislý. To všetko je zabalené v archívoch a prezentované vo forme obrazu, ktorý je možné spustiť bez ohľadu na operačný systém, testovať a pod. Je tu však problém – správa kontajnerov na veľkom počte hostiteľov je veľmi náročná. Preto vznikol Kubernetes.
Obrázok kontajnera predstavuje aplikáciu plus jej závislosti. Aplikácia, jej závislosti a obraz systému súborov OS sú umiestnené v rôznych častiach obrazu, takzvaných vrstvách. Vrstvy je možné opätovne použiť pre rôzne nádoby. Napríklad všetky aplikácie v spoločnosti môžu používať základnú vrstvu Ubuntu. Pri spúšťaní kontajnerov nie je potrebné ukladať viacero kópií jednej základnej vrstvy na hostiteľovi. To vám umožní optimalizovať ukladanie a doručovanie obrázkov.
Keď chceme spustiť aplikáciu z kontajnera, potrebné vrstvy sa na seba naložia a vytvorí sa prekryvný súborový systém. Na vrchu je umiestnená záznamová vrstva, ktorá sa odstráni, keď sa nádoba zastaví. To zaisťuje, že pri spustení kontajnera bude mať aplikácia vždy rovnaké prostredie, ktoré sa nedá zmeniť. To zaručuje reprodukovateľnosť prostredia na rôznych hostiteľských OS. Či už ide o Ubuntu alebo CentOS, prostredie bude vždy rovnaké. Okrem toho je kontajner izolovaný od hostiteľa pomocou mechanizmov zabudovaných do jadra Linuxu. Aplikácie v kontajneri nevidia súbory, procesy hostiteľa a susedné kontajnery. Táto izolácia aplikácií od hostiteľského OS poskytuje ďalšiu vrstvu zabezpečenia.
Na správu kontajnerov na hostiteľovi je k dispozícii veľa nástrojov. Najpopulárnejší z nich je Docker. Umožňuje vám zabezpečiť celý životný cyklus kontajnerov. Funguje však iba na jednom hostiteľovi. Ak potrebujete spravovať kontajnery na viacerých hostiteľoch, Docker môže inžinierom urobiť zo života peklo. Preto vznikol Kubernetes.
Dopyt po Kubernetes je práve kvôli schopnosti spravovať skupiny kontajnerov na viacerých hostiteľoch ako nejaký druh jedinej entity. Obľúbenosť systému poskytuje možnosť budovať DevOps alebo Development Operations, v ktorých sa Kubernetes používa na spustenie procesov práve tohto DevOps.
Obrázok 1. Schematické znázornenie fungovania Kubernetes
Plná automatizácia
DevOps je v podstate automatizácia vývojového procesu. Zhruba povedané, vývojári píšu kód, ktorý sa nahráva do úložiska. Potom môže byť tento kód okamžite automaticky zhromaždený do kontajnera so všetkými knižnicami, otestovaný a „zavedený“ do ďalšej fázy - Staging a potom okamžite do výroby.
Spolu s Kubernetes vám DevOps umožňuje automatizovať tento proces tak, aby prebiehal prakticky bez účasti samotných vývojárov. Vďaka tomu je zostavenie výrazne rýchlejšie, pretože vývojár to nemusí robiť na svojom počítači - jednoducho napíše kúsok kódu, vloží kód do úložiska, potom sa spustí kanál, ktorý môže zahŕňať proces budovania, testovania a zavádzania. A to sa deje pri každom odovzdaní, takže testovanie prebieha nepretržite.
Použitie kontajnera zároveň umožňuje mať istotu, že celé prostredie tohto programu bude uvoľnené do výroby presne v takej podobe, v akej bolo testované. To znamená, že nebudú žiadne problémy typu „niektoré verzie boli v teste, iné vo výrobe, ale keď sme ich nainštalovali, všetko padlo“. A keďže dnes máme trend k architektúre mikroservisov, keď namiesto jednej obrovskej aplikácie existujú stovky malých, na ich manuálnu administráciu bude potrebný obrovský štáb zamestnancov. Preto používame Kubernetes.
Plusy, plusy, plusy
Ak hovoríme o výhodách Kubernetes ako platformy, potom má významné výhody z pohľadu riadenia architektúry mikroslužieb.
- Správa viacerých replík. Najdôležitejšia vec je správa kontajnerov na viacerých hostiteľoch. Ešte dôležitejšie je spravovať viaceré repliky aplikácií v kontajneroch ako jednu entitu. Vďaka tomu sa inžinieri nemusia starať o každý jednotlivý kontajner. Ak jeden z kontajnerov zlyhá, Kubernetes to uvidí a znova ho reštartuje.
- Klastrová sieť. Kubernetes má aj takzvanú klastrovú sieť s vlastným adresným priestorom. Vďaka tomu má každý modul svoju adresu. Subpod sa chápe ako minimálna štrukturálna jednotka klastra, v ktorej sa kontajnery priamo spúšťajú. Okrem toho má Kubernetes funkčnosť, ktorá kombinuje nástroj na vyrovnávanie zaťaženia a vyhľadávanie služieb. To vám umožní zbaviť sa manuálnej správy IP adries a delegovať túto úlohu na Kubernetes. A automatické kontroly stavu pomôžu odhaliť problémy a presmerovať prevádzku na pracovné moduly.
- Správa konfigurácie. Pri správe veľkého počtu aplikácií je ťažké spravovať konfiguráciu aplikácií. Na tento účel má Kubernetes špeciálne prostriedky ConfigMap. Umožňujú vám centrálne ukladať konfigurácie a vystavovať ich modulom pri spúšťaní aplikácií. Tento mechanizmus nám umožňuje zaručiť konzistentnosť konfigurácie v najmenej desiatich alebo stovkách replík aplikácií.
- Trvalé objemy. Kontajnery sú vo svojej podstate nemenné a keď sa kontajner zastaví, všetky údaje zapísané do systému súborov budú zničené. Niektoré aplikácie ale ukladajú dáta priamo na disk. Na vyriešenie tohto problému má Kubernetes funkciu správy diskového úložiska - Trvalé zväzky. Tento mechanizmus využíva externé úložisko pre dáta a môže prenášať trvalé úložisko, blok alebo súbor, do kontajnerov. Toto riešenie vám umožňuje ukladať údaje oddelene od pracovníkov, čo ich šetrí, ak sa tí istí pracovníci pokazia.
- Load Balancer. Aj keď v Kubernetes spravujeme abstraktné entity ako Deployment, StatefulSet atď., kontajnery v konečnom dôsledku bežia na bežných virtuálnych strojoch alebo hardvérových serveroch. Nie sú dokonalé a môžu kedykoľvek spadnúť. Kubernetes to uvidí a presmeruje internú prevádzku na iné repliky. Čo však robiť s premávkou, ktorá prichádza zvonka? Ak jednoducho nasmerujete premávku na jedného z pracovníkov, ak dôjde k havárii, služba bude nedostupná. Na vyriešenie tohto problému má Kubernetes služby ako Load Balancer. Sú navrhnuté tak, aby automaticky konfigurovali externý cloud balancer pre všetkých pracovníkov v klastri. Tento externý balancer nasmeruje vonkajšiu premávku na pracovníkov a sám monitoruje ich stav. Ak sa jeden alebo viacerí pracovníci stanú nedostupnými, premávka sa presmeruje na iných. To vám umožňuje vytvárať vysoko dostupné služby pomocou Kubernetes.
Kubernetes funguje najlepšie pri spustení architektúr mikroslužieb. Je možné implementovať systém do klasickej architektúry, ale je to zbytočné. Ak aplikácia nemôže bežať na viacerých replikách, aký je v tom rozdiel - v Kubernetes alebo nie?
Open source Kubernetes
Open source Kubernetes je skvelá vec: Nainštaloval som ho a funguje. Môžete ho nasadiť na vlastné hardvérové servery, na vlastnú infraštruktúru, nainštalovať master a worker, na ktorom budú bežať všetky aplikácie. A čo je najdôležitejšie, toto všetko je zadarmo. Existujú však nuansy.
- Prvým je požiadavka na znalosti a skúsenosti administrátorov a inžinierov, ktorí toto všetko nasadia a podporia. Keďže klient dostáva úplnú slobodu konania v klastri, nesie zodpovednosť za výkon klastra sám. A tu je veľmi ľahké všetko rozbiť.
- Druhým je nedostatok integrácií. Ak spustíte Kubernetes bez populárnej virtualizačnej platformy, nezískate všetky výhody programu. Napríklad pomocou služieb trvalého objemu a vyrovnávania zaťaženia.
Obrázok 2. Architektúra k8s
Kubernetes od predajcu
Integrácia s poskytovateľom cloudu poskytuje dve možnosti:
- Po prvé, osoba môže jednoducho kliknúť na tlačidlo „vytvoriť klaster“ a získať klaster už nakonfigurovaný a pripravený na použitie.
- Po druhé, samotný predajca nainštaluje klaster a nastaví integráciu s cloudom.
Ako sa to deje tu. Inžinier, ktorý spúšťa klaster, určí, koľko pracovníkov potrebuje a s akými parametrami (napríklad 5 pracovníkov, každý s 10 CPU, 16 GB RAM a povedzme 100 GB disku). Potom získa prístup k už vytvorenému zhluku. V tomto prípade sú pracovníci, na ktorých sa záťaž spúšťa, úplne prenesení na klienta, ale celá rovina riadenia zostáva v zodpovednosti dodávateľa (ak je služba poskytovaná podľa modelu riadenej služby).
Táto schéma má však svoje nevýhody. Vzhľadom na to, že rovina správy zostáva u dodávateľa, dodávateľ neposkytuje úplný prístup ku klientovi, čo znižuje flexibilitu pri práci s Kubernetes. Niekedy sa stáva, že klient chce do Kubernetes pridať nejakú špecifickú funkcionalitu, napríklad autentifikáciu cez LDAP, ale konfigurácia manažérskej roviny to neumožňuje.
Obrázok 3. Príklad klastra Kubernetes od cloudového poskytovateľa
Čo si vybrať: open source alebo predajca
Je teda Kubernetes open source alebo špecifický pre dodávateľa? Ak si vezmeme open source Kubernetes, tak si s ním používateľ robí, čo chce. Ale je tu veľká šanca, že si vystrelíte do nohy. S predajcom je to zložitejšie, pretože všetko je premyslené a nakonfigurované pre spoločnosť. Najväčšou nevýhodou open source Kubernetes je požiadavka na špecialistov. S možnosťou predajcu je spoločnosť oslobodená od tejto bolesti hlavy, ale bude sa musieť rozhodnúť, či zaplatí svojim špecialistom alebo predajcovi.
Nuž, klady sú zrejmé, sú známe aj zápory. Jedna vec je nemenná: Kubernetes rieši množstvo problémov automatizáciou správy mnohých kontajnerov. A ktorý si vybrať, open source alebo predajcu – každý sa rozhodne sám.
Článok pripravil Dmitrij Krasnov, vedúci architekt služby Containerum poskytovateľa #CloudMTS
Zdroj: hab.com