ProHoster > Blog > Administrimi > Si si lidhin klasterat Kubernetes në qendra të ndryshme të të dhënave

Si si lidhin klasterat Kubernetes në qendra të ndryshme të të dhënave

Si si lidhin klasterat Kubernetes në qendra të ndryshme të të dhënave
Mirë se vini në serinë e udhëzimeve të shkurtra për Kubernetes. Ky është një kolumnë e rregullt me pyetje më interesante që marrim online dhe në trajnimet tona. Përgjigjet ekspert i Kubernetes.

Eksperti i sotëm është Daniel Polencic (Daniele Polencic). Daniel punon si instruktor dhe zhvillues softueri në Learnk8s.

Nëse dëshironi të merrni përgjigje për pyetjen tuaj në postimin e ardhshëm, na kontaktoni përmes email-it ose në Twitter: @learnk8s.

E humbët postimet e mëparshme? Shihni ato këtu.

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

Shkurt: kubefed v2 do të dalë së shpejti, dhe gjithashtu rekomandoj të lexoni për Shipper dhe projekti multi-cluster-scheduler.

Shpesh, infrastruktura riprodhohet dhe shpërndahet në rajone të ndryshme, veçanërisht në mjedise të kontrolluara.

Nëse një rajon nuk është i qasshëm, trafiku ridrejtohet në një tjetër për të shmangur ndalesat.

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

Mund të keni një ose disa klastera për ekipin, rajonin, mjedisin, ose për një kombinim të këtyre elementeve.

Klasterët tuaj mund të vendosen në vende të ndryshme cloud dhe në ambient lokal.

Por si të planifikoni infrastrukturën për një shpërndarje të tillë gjeografike?
A duhet të krijoni një klaster të madh mbi disa cloud në një rrjet të vetëm?
Ose të krijoni shumë klasterë të vegjël dhe të gjeni një mënyrë për t'i kontrolluar dhe sinkronizuar ato?

Një klaster udhëheqës

Të krijoni një klaster mbi një rrjet të vetëm nuk është aq e lehtë.

Imagjinoni, keni një katastrofë, është humbur lidhja midis segmenteve të klasterit.

Nëse keni një server master, gjysma e burimeve nuk do të mund të merrni komanda të reja, sepse nuk do të arrijë të lidhët me masterin.

Dhe me këtë, keni tabela të vjetra të rrugëve (kube-proxy nuk mund të ngarkojë të rejat) dhe nuk ka pod të tjera (kubelet nuk mund të kërkojë azhurnime).

Ajo që është më keq, nëse Kubernetes nuk sheh një nyje, ai e etiketon atë si të humbur dhe shpërndan podët e munguar në nyjat ekzistuese.

Si rezultat, keni dyfish pod-Ă«sh.

NĂ«se bĂ«ni nga njĂ« server master pĂ«r çdo rajon, do tĂ« ketĂ« probleme me algoritmin pĂ«r arritjen e konsensusit nĂ« bazĂ«n e tĂ« dhĂ«nave etcd.shĂ«n. red. — NĂ« fakt, baza e tĂ« dhĂ«nave etcd nuk duhet domosdoshmĂ«risht tĂ« ndodhet nĂ« serverat master. Ajo mund tĂ« ekzekutohet nĂ« njĂ« grup tĂ« veçantĂ« serverĂ«sh nĂ« njĂ« rajon. MegjithatĂ«, kĂ«tĂ« bĂ«jmĂ« me njĂ« pikĂ« dĂ«shtimi tĂ« klashtĂ«r. Por Ă«shtĂ« e shpejtĂ«.)

etcd përdor algoritmin raft, për të arritur një marrëveshje mbi vlerën, para se ta shkruajë atë në disk.
Kështu, shumica e instancave duhet të arrijnë konsensusin, përpara se gjendja të mund të shkruhet në etcd.

Nëse vonesa midis instancave etcd rritet ndjeshëm, si në rastin e tre instancave etcd në rajone të ndryshme, merr shumë kohë për të arritur një marrëveshje mbi vlerën dhe për ta shkruar atë në disk.
Kjo ndikon edhe te kontrolluesit e Kubernetes.

Menaxherit të kontrolluesve iu nevojitet më shumë kohë për të mësuar mbi ndryshimin dhe për të shkruar përgjigjen në bazën e të dhënave.

