ProHoster > Blog > administratë > Si të lidhni grupet Kubernetes në qendra të ndryshme të të dhënave

Si të lidhni grupet Kubernetes në qendra të ndryshme të të dhënave

Si të lidhni grupet Kubernetes në qendra të ndryshme të të dhënave
Mirë se vini në serinë tonë të Fillimit të Shpejtë të Kubernetes. Kjo është një rubrikë e rregullt me ​​pyetjet më interesante që marrim në internet dhe në trajnimet tona. Përgjigjet e ekspertëve të Kubernetes.

Eksperti i sotëm është Daniel Polenchik (Daniele Polençiç). Daniel punon si instruktor dhe zhvillues softuerësh në Learnk8s.

Nëse dëshironi t'i përgjigjeni pyetjes suaj në postimin tjetër, na kontaktoni me email ose Twitter: @learnk8s.

Keni humbur postimet e mëparshme? I gjeni këtu.

Si të lidhni grupet Kubernetes në qendra të ndryshme të të dhënave?

pak: Kubefed v2 vjen së shpejti, dhe unë rekomandoj gjithashtu të lexoni rreth transportues mallrash и projekt multi-cluster-scheduler.

Shumë shpesh, infrastruktura përsëritet dhe shpërndahet nëpër rajone të ndryshme, veçanërisht në mjedise të kontrolluara.

Nëse një rajon nuk është i disponueshëm, trafiku ridrejtohet në një tjetër për të shmangur ndërprerjet.

Me Kubernetes, ju mund të përdorni një strategji të ngjashme dhe të shpërndani ngarkesat e punës nëpër rajone të ndryshme.

Mund të keni një ose më shumë grupe për ekip, rajon, mjedis ose një kombinim të këtyre elementeve.

Grupet tuaja mund të strehohen në re të ndryshme dhe në ambiente të ndryshme.

Por si e planifikoni infrastrukturën për një shtrirje të tillë gjeografike?
A keni nevojë të krijoni një grup të madh për disa mjedise cloud mbi një rrjet të vetëm?
Apo keni shumë grupime të vogla dhe gjeni një mënyrë për t'i kontrolluar dhe sinkronizuar ato?

Një grup lidershipi

Krijimi i një grupi mbi një rrjet të vetëm nuk është aq i lehtë.

Imagjinoni që keni një aksident, lidhja midis segmenteve të grupimit është e humbur.

Nëse keni një server master, gjysma e burimeve nuk do të mund të marrin komanda të reja sepse nuk do të jenë në gjendje të kontaktojnë masterin.

Dhe në të njëjtën kohë ju keni tabela të vjetra të rrugëtimit (kube-proxy nuk mund të shkarkojë të reja) dhe asnjë pods shtesë (kubelet nuk mund të kërkojë përditësime).

Për t'i bërë gjërat edhe më keq, nëse Kubernetes nuk sheh një nyje, ai e shënon atë si jetim dhe shpërndan podet që mungojnë në nyjet ekzistuese.

Si rezultat, ju keni dy herë më shumë bishtaja.

Nëse krijoni një server master për çdo rajon, do të ketë probleme me algoritmin e konsensusit në bazën e të dhënave etcd. (përafërsisht. ed. — Në fakt, baza e të dhënave etcd nuk duhet domosdoshmërisht të jetë e vendosur në serverët kryesorë. Mund të ekzekutohet në një grup të veçantë serverësh në të njëjtin rajon. Vërtetë, në të njëjtën kohë duke marrë një pikë dështimi të grupit. Por shpejt.)

etjd përdorime algoritmi trappër të negociuar vlerën përpara se ta shkruani atë në disk.
Kjo do të thotë, shumica e rasteve duhet të arrijnë konsensus përpara se shteti të mund të shkruhet në etj.

Nëse vonesa midis instancave etcd rritet në mënyrë dramatike, siç është rasti me tre instanca etcd në rajone të ndryshme, duhet një kohë e gjatë për të negociuar një vlerë dhe për ta shkruar atë në disk.
Kjo reflektohet në kontrollorët Kubernetes.

Menaxherit të kontrolluesit i duhet më shumë kohë për të mësuar rreth ndryshimit dhe për të shkruar përgjigjen në bazën e të dhënave.

