Ako pripojiť klastre Kubernetes v rôznych dátových centrách
Vitajte v našej sérii Kubernetes Quick Start. Toto je pravidelná rubrika s najzaujímavejšími otázkami, ktoré dostávame online a na našich školeniach. Odpovedá expert Kubernetes.
Dnešným odborníkom je Daniel Polenchik (Daniele Polencic). Daniel pracuje ako inštruktor a vývojár softvéru v Learnk8s.
Pomerne často sa infraštruktúra replikuje a distribuuje v rôznych regiónoch, najmä v kontrolovaných prostrediach.
Ak je jeden región nedostupný, premávka sa presmeruje do iného, aby sa predišlo prerušeniam.
S Kubernetes môžete použiť podobnú stratégiu a rozložiť pracovné zaťaženie v rôznych regiónoch.
Môžete mať jeden alebo viac klastrov na tím, región, prostredie alebo kombináciu týchto prvkov.
Vaše klastre môžu byť hosťované v rôznych cloudoch a lokálnych priestoroch.
Ako však plánujete infraštruktúru pre takéto geografické rozšírenie?
Potrebujete vytvoriť jeden veľký klaster pre niekoľko cloudových prostredí cez jednu sieť?
Alebo máte veľa malých klastrov a nájdete spôsob, ako ich ovládať a synchronizovať?
Jeden vodcovský klaster
Vytvorenie jedného klastra cez jednu sieť nie je také jednoduché.
Predstavte si, že máte nehodu, spojenie medzi segmentmi klastra sa stratí.
Ak máte jeden hlavný server, polovica prostriedkov nebude môcť prijímať nové príkazy, pretože nebudú môcť kontaktovať hlavný server.
A zároveň máte staré smerovacie tabuľky (kube-proxy nemôže stiahnuť nové) a žiadne ďalšie moduly (kubelet nemôže požadovať aktualizácie).
Aby toho nebolo málo, ak Kubernetes nevidí uzol, označí ho ako osamotený a rozdelí chýbajúce pody do existujúcich uzlov.
Výsledkom je, že máte dvakrát toľko strukov.
Ak vytvoríte jeden hlavný server pre každý región, vyskytnú sa problémy s konsenzuálnym algoritmom v databáze etcd. (približne. vyd. — Databáza etcd sa v skutočnosti nemusí nevyhnutne nachádzať na hlavných serveroch. Môže byť spustený na samostatnej skupine serverov v rovnakom regióne. Je pravda, že zároveň získava bod zlyhania klastra. Ale rýchlo.)
atď raftový algoritmusna dohodnutie hodnoty pred jej zápisom na disk.
To znamená, že väčšina inštancií musí dosiahnuť konsenzus predtým, ako môže byť štát napísaný na etcd.
Ak sa latencia medzi inštanciami etcd dramaticky zvýši, ako je to v prípade troch inštancií etcd v rôznych regiónoch, trvá dlho, kým sa dohodne hodnota a zapíše sa na disk.
To sa odráža v ovládačoch Kubernetes.
Správca radiča potrebuje viac času, aby sa dozvedel o zmene a zapísal odpoveď do databázy.
A keďže neexistuje jeden ovládač, ale niekoľko, dôjde k reťazovej reakcii a celý klaster začne pracovať veľmi pomaly.
V súčasnosti neexistujú žiadne dobré príklady veľkej siete pre jeden klaster.
V podstate sa vývojárska komunita a skupina klastrov SIG snažia zistiť, ako organizovať klastre rovnakým spôsobom, ako Kubernetes organizuje kontajnery.
Prvýkrát sme sa pokúsili spravovať kolekciu klastrov ako jeden objekt pomocou nástroja kube federation.
Začiatok bol dobrý, ale nakoniec sa federácia kube nikdy nestala populárnou, pretože nepodporovala všetky zdroje.
Podporoval federatívne dodávky a služby, ale napríklad nie StatefulSets.
Konfigurácia federácie sa tiež prenášala vo forme anotácií a nebola flexibilná.
Predstavte si, ako by ste mohli opísať rozdelenie repliky pre každý klaster vo federácii iba pomocou anotácií.
Bol to úplný chaos.
SIG-cluster urobil po kubefed v1 veľa práce a rozhodol sa pristupovať k problému z iného uhla.
Namiesto anotácií sa rozhodli vydať ovládač, ktorý je nainštalovaný na klastroch. Dá sa prispôsobiť pomocou vlastných definícií zdrojov (CRD).
Pre každý zdroj, ktorý bude súčasťou federácie, máte vlastnú definíciu CRD s tromi sekciami:
štandardná definícia zdroja, napríklad nasadenie;
časť placement, kde definujete, ako bude zdroj distribuovaný vo federácii;
časť override, kde pre konkrétny zdroj môžete prepísať váhu a parametre z umiestnenia.
Tu je príklad kombinovanej dodávky s umiestnením a sekciou prepísania.
Vývojári Booking.com nepracovali na kubefed v2, ale prišli s Shipperom – operátorom na doručovanie na viacerých klastroch, vo viacerých regiónoch a vo viacerých cloudoch.
Oba nástroje vám umožňujú prispôsobiť stratégiu nasadenia viacerých klastrov (ktoré klastre sa používajú a koľko replík majú).
Ale Cieľom odosielateľa je znížiť riziko chýb pri doručovaní.
V odosielateľovi môžete definovať sériu krokov, ktoré popisujú rozdelenie replík medzi predchádzajúce a aktuálne nasadenie a objem prichádzajúcej prevádzky.
Keď vložíte prostriedok do klastra, radič odosielateľa postupne zavádza túto zmenu do všetkých spojených klastrov.
Odosielateľ je tiež veľmi obmedzený.
Napríklad, ako vstup prijíma tabuľky kormidla a nepodporuje vanilkové zdroje.
Vo všeobecnosti Shipper funguje takto.
Namiesto štandardného doručovania musíte vytvoriť aplikačný zdroj, ktorý obsahuje Helmov diagram:
Ale namiesto toho, aby prišiel s novým spôsobom interakcie s klastrom a zabalením zdrojov do vlastných definícií, plánovač viacerých klastrov je zabudovaný do štandardného životného cyklu Kubernetes a zachytáva všetky hovory, ktoré vytvárajú moduly.
Každý vytvorený lusk je okamžite nahradený figurínou.
použitie plánovača s viacerými klastrami webhooky na úpravu prístupupre zachytenie hovoru a vytvorenie nečinného fiktívneho modulu.
Pôvodný modul prechádza ďalším plánovacím cyklom, kde sa po prieskume celej federácie rozhodne o umiestnení.
Nakoniec je modul doručený do cieľového klastra.
Výsledkom je, že máte extra modul, ktorý nič nerobí, len zaberá miesto.
Výhodou je, že ste nemuseli písať nové zdroje na kombinovanie zásob.
Každý zdroj, ktorý vytvorí pod, je automaticky pripravený na zlúčenie.
To je zaujímavé, pretože zrazu máte zásoby rozmiestnené po niekoľkých regiónoch a ani ste si to nevšimli. To je však dosť riskantné, pretože tu všetko spočíva na mágii.
No zatiaľ čo sa Shipper snaží väčšinou zmierniť dopady dodávok, multi-cluster-plánovač zvláda všeobecnejšie úlohy a je možno vhodnejší pre dávkové úlohy.
Nemá pokročilý mechanizmus postupného dodávania.
Viac o multi-cluster-plánovači nájdete na oficiálna stránka úložiska.
Ak si chcete prečítať o multi-cluster-plánovači v akcii, Admiralita má zaujímavý prípad použitia s Argo — pracovné postupy, udalosti, CI a CD Kubernetes.
Ďalšie nástroje a riešenia
Prepojenie a správa viacerých klastrov je zložitá úloha a neexistuje univerzálne riešenie.
Ak by ste chceli túto tému ďalej preskúmať, tu je niekoľko zdrojov:
Submariner od Ranchera je nástroj, ktorý spája prekryvné siete rôznych klastrov Kubernetes.
Cilium, doplnok sieťového rozhrania kontajnerov, ponúka klastrová sieťová funkcia, ktorý umožňuje kombinovať niekoľko klastrov
To je na dnes všetko
Ďakujeme za prečítanie až do konca!
Ak viete, ako efektívnejšie prepojiť viacero klastrov, povedz nám.
Vašu metódu pridáme do odkazov.
Špeciálne poďakovanie patrí Chrisovi Nesbittovi-Smithovi (Chris Nesbitt-Smith) a Vincent de Sme (Vincent De Smet) (inžinier spoľahlivosti v swatmobile.io) za prečítanie článku a zdieľanie užitočných informácií o fungovaní federácie.