Dhe pasi që kontrolluesit nuk janë vetëm një, por disa, atëherë ndodh një reaksion zinxhir, dhe i gjithë klashtëri fillon të punojë shumë ngadalë..

etcd është aq i ndjeshëm ndaj vonesës, saqë në dokumentacionin zyrtar rekomandohet të përdoren SSD në vend të disqeve të zakonshme..

Aktualisht nuk ka shembuj të mirë të një rrjeti të madh për një klashtër.

Në përgjithësi, komuniteti i zhvilluesve dhe grupi SIG-cluster po përpiqen të kuptojnë se si të orkestrojnë klasterët ashtu si Kubernetes orkestrojnë kontejnerët.

Opsioni 1: federata e klasterëve me kubefed

PĂ«rgjigjja zyrtare nga SIG-cluster — kubefed2, versioni i ri i klientit burimor dhe operatorit tĂ« federatĂ«s kube.

Për herë të parë, për të menaxhuar një koleksion klasterësh si një objekt të vetëm u provua të përdorej mjeti kube federation.

Fillimi ishte i mirë, por në fund kube federation nuk u bë popullor, sepse mbështeste jo të gjitha burimet.

Ai mbështeti çmimet e bashkuara dhe shërbimet, por, për shembull, jo StatefulSets.
Po ashtu, konfigurimi i federatës ishte i transmetuar në formë anotacionesh dhe nuk ishte fleksibël.

Imagjinoni se si mund të përshkruhet ndarja e replicave për çdo klaster në federatë duke përdorur vetëm anotacione.

Kështu u krijua një kaos i plotë.

SIG-cluster bëri një punë të madhe pas kubefed v1 dhe vendosi të qaset problemit nga një këndvështrim tjetër.

Në vend të anotacioneve, ata vendosën të lëshonin një kontrollues që instalohet në klasterët. Ai mund të konfigurohet me definicionet e burimeve të personalizuara (Custom Resource Definition, CRD).

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

  • pĂ«rcaktimi standard i burimit, si p.sh. deploy;
  • seksioni placement, ku definohet si do tĂ« shpĂ«rndahet burimi nĂ« federatĂ«;
  • seksioni override, ku pĂ«r njĂ« burim tĂ« caktuar mund tĂ« rishkruhen pesha dhe parametrat nga placement.

Ja një shembull i një dërgesë të kombinuar me seksionet placement dhe 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

Siç e shihni, dërgesa është shpërndarë në dy klastera: cluster1 dhe cluster2.

Klusteri i parë ofron tre replika, ndërsa për të dytin është e caktuar vlera 5.

Nëse ju nevojitet më shumë kontroll mbi numrin e replika, kubefed2 ofron një objekt të ri ReplicaSchedulingPreference, ku replika mund të shpërndahen sipas peshe:

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 ende nuk është plotësisht e gatshme, dhe në depozitat zyrtare të projektit po bëhet punë aktive.

MBani nën breg kubefed2, por mërzituni që për mjedisin e punës, ai ende nuk është i aftë.

Mësoni më shumë për kubefed2 nga artikulli zyrtar mbi kubefed2 në blogun e Kubernetes dhe në depozitën zyrtare të projektit kubefed.

Opsioni 2: bashkimi i klasterëve në stilin Booking.com

Zhvilluesit e Booking.com nuk u morën me kubefed v2, por krijuan Shipper - një operator për shpërndarjen në shumë klasterë, në shumë rajone dhe në shumë cloud.

Shipper i ngjashëm me kubefed2.

Të dy mjetet lejojnë konfigurimin e strategjisë së shpërndarjes në shumë klasterë (cilat klasterë përdoreshin dhe sa replika kanë).

Por objektivi i Shipper është të ulë rrezikun e gabimeve gjatë shpërndarjes.

Në Shipper, mund të përcaktoni një sërë hapash që përshkruajnë ndarjen e replikave midis shpërndarjes së mëparshme dhe asaj aktuale dhe volumit të trafikut që po hyn.

Kur dërgoni një burim në një klaster, kontrolluesi Shipper shpërndan hapat për të bërë këtë ndryshim në të gjitha klasterët e bashkuar.

