Tere tulemast Kubernetes'i lühijuhendite seeriasse. See on regulaarne rubriik kõige huvitavamate küsimustega, mida me saame veebis ja meie koolitustel. Vastab Kubernetes'i ekspert.
Täna on ekspert — Daniele Polencic (). Daniele töötab õppejõu ja tarkvaraarendajana ettevõttes .
Kui soovite, et teie küsimusele vastataks järgmises postituses, või .
Kas jäite eelnenud postitustest ilma? .
Kuidas ühendada Kubernetes'i klastreid erinevates andmekeskustes?
Lühidalt: , samuti soovitan lugeda ja .
Infrastruktuuri dubleerimine ja jaotamine erinevatesse piirkondadesse on üsna tavaline, eriti kontrollitavates keskkondades.
Kui üks piirkond pole kättesaadav, suunatakse liiklus teise piirkonda, et vältida katkestusi.
Kubernetes'i abil saab kasutada sarnast strateegiat ning jaotada koormusi erinevatesse piirkondadesse.
Teie meeskonnal võib olla üks või mitu klastrit piirkonna, keskkonna või nende kombinatsiooni kaupa.
Teie klastrid võivad olla erinevates pilvedes ja kohalikus keskkonnas.
Kuidas planeerida infrastruktuuri nii laialdaselt hajutatud geograafiliselt?
Kas peaks looma ühe suure klaster mitu pilvekeskkonda ühisvõrgus?
Või tuleks mõjutada palju väikseid klastreid ja leida viis nende kontrollimiseks ja sünkroniseerimiseks?
Üks juhtiv klaster
Ühe ühisvõrku kuuluva klastrite loomine ei ole nii lihtne.
Kujutage ette, et teil on õnnetus ja ühendus klastrite segmentide vahel on kadunud.
Kui teil on üks meesterver, ei saa pool ressursse uusi käske vastu võtta, sest nad ei saa meesterverega ühendust.
Ja sel juhul on teil vanad marsruudimis tabelid (kube-proxy ei saa laadida uusi) ja mingeid lisapod'e (kubelet ei saa uuendusi küsida).
Mis veelgi hullem, kui Kubernetes ei näe sõlme, tähistab ta seda kadunuks ja jaotab puuduvad pod'id olemasolevatele sõlmedele.
Kokku on teil pod'e kaks korda rohkem.
Kui teete igasse piirkonda ühe meesterveri, tekivad probleemid etcd andmebaasi konsensuse saavutamise algoritmiga.märkus toimetajalt — Tegelikult ei pea etcd andmebaas olema tingimata meister-serverites. Seda saab käivitada eraldi serverigruppides ühes regioonis. Tõsi, see loob ka klastrile rikke punkti. Kuid see on kiire.)
etcd kasutab , et kokku leppida väärtuses, enne kui see kirjutatakse kettale.
See tähendab, et enamus eksemplare peab konsensuseni jõudma, enne kui olek saab kirjutada etcd-sse.
Kui viivitus eksemplaride vahel järsult suureneb, nagu kolme etcd eksemplariga eri piirkondades, kulub väärtuse kokku leppimiseks ja kettale kirjutamiseks palju aega.
See kajastub ka Kubernetes'i kontrollerites.
Kontrolleri haldur vajab rohkem aega, et teada saada muutusest ja kirjutada vastus andmebaasi.
Ja kuna kontrollerid ei ole üks, vaid mitu, tekib ahelreaktsioon ja kogu klaster hakkab töötama väga aeglaselt..
etcd on viivituse suhtes nii tundlik, et .
Hetkel ei ole ühtegi head näidet suurest võrgust ühele klastrile.
Peamiselt püüavad arendajate kogukond ja SIG-cluster rühm mõista, kuidas orkestreerida klastreid just nagu Kubernetes orkestreerib konteinerite haldamist.
Variant 1: klastrite föderatsioon kubefed'iga
SIG-cluster ametlik vastus — .
Esmakordselt prooviti kogu klastrite kogumit ühtse objektina hallata kube föderatsiooni tööriistaga.
Algus oli hea, kuid lõpuks ei saavutanud kube föderatsioon kunagi populaarsust, kuna see ei toetanud kõiki ressursse.
See toetas ühendatud pakkumist ja teenuseid, kuid näiteks ei toetanud StatefulSets'i.
Lisaks edastati föderatsiooni konfiguratsioon annotatsioonidena ja see ei olnud paindlik.
Kujutage ette, kuidas võiks föderatsioonis iga klastrite koopiate jagamist kirjeldada ainult annotatsioonide abil.
Saime täieliku segaduse.
SIG-cluster tegi pärast kubefed v1 suurepärast tööd ja otsustas probleemile läheneda teisiti.
Annotatsioonide asemel otsustasid nad välja anda kontrolleri, mis installitakse klastritele. Selle saab konfigureerida kohandatud ressursi definitsioonide (Custom Resource Definition, CRD) abil.
Iga ressursi jaoks, mis kuulub föderatsiooni, on teil kohandatud CRD, mis koosneb kolmest osast:
- standardne ressursimääratlus, näiteks deployment;
- osa
placement, kus määrate, kuidas ressurss jaotatakse föderatsioonis; - osa
override, kus saab konkreetse ressursi jaoks määrata ümber kaalu ja parameetrid placementist.
Siin on näide ühest pakkumisest koos placementi ja override'i osadega.
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: 5Nagu näete, on pakkumine jagatud kahe klastrisse: cluster1 ja cluster2.
Esimene klaster tarnib kolm replikat, samas kui teisel on määratud väärtus 5.
Kui vajate rohkem kontrolli replikate arvu üle, pakub kubefed2 uut objekti ReplicaSchedulingPreference, kus replikad saab jagada kaalu alusel:
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 ja API struktuur ei ole veel täiesti valmis ning projekti ametlikus hoidlas on aktiivne töö käimas.
Jälgige kubefed2, kuid pidage meeles, et see ei sobi veel töö keskkonda.
Learn more about kubefed2 from in the Kubernetes blog and in the .
Variant 2: clusterite ühendamine Booking.com stiilis
Booking.com arendajad ei tegelenud kubefed v2-ga, kuid nad lõid Shipperi — operaatori, mis hoolitseb kohaletoimetamise eest mitmes klastris, mitmes regioonis ja mitmes pilves.
see meenutab midagi kubefed2-le.
Mõlemad tööriistad võimaldavad seadistada mitme klastri juurutusstrateegiat (milliseid klastriid kasutatakse ja kui palju neil replikaid on).
Aga Shipperi ülesanne on vähendada kohaletoimetamisega seotud vigade riski.
Shipperis saab määratleda rida samme, mis kirjeldavad replikate jaotumist eelneva ja praeguse juurutuse vahel ning sissetuleva liikluse mahtu.
Kui saadate ressursi klastrisse, paigaldab Shipper selle muudatuse järk-järgult kõikidesse ühendatud klastritesse.
Ja veel, Shipper on väga piiratud.
Näiteks, see võtab sisendina vastu Helm-graafikud ja ei toeta vanilje ressursse.
Üldiselt töötab Shipper järgmiselt.
Standardse tarnimise asemel tuleb luua rakenduse resurss, mis sisaldab Helm-graafikut:
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 on hea valik mitme klastriga haldamiseks, kuid selle tihe seos Helmiga takistab ainult.
Aga mis, kui kõik võtame Helmilt üle või ?
Tutvuge Shipperiga ja selle filosoofiaga .
Kui soovite koodi uurida, .
Valik 3: „maagiline“ klastrite ühendamine
Kubefed v2 ja Shipper töötavad klastrite föderatsiooniga, pakkudes klastritele uusi ressursse kasutaja määratud ressursside kaudu.
Aga äkki ei soovi te kõikide tarnetüüpide, StatefulSetide, DaemonSetide jne kirjutamist ümber teha, et ühendada?
Kuidas liita olemasolev klaster föderatsiooni, muutmata YAML-i?
, mis tegeleb klastrite töökoormuste planeerimisega.
Kuid selle asemel, et välja mõelda uus viis klastriga suhtlemiseks ja ressursse kasutaja määratud määratlustesse mähkida, rakendatakse multi-cluster-scheduler Kubernetes'i standardse elu tsüklisse ja püüab kinni kõik kõned, mis loovad pod'e.
Iga loodud pod vahetatakse kohe välja tühja maketi vastu.
multi-cluster-scheduler kasutab , et interceptida kõne ja luua mitteaktiivne pod-maket.
Algne pod läbib veel ühe planeerimisringi, kus pärast kogu föderatsiooni küsitlemist tehakse otsus paigutuse kohta.
Lõpuks toimetatakse pod sihtklastrisse.
Tulemusena on teil üleliigne pod, mis ei tee midagi, lihtsalt võtab ruumi.
Eeliseks on see, et teil ei pidanud olema uusi ressursse tarnete integreerimiseks kirjutama.
Iga pod'i loomise ressurss on automaatselt tarneteks valmis.
See on huvitav, sest teil võivad ühel hetkel olla tarned, mis on jaotatud mitmesse piirkonda, kuid te ei märganudki. Sellegipoolest on see üsna riskantne, kuna kõik toetub siin maagiale.
Aga kui Shipper püüab peamiselt tarnete tagajärgi leevendada, siis multi-cluster-scheduler täidab üldisemaid ülesandeid ja on võib-olla paremini sobiv partii ülesannete jaoks.
Tal ei ole arenenud järkjärguliste tarnete mehhanismi.
Rohkem multi-cluster-schedulerist saad lugeda .
Kui soovite lugeda multi-cluster-schedulerist tegutsemise käigus, on Admiraltyl olemas — töövoogude, sündmuste, CI ja CD Kubernetesega.
Teised tööriistad ja lahendused
Mitme klastri ühendamine ja haldamine on keeruline ülesanne, universaalset lahendust ei eksisteeri.
Kui soovite selle teema kohta põhjalikumalt uurida, siis siin on mõned ressursid:
- — tööriist, mis ühendab erinevate Kubernetes klasside ülekattesid.
- Jaepood Target kasutab .
- Proovige kasutada IPV6 ja .
- Võib kasutada teenusete võrgustikku, näiteks .
- Cilium, konteinerite võrgu liidese plug-in, pakub , mis võimaldab mitme klastrit ühendada
Sellega ongi täna kõik
Aitäh, et lugesite lõpuni!
Kui teate, kuidas mitmeid klastreid efektiivsemalt ühendada, .
Lisame teie meetodi linkidele.
Eriti tänud Chris Nesbitt-Smithile () ja Vincent De Smetile () (ennustatav insener ) selle eest, et lugesite artiklit ja jagasite kasulikku teavet selle kohta, kuidas föderatsioon töötab.
Allikas: habr.com