Dhe meqenëse nuk ka një kontrollues, por disa, rezulton një reaksion zinxhir dhe i gjithë grupi fillon të punojë shumë ngadalë.

etjd është aq i ndjeshëm ndaj vonesës saqë Dokumentacioni zyrtar rekomandon përdorimin e SSD-ve në vend të disqeve të rregullta.

Aktualisht nuk ka shembuj të mirë të një rrjeti të madh për një grup të vetëm.

Në thelb, komuniteti i zhvilluesve dhe grupi SIG-cluster po përpiqen të kuptojnë se si të orkestrojnë grupimet në të njëjtën mënyrë që Kubernetes orkestron kontejnerët.

Opsioni 1: federata e grupimeve me kubefed

Përgjigje zyrtare nga SIG-cluster - kubefed2, një version i ri i klientit dhe operatorit origjinal të federatës kube.

Për herë të parë, ne u përpoqëm të menaxhonim një koleksion grupesh si një objekt i vetëm duke përdorur mjetin e federatës kube.

Fillimi ishte i mirë, por në fund federata kube nuk u bë kurrë e njohur sepse nuk i mbështeti të gjitha burimet.

Ai mbështeti dërgesat dhe shërbimet e federuara, por jo StatefulSets, për shembull.
Gjithashtu, konfigurimi i federatës u transmetua në formën e shënimeve dhe nuk ishte fleksibël.

Imagjinoni se si mund ta përshkruani ndarjen e kopjeve për çdo grup në një federatë duke përdorur vetëm shënime.

Ishte një rrëmujë e plotë.

SIG-cluster bëri shumë punë pas kubefed v1 dhe vendosi t'i qaset problemit nga një kënd tjetër.

Në vend të shënimeve, ata vendosën të lëshojnë një kontrollues që është i instaluar në grupe. Mund të personalizohet duke përdorur Përkufizimet e Burimeve të Përshtatshme (CRD).

Për çdo burim që do të jetë pjesë e federatës, ju keni një përkufizim të personalizuar CRD me tre seksione:

  • përkufizimi standard i një burimi, për shembull vendosja;
  • seksion placement, ku përcaktoni se si do të shpërndahet burimi në federatë;
  • seksion override, ku për një burim specifik mund të anashkaloni peshën dhe parametrat nga vendosja.

Këtu është një shembull i një dërgese të kombinuar me seksione vendosjeje dhe anashkalimi.

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

Siç mund ta shihni, furnizimi shpërndahet në dy grupime: cluster1 и cluster2.

Grupi i parë siguron tre kopje, dhe i dyti është vendosur në 5.

Nëse keni nevojë për më shumë kontroll mbi numrin e kopjeve, kubefed2 ofron një objekt të ri ReplicaSchedulingPreference ku kopjet mund të peshohen:

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

Struktura CRD dhe API nuk janë ende gati, dhe puna aktive është duke u zhvilluar në depon e projektit zyrtar.

Mbani një sy në kubefed2, por mbani mend se nuk është ende i përshtatshëm për prodhim.

Mësoni më shumë rreth kubefed2 nga artikull zyrtar rreth kubefed2 në blogun rreth Kubernetes dhe në depoja zyrtare e projektit kubefed.

Opsioni 2: kombinimi i grupimeve në stilin e Booking.com

Zhvilluesit e Booking.com nuk punuan në kubefed v2, por ata dolën me Shipper - një operator për shpërndarjen në disa grupe, në disa rajone dhe në disa re.

transportues mallrash disi e ngjashme me kubefed2.

Të dy mjetet ju lejojnë të personalizoni strategjinë tuaj të vendosjes me shumë grupime (cilat grupe përdoren dhe sa kopje kanë).

Por Qëllimi i dërguesit është të zvogëlojë rrezikun e gabimeve gjatë dorëzimit.

Në Transportuesi, mund të përcaktoni një sërë hapash që përshkruajnë ndarjen e kopjeve midis vendosjes së mëparshme dhe aktuale dhe vëllimit të trafikut në hyrje.

Kur shtyni një burim në një grup, kontrolluesi i dërguesit e shpërndan gradualisht atë ndryshim në të gjitha grupimet e bashkuara.

Gjithashtu, dërguesi është shumë i kufizuar.

Për shembull, ai pranon diagramet e timonit si hyrje dhe nuk mbështet burimet e vaniljes.
Në terma të përgjithshëm, Transportuesi funksionon si kjo.

Në vend të shpërndarjes standarde, ju duhet të krijoni një burim aplikacioni që përfshin një tabelë Helm:

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

Transportuesi është një opsion i mirë për menaxhimin e grupimeve të shumta, por marrëdhënia e tij e ngushtë me Helm vetëm pengon.

Po sikur të gjithë të kalojmë nga Helm në personalizoj ose Kapitan?

Zbuloni më shumë rreth Shipper dhe filozofisë së tij në kjo deklaratë zyrtare për shtyp.

Nëse dëshironi të gërmoni në kodin, shkoni te depoja zyrtare e projektit.

Opsioni 3: bashkimi i grupimeve "magjike".

Kubefed v2 dhe Shipper punojnë me federatën e grupimeve, duke ofruar burime të reja për grupimet përmes përcaktimit të burimeve me porosi.

Por, çka nëse nuk dëshironi të rishkruani të gjitha dërgesat, StatefulSets, DaemonSets, etj. për t'u bashkuar?

Si të përfshihet një grup ekzistues në një federatë pa ndryshuar YAML?

multi-cluster-scheduler është një projekt Admirality, i cili merret me planifikimin e ngarkesave të punës në grupe.

Por në vend që të krijohet një mënyrë e re për të bashkëvepruar me grupin dhe për të mbështjellë burimet në përkufizime të personalizuara, programuesi me shumë grupime është i integruar në ciklin standard të jetës së Kubernetes dhe përgjon të gjitha thirrjet që krijojnë pods.

Çdo pod i krijuar zëvendësohet menjëherë me një bedel.

përdor multi-cluster-scheduler webhooks për modifikimin e aksesitpër të përgjuar telefonatën dhe për të krijuar një pod të papunë.

Pjesa origjinale kalon nëpër një cikël tjetër planifikimi ku, pas votimit të të gjithë federatës, merret një vendim për vendosjen.

Së fundi, pod i dorëzohet grupit të synuar.

Si rezultat, ju keni një pod shtesë që nuk bën asgjë, thjesht zë hapësirë.

Avantazhi është se nuk ju është dashur të shkruani burime të reja për të kombinuar furnizimet.

Çdo burim që krijon një pod është automatikisht gati për t'u bashkuar.

Kjo është interesante, sepse papritmas ju keni furnizime të shpërndara në disa rajone dhe as nuk e keni vënë re. Sidoqoftë, kjo është mjaft e rrezikshme, sepse gjithçka këtu mbështetet në magji.

Por ndërsa Shipper po përpiqet të zbusë më së shumti ndikimin e dërgesave, programuesi me shumë grupime trajton detyra më të përgjithshme dhe ndoshta është më i përshtatshëm për punët e grupeve.

Nuk ka një mekanizëm të avancuar gradual të shpërndarjes.

Më shumë rreth planifikuesit me shumë grupime mund të gjenden në faqe zyrtare e depove.

Nëse dëshironi të lexoni rreth planifikuesit me shumë grupime në veprim, Admiralty ka rast përdorimi interesant me Argo — rrjedhat e punës, ngjarjet, CI dhe CD Kubernetes.

Mjete dhe zgjidhje të tjera

Lidhja dhe menaxhimi i grupeve të shumta është një detyrë komplekse dhe nuk ka zgjidhje universale.

Nëse dëshironi ta eksploroni më tej këtë temë, këtu janë disa burime:

Kaq për sot

Faleminderit që lexuat deri në fund!

Nëse dini si të lidhni grupe të shumta në mënyrë më efikase, na thuaj.

Ne do të shtojmë metodën tuaj në lidhje.

Falenderime të veçanta për Chris Nesbitt-Smith (Chris Nesbitt-Smith) dhe Vincent de Sme (Vincent De Smet) (inxhinier i besueshmërisë në swatmobile.io) për të lexuar artikullin dhe për të ndarë informacione të dobishme për mënyrën se si funksionon federata.

Burimi: www.habr.com

Shto një koment