Po, Shipper është shumë i kufizuar.

Për shembull, Ai pranon Helm charts si input. dhe nuk mbështet burimet vanilla.
Në përgjithësi, Shipper funksionon si më poshtë.

Në vend të shpërndarjes standarde, duhet të krijoni një burim aplikacioni që përfshin 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 është një opsion i mirë për menaxhimin e disa klasterëve, por lidhja e tij e ngushtë me Helm e pengon atë.

Po ndoshta të gjithë do të kalojmë nga Helm në kustomize ose kapitan?

Mësoni më shumë për Shipper dhe filozofinë e tij në këtë njoftim zyrtar për shtyp.

Nëse dëshironi të hulumtoni kodin, shkoni në depot zyrtare të projektit.

Opsioni 3: „magjike” bashkimi i klasterĂ«ve

Kubefed v2 dhe Shipper punojnë me federatën e klasterëve, duke u ofruar klasterëve burime të reja përmes përcaktimit të burimeve nga përdoruesi.

Por një moment, mos doni të rishkruani të gjitha ofrimet, StatefulSets, DaemonSets, etj. për bashkimin?

Si të përfshini një klasër ekzistues në federatë pa ndryshuar YAML?

multi-cluster-scheduler është një projekt Admirality, i cili merret me ngarkesat e punës të planifikimit në klastra.

Por përveç se të krijoni një mënyrë të re për të ndikuar në klasër dhe për të mbështjellur burimet në definita të personalizuara, multi-cluster-scheduler integrohet në ciklin standard të jetës Kubernetes dhe ndërhyn në të gjitha thirrjet që krijojnë podë.

Çdo pod qĂ« krijohet menjĂ«herĂ« zĂ«vendĂ«sohet me njĂ« pod tĂ« zbrazĂ«t.

multi-cluster-scheduler përdor web-hooks për të modifikuar qasjen, për të kapur thirrjen dhe për të krijuar një pod të zbrazët.

Pod origjinal kalon përmes një cikli tjetër planifikimi, ku pas anketimit të gjithë federatës merret një vendim për vendosjen.

Më në fund, pod dërgohet në klastrin e synuar.

Si rezultat, keni një pod të tepërt që nuk bën asgjë, thjesht zë hapësirë.

Avantazhi është që nuk keni pasur nevojë të shkruani burime të reja për bashkimin e ofrimeve.

Çdo burim qĂ« krijon podĂ« Ă«shtĂ« automatikisht i gatshĂ«m pĂ«r bashkim.

Kjo është interesante, pasi ndodhin furnizime të shpërndara në disa rajone, dhe ju nuk e keni vënë re. Megjithatë, është mjaft e rrezikshme, pasi këtu gjithçka mbështetet në magji.

Por nëse Shipper përpiqet kryesisht të zbusë pasojat e furnizimeve, multi-cluster-scheduler kryen detyra më të përgjithshme dhe ndoshta është më i përshtatshëm për detyrat e paketave.

Ai nuk ka një mekanizëm të avancuar të furnizimeve të avancuara.

Më shumë rreth multi-cluster-scheduler mund të mësoni në faqen e depozitës zyrtare.

NĂ«se dĂ«shironi tĂ« lexoni rreth multi-cluster-scheduler nĂ« veprim, Admiralty ka njĂ« rast interesant pĂ«rdorimi me Argo — procese pune, ngjarje, CI dhe CD nĂ« Kubernetes.

Mjetet dhe zgjidhjet e tjera

Kombinimi dhe menaxhimi i disa klasterëve është një detyrë e komplikuar; nuk ka një zgjidhje universale.

Nëse dëshironi të studioni më thellë këtë temë, ja disa burime për ju:

Këtu është gjithçka për sot

Faleminderit që e lexuat deri në fund!

Nëse e dini një mënyrë më efikase për të lidhur disa klasterë, na tregoni.

Ne do ta shtojmë mënyrën tuaj në lidhje.

Falënderim të veçantë Chris Nesbitt-Smithit (Chris Nesbitt-Smith) dhe Vincent De Smet (Vincent De Smet) (inxhinier i qëndrueshmërisë në swatmobile.io) për leximin e artikullit dhe ndarjen e informacionit të dobishëm rreth mënyrës si funksionon federata.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster