🥇Ako spojiť clustre Kubernetes v rôznych dátových centrách

Vitajte v sérii krátkych príručiek o Kubernetes. Toto je pravidelný stĺpec s najzaujímavejšími otázkami, ktoré dostávame online a na našich školeniach. Odpovedá expert na Kubernetes.

Dnešný expert — Daniele Polencic (Daniele Polencic). Daniele pracuje ako inštruktor a softvérový vývojár v Learnk8s.

Ak chcete získať odpoveď na svoju otázku v nasledujúcom príspevku, kontaktujte nás e-mailom alebo na Twitteri: @learnk8s.

Premeškali ste predchádzajúce príspevky? Hľadajte ich tu.

Ako spojiť klastre Kubernetes v rôznych dátových centrách?

Stručne: čoskoro vyjde Kubefed v2, a odporúčam prečítať si o Shipper a projekte multi-cluster-scheduler..

Často sa infraštruktúra replikovaných a distribuuje do rôznych regiónov, najmä v kontrolovaných prostrediach.

Ak je jeden región nedostupný, traffic sa presmeruje do iného, aby sa predišlo prerušením.

S Kubernetes môžete použiť podobnú stratégiu a distribuovať pracovné záťaže do rôznych regiónov.

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ť umiestnené v rôznych cloudových službách a v lokálnom prostredí.

Ako naplánovať infraštruktúru pre takú geografickú distribúciu?
Je potrebné vytvoriť jeden veľký klaster na niekoľkých cloudových službách cez jednu sieť?
Alebo zriadiť množstvo malých klastrov a nájsť spôsob, ako ich kontrolovať a synchronizovať?

Jeden riadiaci klaster

Vytvoriť jeden klaster cez jednu sieť nie je také jednoduché.

Predstavte si, že máte haváriu, stratené spojenie medzi segmentmi klastru.

Ak máte jeden master server, polovica zdrojov nebude schopná prijímať nové príkazy, pretože sa nemôže spojiť s masterom.

A pritom máte staré smerovacie tabuľky (kube-proxy nedokáže načítať nové) a žiadne dodatočné pod'y (kubelet nemôže požiadať o aktualizácie).

Čo je ešte horšie, ak Kubernetes nevidí uzol, označí ho ako stratený a prerozdeľuje chýbajúce pod'y na existujúce uzly.

V dôsledku toho máte dvakrát viac pod'ov.

Ak by ste mali jeden master server pre každý región, vzniknú problémy s algoritmom dosahovania konsenzu v databáze etcd.pozn. red. — V skutočnosti nemusí byť databáza etcd umiestnená na master serveroch. Môže byť spustená na samostatnej skupine serverov v jednom regióne, ale to spôsobuje bod zlyhania klastra. Naopak, je to rýchle.)

etcd používa algoritmus raft, aby pred zapisovaním hodnoty na disk dosiahol konsenzus.
To znamená, že väčšina inštancií musí dosiahnuť konsenzus predtým, než sa stav zapíše do etcd.

Ak sa oneskorenie medzi inštanciami etcd výrazne zvýši, ako v prípade troch inštancií etcd v rôznych regiónoch, trvá dlhý čas, kým sa hodnota zosúladí a zapíše na disk.
To sa odráža aj na kontroléroch Kubernetes.

Kontrolórovi trvá dlhšie, kým sa dozvie o zmene a zapíše odpoveď do databázy.

A keďže kontrolórov nie je len niekoľko, vzniká reťazová reakcia a celý klaster začne fungovať veľmi pomaly..

etcd je tak citlivý na oneskorenie, že v oficiálnej dokumentácii sa odporúča používať SSD namiesto bežných pevných diskov..

V súčasnosti neexistujú dobré príklady veľkej siete pre jeden klaster.

Hlavne komunita vývojárov a skupina SIG-cluster sa snažia pochopiť, ako orchestrácie klastrov rovnako ako Kubernetes orchestruje kontajnery.

