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 (). Daniel pracuje ako inštruktor a vývojár softvéru v .
Ak chcete odpoveď na svoju otázku v nasledujúcom príspevku, alebo .
Zmeškali ste predchádzajúce príspevky? .
Ako pripojiť klastre Kubernetes v rôznych dátových centrách?
krátko: , a tiež odporúčam prečítať si o и .
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ď na 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.
etcd je tak citlivý na latenciu, že .
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.
Možnosť 1: klastrová federácia s kubefed
Oficiálna odpoveď od klastra SIG - .
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.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Ako vidíte, zásoba je rozdelená do dvoch klastrov: cluster1 и cluster2.
Prvý klaster poskytuje tri repliky a druhý je nastavený na 5.
Ak potrebujete väčšiu kontrolu nad počtom replík, kubefed2 poskytuje nový objekt ReplicaSchedulingPreference, kde môžu byť repliky vážené:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Štruktúra CRD a API ešte nie sú celkom pripravené a prebiehajú aktívne práce v oficiálnom repozitári projektu.
Sledujte kubefed2, ale nezabudnite, že ešte nie je vhodný na výrobu.
Získajte viac informácií o kubefed2 od v blogu o Kubernetes a in .
Možnosť 2: spojenie klastrov v štýle Booking.com
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.
niečo podobné ako kubefed2.
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:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper je dobrá voľba pre správu viacerých klastrov, ale jeho úzky vzťah s Helm len prekáža.
Čo keby sme všetci prešli z Helma na alebo ?
Zistite viac o Shipper a jeho filozofii na .
Ak sa chcete ponoriť do kódu, .
Možnosť 3: „magické“ zlúčenie klastrov
Kubefed v2 a Shipper pracujú s federáciou klastrov a poskytujú klastrom nové zdroje prostredníctvom vlastnej definície zdrojov.
Ale čo ak nechcete prepísať všetky dodávky, StatefulSets, DaemonSets atď.
Ako zahrnúť existujúci klaster do federácie bez zmeny YAML?
, ktorá sa zaoberá plánovaním záťaže na klastroch.
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 pre 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 .
Ak si chcete prečítať o multi-cluster-plánovači v akcii, Admiralita má — 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:
- je nástroj, ktorý spája prekryvné siete rôznych klastrov Kubernetes.
- Využitie maloobchodného reťazca Target .
- Skúste použiť IPV6 a .
- Môžete použiť napríklad servisnú sieť .
- Cilium, doplnok sieťového rozhrania kontajnerov, ponúka , 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, .
Vašu metódu pridáme do odkazov.
Špeciálne poďakovanie patrí Chrisovi Nesbittovi-Smithovi () a Vincent de Sme () (inžinier spoľahlivosti v ) za prečítanie článku a zdieľanie užitočných informácií o fungovaní federácie.
Zdroj: hab.com