Velkomin í Kubernetes Quick Start seríuna okkar. Þetta er venjulegur dálkur með áhugaverðustu spurningunum sem við fáum á netinu og í þjálfuninni okkar. Kubernetes sérfræðingur svarar.
Sérfræðingur dagsins er Daniel Polenchik (). Daníel starfar sem leiðbeinandi og hugbúnaðargerð hjá .
Ef þú vilt svara spurningunni þinni í næstu færslu, eða .
Misstu af fyrri færslum? .
Hvernig á að tengja Kubernetes klasa í mismunandi gagnaverum?
Í stuttu máli: , og ég mæli líka með að lesa um и .
Oft eru innviðir endurteknir og dreift yfir mismunandi svæði, sérstaklega í stýrðu umhverfi.
Ef eitt svæði er ekki tiltækt er umferð beint á annað til að forðast truflanir.
Með Kubernetes geturðu notað svipaða stefnu og dreift vinnuálagi á mismunandi svæði.
Þú getur haft einn eða fleiri klasa fyrir hvert lið, svæði, umhverfi eða samsetningu þessara þátta.
Hægt er að hýsa klasana þína í mismunandi skýjum og á staðnum.
En hvernig skipuleggur þú innviði fyrir slíka landfræðilega útbreiðslu?
Þarftu að búa til einn stóran þyrping fyrir mörg skýjaumhverfi yfir eitt net?
Eða eiga marga litla klasa og finna leið til að stjórna og samstilla þá?
Einn forystuklasi
Það er ekki svo auðvelt að búa til einn þyrping yfir eitt net.
Ímyndaðu þér að þú lendir í slysi, tenging milli klasahluta er rofin.
Ef þú ert með einn aðalþjónn mun helmingur auðlindanna ekki geta tekið á móti nýjum skipunum vegna þess að þeir munu ekki geta haft samband við skipstjórann.
Og á sama tíma ertu með gamlar leiðartöflur (kube-proxy getur ekki hlaðið niður nýjum) og engin viðbótarbelg (kubelet getur ekki beðið um uppfærslur).
Til að gera illt verra, ef Kubernetes sér ekki hnút, merkir það hann sem munaðarlaus og dreifir belgjunum sem vantar til núverandi hnúta.
Fyrir vikið ertu með tvöfalt fleiri belg.
Ef þú býrð til einn aðalþjón fyrir hvert svæði, verða vandamál með samþykki reiknirit í etcd gagnagrunninum. (ca. útg. — Reyndar þarf etcd gagnagrunnurinn ekki endilega að vera staðsettur á aðalþjónum. Það er hægt að keyra það á sérstökum hópi netþjóna á sama svæði. True, á sama tíma að fá stig bilun í þyrpingunni. En fljótt.)
etcd notar til að semja um gildi áður en það er skrifað á disk.
Það er, meirihluti mála verður að ná samstöðu áður en hægt er að skrifa ríkið til etcd.
Ef leynd milli etcd tilvika eykst verulega, eins og raunin er með þrjú etcd tilvik á mismunandi svæðum, tekur það langan tíma að semja um gildi og skrifa það á disk.
Þetta endurspeglast í Kubernetes stýringar.
Stjórnandi þarf meiri tíma til að kynna sér breytinguna og skrifa svarið í gagnagrunninn.
Og þar sem það er ekki einn stjórnandi, heldur nokkrir, keðjuverkun verður til og allur þyrpingin fer að vinna mjög hægt.
etcd er svo latency næmur að .
Sem stendur eru engin góð dæmi um stórt net fyrir einn þyrping.
Í grundvallaratriðum eru þróunarsamfélagið og SIG-klasahópurinn að reyna að finna út hvernig eigi að skipuleggja klasa á sama hátt og Kubernetes skipuleggur gáma.
Valkostur 1: klasasamband með kubefed
Opinbert svar frá SIG-þyrpingunni - .
Í fyrsta skipti reyndum við að stjórna safni klasa sem einn hlut með því að nota kube federation tólið.
Byrjunin var góð, en á endanum varð kube federation aldrei vinsælt vegna þess að það styður ekki öll úrræði.
Það styður sambandssendingar og þjónustu, en ekki StatefulSets, til dæmis.
Einnig var sambandsstillingin send í formi athugasemda og var ekki sveigjanleg.
Ímyndaðu þér hvernig þú gætir lýst eftirmyndaskiptingu fyrir hvern klasa í sambandsríki með því að nota aðeins athugasemdir.
Þetta var algjört rugl.
SIG-cluster vann mikla vinnu eftir kubefed v1 og ákvað að nálgast vandamálið frá öðru sjónarhorni.
Í stað athugasemda ákváðu þeir að gefa út stjórnanda sem er settur upp á klasa. Það er hægt að aðlaga það með því að nota Custom Resource Definitions (CRDs).
Fyrir hverja auðlind sem verður hluti af sambandinu hefurðu sérsniðna CRD skilgreiningu með þremur hlutum:
- staðlaða skilgreiningu á auðlind, til dæmis dreifing;
- kafla
placement, þar sem þú skilgreinir hvernig auðlindinni verður dreift í sambandinu; - kafla
override, þar sem fyrir tiltekna auðlind er hægt að hnekkja þyngd og færibreytum frá staðsetningu.
Hér er dæmi um samsetta afhendingu með staðsetningar- og hnekkjahlutum.
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: 5Eins og þú sérð er framboðið dreift yfir tvo klasa: cluster1 и cluster2.
Fyrsti þyrpingin gefur þrjár eftirlíkingar og sá seinni er stilltur á 5.
Ef þú þarft meiri stjórn á fjölda eftirmynda, gefur kubefed2 nýjan ReplicaSchedulingPreference hlut þar sem hægt er að vega eftirlíkingar:
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: 2CRD uppbyggingin og API eru ekki alveg tilbúin ennþá og virk vinna er í gangi í opinberu verkefnageymslunni.
Fylgstu með kubefed2, en mundu að það hentar ekki enn til framleiðslu.
Lærðu meira um kubefed2 frá í blogginu um Kubernetes og í .
Valkostur 2: sameina klasa í Booking.com stíl
Hönnuðir Booking.com unnu ekki á kubefed v2, en þeir komu með Shipper - rekstraraðila fyrir afhendingu á nokkrum klösum, á nokkrum svæðum og í nokkrum skýjum.
nokkuð svipað og kubefed2.
Bæði verkfærin gera þér kleift að sérsníða dreifingarstefnu þína fyrir marga klasa (hvaða klasar eru notaðir og hversu margar eftirlíkingar þeir hafa).
En Markmið sendanda er að draga úr hættu á mistökum við afhendingu.
Í Sendara geturðu skilgreint röð skrefa sem lýsa skiptingu eftirmynda á milli fyrri og núverandi uppsetningar og magni komandi umferðar.
Þegar þú ýtir tilföngum í þyrping, rúllar sendandastýringin smám saman út þeirri breytingu yfir alla sameinaða klasa.
Einnig er sendandi mjög takmarkaður.
Til dæmis, það tekur við stýrikortum sem inntak og styður ekki vanilluauðlindir.
Almennt séð virkar sendandi svona.
Í stað staðlaðrar afhendingar þarftu að búa til forritsúrræði sem inniheldur stýrikort:
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: 3Sendandi er góður kostur til að stjórna mörgum klösum, en náið samband hans við Helm kemur aðeins í veg fyrir.
Hvað ef við skiptum öll úr Helm til eða ?
Finndu út meira um Shipper og heimspeki hans á .
Ef þú vilt grafa ofan í kóðann, .
Valkostur 3: „töfra“ klasasamruni
Kubefed v2 og Shipper vinna með klasasambandi og veita klösum nýtt úrræði með sérsniðinni skilgreiningu tilfanga.
En hvað ef þú vilt ekki endurskrifa allar sendingar, StatefulSets, DaemonSets o.s.frv. til að sameinast?
Hvernig á að taka núverandi klasa inn í sambandsríki án þess að breyta YAML?
, sem fjallar um tímasetningu vinnuálags á klasa.
En í stað þess að koma með nýja leið til að hafa samskipti við klasann og vefja tilföngum inn í sérsniðnar skilgreiningar, er multi-cluster-scheduler felld inn í staðlaða Kubernetes lífsferilinn og hlerar öll símtöl sem búa til belg.
Hvert búið til belg er samstundis skipt út fyrir dummy.
multi-cluster-scheduler notar til að hlera símtalið og búa til aðgerðalausan dummy pod.
Upprunalega belgurinn fer í gegnum aðra áætlanagerð þar sem ákvörðun um staðsetningu er tekin eftir að hafa skoðað allt sambandið.
Að lokum er belgurinn afhentur í markþyrpinguna.
Fyrir vikið ertu með aukabelg sem gerir ekkert, tekur bara pláss.
Kosturinn er sá að þú þurftir ekki að skrifa ný tilföng til að sameina vistir.
Hvert tilfang sem býr til hólf er sjálfkrafa tilbúið til að sameinast.
Þetta er áhugavert, vegna þess að allt í einu ertu með birgðir dreift yfir nokkur svæði og þú tókst ekki einu sinni eftir því. Þetta er þó nokkuð áhættusamt því hér hvílir allt á töfrum.
En á meðan Shipper reynir að mestu að draga úr áhrifum afhendinganna, sinnir multi-cluster-scheduler almennari verkefnum og hentar ef til vill betur fyrir lotustörf.
Það er ekki með háþróaðan hægfara afhendingu.
Meira um multi-cluster-scheduler er að finna á .
Ef þú vilt lesa um multi-cluster-scheduler í aðgerð, Admiralty hefur — verkflæði, viðburðir, CI og CD Kubernetes.
Önnur verkfæri og lausnir
Að tengja og stjórna mörgum klösum er flókið verkefni og það er engin alhliða lausn.
Ef þú vilt kanna þetta efni frekar eru hér nokkur úrræði:
- er tól sem tengir yfirlagsnet mismunandi Kubernetes klasa.
- Verslunarkeðja Target uses .
- Prófaðu að nota IPV6 og .
- Þú getur til dæmis notað þjónustunet .
- Cilium, gámakerfisviðmótbót, býður upp á , sem gerir þér kleift að sameina nokkra klasa
Það er allt í dag
Takk fyrir að lesa til enda!
Ef þú veist hvernig á að tengja marga klasa á skilvirkari hátt, .
Við munum bæta aðferð þinni við tenglana.
Sérstakar þakkir til Chris Nesbitt-Smith () og Vincent de Sme () (áreiðanleikaverkfræðingur í ) fyrir að lesa greinina og deila gagnlegum upplýsingum um hvernig sambandið starfar.
Heimild: www.habr.com