Možnosť 1: federácia klastrov s kubefed.

Oficiálna odpoveď od SIG-cluster je, kubefed2, nová verzia pôvodného klienta a operátora kube federation..

Prvýkrát sa o správu zbierky klastrov ako o jedinom objekte pokúsili pomocou nástroja kube federation.

Začiatok bol dobrý, ale nakoniec sa kube federation nestal populárnym, pretože nepodporoval všetky zdroje.

Podporoval kombinované dodávky a služby, ale napríklad nie StatefulSets.
A navyše, konfigurácia federácie bola prenášaná vo forme anotácií a bola málo flexibilná.

Predstavte si, ako by sa dalo opísať rozdelenie replik pre každý klaster vo federácii pomocou jedných anotácií.

Vytvoril sa úplný chaos.

SIG-cluster vykonali veľkú prácu po kube fed v1 a rozhodli sa pristúpiť k problému z inej strany.

Namiesto anotácií sa rozhodli vydávať kontrolér, ktorý sa inštaluje na klastroch. Môže sa konfigurovať pomocou používateľských definícií zdrojov (Custom Resource Definition, CRD).

Pre každý zdroj, ktorý bude súčasťou federácie, máte vlastné definovanie CRD pozostávajúce z troch častí:

štandardná definícia zdroja, napríklad deployment;
sekcia placement, kde určujete, ako bude zdroj distribuovaný v federácii;
sekcia override, kde môžete pre konkrétny zdroj predefinovať váhu a parametre z placement.

Tu je príklad kombinovanej dodávky s časťami placement a override.

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: 5

Ako vidíte, dodávka je rozdelená do dvoch klastrov: cluster1 a cluster2.

Prvý klaster dodáva tri repliky, zatiaľ čo druhému je nastavená hodnota 5.

Ak potrebujete väčšiu kontrolu nad počtom replik, kubefed2 poskytuje nový objekt ReplicaSchedulingPreference, kde je možné repliky rozdeliť podľa váhy:

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ú úplne pripravené a v oficiálnom repozitári projektu sa aktívne pracuje.

Sledujte kubefed2, ale pamätajte, že na produkčné prostredie zatiaľ nie je vhodný.

Zistite viac o kubefed2 z oficiálneho článku o kubefed2 v blogu o Kubernetes a v oficiálnom repozitári projektu kubefed.

Varianta 2: spájanie klastrov v štýle Booking.com

Vývojári Booking.com sa nezameriavali na kubefed v2, ale vymysleli Shipper — operátor pre dodávky v niekoľkých klastroch, v niekoľkých regiónoch a v niekoľkých облаках.

Shipper s niečím podobným ako kubefed2.

Oba nástroje umožňujú nastaviť stratégiu nasadenia v niekoľkých klastroch (ktoré klastre sa používajú a koľko majú replik).

Ale úlohou Shipper je znížiť riziko chýb pri dodávke.

V Shipper môžete definovať sériu krokov, ktoré popisujú rozdelenie replik medzi predchádzajúcim a aktuálnym deploymentom a objem prichádzajúcej prevádzky.

Keď odošlete zdroj do klastru, kontrolér Shipper krok za krokom nasadzuje túto zmenu do všetkých zlúčených klastrov.

A navyše je Shipper veľmi obmedzený.

Napríklad, prijíma Helm chart ako vstupné údaje. a nepodporuje vanilla zdroje.
V skratke, Shipper funguje nasledovne.

Namiesto štandardnej dodávky je potrebné vytvoriť zdroj aplikácie, ktorý zahŕňa Helm chart:

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: 3

Shipper je dobrá voľba na správu viacerých klastrov, ale jeho úzka väzba na Helm to len komplikuje.

A čo ak všetci prejdeme z Helm na kustomize alebo kapitan?

Zistite viac o Shipper a jeho filozofii v tento oficiálny tlačový materiál.

Ak sa chcete ponoriť do kódu, navštívte oficiálny repozitár projektu.

Možnosť 3: „magické“ zjednotenie klastrov

Kubefed v2 a Shipper fungujú s federáciou klastrov, poskytujúc klastrom nové zdroje prostredníctvom používateľsky definovaných zdrojov.

Ale čo ak nechcete prepísať všetky dodávky, StatefulSets, DaemonSets atď. na zjednotenie?

Ako zapojiť existujúci klaster do federácie bez zmeny YAML?

multi-cluster-scheduler je projekt Admirality, ktorý sa zaoberá pracovnými záťažami plánovania v klastri.

Ale namiesto toho, aby sa vytváral nový spôsob interakcie s klastrom a obalil zdroje do používateľských definícií, multi-cluster-scheduler sa integruje do štandardného životného cyklu Kubernetes a zachytáva všetky volania, ktoré vytvárajú pod.

Každý vytvorený pod sa okamžite nahrádza prázdnou stub.

multi-cluster-scheduler používa web-hooks na modifikáciu prístupu, aby zachytil volanie a vytvoril bezdôvodný stub pod.

Pôvodný pod prechádza ďalším plánovacím cyklom, kde sa po vyžiadaniu celej federácie rozhoduje o umiestnení.

Nakoniec sa pod dodáva do cieľového klastru.

V konečnom dôsledku máte nadbytočný pod, ktorý nič nerobí, len zaberá miesto.

Výhodou je, že ste nemuseli písať nové zdroje na zjednotenie dodávok.

Každý zdroj, ktorý vytvára pod, je automaticky pripravený na zjednotenie.

Je to zaujímavé, pretože sa vám zrazu objavia dodávky rozložené po niekoľkých regiónoch, a vy si toho ani nevšimnete. Napriek tomu je to dosť riskantné, pretože všetko tu závisí na mágii.

Ale ak sa Shipper snaží najmä zmierniť následky dodávok, multi-cluster-scheduler vykonáva všeobecnejšie úlohy a možno je lepšie vhodný na dávkové úlohy.

Nemá pokročilý mechanizmus postupných dodávok.

Viac o multi-cluster-scheduler sa môžete dozvedieť na stránke oficiálneho repozitára..

Ak chcete čítať o multi-cluster-scheduler v praxi, Admiralty má zaujímavý prípad aplikácie s Argo — pracovnými tokmi, udalosťami, CI a CD Kubernetes.

Ďalšie nástroje a riešenia

Spojenie viacerých klastrov a ich správa je zložitá úloha, univerzálne riešenie neexistuje.

Ak chcete podrobnejšie preskúmať túto tému, tu je niekoľko zdrojov:

Submariner od Rancher — nástroj, ktorý spája overlay siete rôznych klastrov Kubernetes.
Retailová sieť Target používa Unimatrix v kombinácii so Spinnakerom, aby orchestrila nasadenie na viacerých klastroch..
Skúste použiť IPV6 a jednu sieť v niekoľkých regiónoch..
Môžete použiť service mesh, napríklad Istio na prepojenie viacerých klastrov..
Cilium, plugin sieťového rozhrania kontajnerov, ponúka funkciu cluster mesh, ktorá umožňuje kombinovať niekoľko klastrov.

To je všetko na dnes.

Ďakujem, že ste to dočítali do konca!

Ak viete, ako efektívnejšie spojiť viaceré clustre, povedzte nám to..

Pridáme váš spôsob k odkazom.

Osobitná vďaka Chrisovi Nesbittovi-Smithovi (Chris Nesbitt-Smith) a Vincentovi De Smetovi (Vincent De Smet) (inžinierovi dôveryhodnosti na swatmobile.io) za to, že si prečítali článok a podelili sa o užitočné informácie o tom, ako funguje federácia.

Zdroj: habr.com