Tere tulemast lühikeste Kubernetes juhendite seeriasse. See on regulaarne rubriik kõige huvitavamate küsimustega, mida me saame veebis ja meie koolitustel. Vastab Kubernetes ekspert.
Tänane ekspert on Daniele Polencic (). Daniele töötab juhendajana ja tarkvaraarendajana ettevõttes .
Kui soovite saada vastust oma küsimusele järgmises postituses, või .
Kas jäite eelnevaid postitusi maha? .
Kuidas ühendada Kubernetes klastrid erinevates andmekeskustes?
Lühidalt: , ja soovitame tutvuda ka ja .
Tihti replitakse ja jaotatakse infrastruktuuri erinevates piirkondades, eriti kontrollitud keskkondades.
Kui üks piirkond pole saadaval, suunatakse liiklus teise, et vältida katkestusi.
Kubernetesega on võimalik kasutada sarnast strateegiat ja jaotada koormusi erinevatesse piirkondadesse.
Teil võib olla üks või mitu klastri igas meeskonnas, piirkonnas, keskkonnas või nende kombinatsioonis.
Teie klastrid võivad asuda erinevates pilvkeskkondades ja kohalikus keskkonnas.
Kuid kuidas planeerida infrastruktuuri sellise geograafilise leviku jaoks?
Kas luua üks suur klaster mitme pilvkeskkonna moodustamiseks ühes võrgus?
Või luua palju väikeseid klastreid ja leida viis nende juhtimiseks ja sünkroonimiseks?
Üks juhiklastrite
Ühe klastrite loomine ühes võrgus ei ole sugugi lihtne.
Kujutage ette, et teil on rike, ühendus klastrite segmentide vahel on katkenud.
Kui teil on ainult üks master-server, ei saa pooled ressurssidest uusi käske vastu võtta, kuna nad ei saa masteriga ühendust.
Ja sellega seoses on teil vanad marsruudistustabelid (kube-proxy ei suuda uusi laadida) ja mingeid täiendavaid pod'e (kubelet ei saa uuendusi küsida).
Mis veelgi hullem, kui Kubernetes ei näe sõlme, märgib ta selle kadunuks ja jaotab puuduvad pod'id olemasolevatele sõlmedele.
Lõppkokkuvõttes on teil kaks korda rohkem pod'e.
Kui teete igas piirkonnas ühe master-serveri, siis võivad tekkida probleemid andmebaasi etcd konsensuse saavutamise algoritmiga. (märk. red. — Tegelikult ei pea etcd andmebaas olema tingimata master-serverites. Seda saab käitada eraldi serverite grupis ühes regioonis. Kuid see toob endaga kaasa klastripunkti tõrke. Kuid see on kiire.)
etcd kasutab , et kooskõlastada väärtus enne selle kirjutamist kettale.
See tähendab, et enamiku eksemplaride peab saavutama konsensuse, enne kui olek saab kirjutada etcd-sse.
Kui viivitus eksemplaride vahel järjest suureneb, nagu juhtudel, kui kolm etcd eksemplari asuvad erinevates piirkondades, kulub väärtuse kooskõlastamiseks ja selle kirjutamiseks kettale palju aega.
See kajastub ka Kubernetesi kontrollijates.
Kontrollijatel kulub kauem aega, et teada saada muudatusest ning kirjutada vastus andmebaasi.
Ja kuna kontrollijaid on mitu, tekib ahelreaktsioon ja kogu klaster hakkab töötama väga aeglaselt.
etcd on nii tundlik viivituse suhtes, et .
Praegu ei ole head näidet suurest võrgustiku ühe klastri jaoks.
Peamiselt püüavad arendajate kogukond ja SIG-cluster grupp mõista, kuidas orkestreerida klastreid nii nagu Kubernetes orkestreerib konteinerid.
Variant 1: klastrite föderatsioon kubefediga
SIG-clusteri ametlik vastus — .
Esimest korda prooviti klastrite kogumit hallata kui ühte objekti kube föderatsiooni tööriista abil.
Algus oli hea, kuid lõpuks ei saanud kube föderatsioon populaarseks, kuna see ei toetanud kõiki ressursse.
See toetas koondatud tarnimist ja teenuseid, kuid näiteks ei olnud StatefulSets.
Ja föderatsiooni konfiguratsioon edastati annotatsioonidena ning ei olnud paindlik.
Kujutage ette, kuidas saab annotatsioonide abil kirjeldada igas föderatsioonis oleva klastri replikate jagunemist.
Tuli täielik segadus.
SIG-cluster on pärast kubefed v1 palju tööd teinud ja otsustanud probleemile läheneda teisest küljest.
Annotatsioonide asemel otsustasid nad välja anda kontrollija, mis installitakse klastritesse. Seda saab konfigureerida kasutaja määratletud ressursside määratlemise (Custom Resource Definition, CRD) abil.
Iga ressursi jaoks, mis kuulub föderatsiooni, on teil kohandatud CRD definitsioon, mis koosneb kolmest osast:
- standardsest ressursi määratlemisest, nagu näiteks deploy;
- osa
placement, kus määrate, kuidas ressursi jaotamine föderatsioonis toimub; - osa
override, kus konkreetse ressursi jaoks saate kaalud ja parameetrid placement'ist ümber määrata.
Siin on näide ühendatud tarnest, kus on osad placement ja 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: 5Nagu näete, on tarne jaotatud kahe klastrisse: cluster1 ja cluster2.
Esimene klasters tarnib kolm replikat, samas kui teisel on määratud väärtus 5.
Kui vajate rohkem kontrolli replikate arvu üle, siis kubefed2 pakub uut objekti ReplicaSchedulingPreference, kus replikasid saab jaotada kaalu järgi:
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äielikult valmis ning ametlikus projekti hoidlas käib aktiivne töö.
Jälgige kubefed2, kuid pidage meeles, et see ei ole veel töökeskkonda sobiv.
Lisateabe saamiseks kubefed2 kohta vaadake Kubernetes blogis ja .
Variant 2: klastrite ühendamine Booking.com stiilis
Booking.com arendajad ei tegelenud kubefed v2, aga nad leiutasid Shipper'i — operaatori mitme klastri, mitme piirkonna ja mitme pilve tarnimiseks.
millel on sarnasus kubefed2-ga.
Mõlemad tööriistad võimaldavad seadistada mitme klastriga juurutamise strateegiat (milliseid klastreid kasutatakse ja kui palju neil replikaate on).
Aga Shipperi ülesanne on vähendada tarnimisega seotud vigade riski.
Shipper'is saate määrata mitmeid samme, mis kirjeldavad replikate jagamist varasema ja praeguse juurutuse vahel ja sissetuleva liikluse mahtu.
Kui saadate ressursi klastrisse, juurutab Shipper'i kontroller järk-järgult seda muutust kõigis ühendatud klastrites.
Ja Shipper on väga piiratud.
Näiteks, ta aktsepteerib Helm'i graafikuid kui sisendandmeid. ja ei toeta vanilla ressursse.
Üldises plaanis töötab Shipper järgmiselt.
Standardse tarnimise asemel tuleb luua rakenduse ressurss, mis hõlmab Helm'i graafikute:
apiVersioon: shipper.booking.com/v1alpha1
kind: Rakendus
metadata:
nimi: super-server
spec:
revisionHistoryLimit: 3
mall:
chart:
nimi: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
versioon: 0.0.1
klastrite nõuded:
piirkonnad:
- nimi: kohalik
strateegia:
sammud:
- maht:
contender: 1
incumbent: 100
nimi: staging
liiklus:
contender: 0
incumbent: 100
- maht:
contender: 100
incumbent: 0
nimi: täielik
liiklus:
contender: 100
incumbent: 0
väärtused:
replikateArv: 3Shipper on hea valik mitme klastriga haldamiseks, kuid selle tihe seos Helmiga takistab ainult.
Aga äkki liigume kõik Helmilt üle või ?
Tutvuge Shipperi ja tema filosoofiaga .
Kui soovite koodi uurida, .
Valik 3: "magiline" klastrite ühendamine
Kubefed v2 ja Shipper töötavad klastrite föderatsiooniga, pakkudes klastritele uusi ressursse kasutaja määratud ressursside kaudu.
Aga äkki te ei soovi kõiki tarnimisi, StatefulSets, DaemonSets jne ümber kirjutada, et need ühendataks?
Kuidas ühendada olemasolev klaster föderatsiooni, muutes YAML-i?
, mis tegeleb klastrite jaoks planeeritud töökoormustega.
Kuid uue ühendamisviisi väljamõtlemise asemel integreeritakse multi-cluster-scheduler Kubernetes'e standardse elutsükli ja püütakse kinni kõik kutseid, mis loovad pod'e.
Iga loodud pod asendatakse koheselt tühja placeholderiga.
multi-cluster-scheduler kasutab , et kutse kinni püüda ja luua inaktiivne pod-placeholder.
Algne pod läbib veel ühe planeerimisetsükli, kus pärast kogu föderatsiooni küsitlemist otsustatakse asukoht.
Lõpuks tarnitakse pod sihtklastrisse.
Kokkuvõttes on teil üleliigne pod, mis ei tee midagi, lihtsalt võtab ruumi.
Eelis on see, et te ei pidanud uusi ressursse tarnimise ühendamiseks kirjutama.
Iga resurss, mis loob pod'e, on automaatselt valmis tarnimiste ühendamiseks.
See, it's interesting because suddenly you have deliveries distributed across several regions, and you didn't even notice. However, this is quite risky, as everything here relies on magic.
But while Shipper primarily tries to mitigate the consequences of deliveries, the multi-cluster-scheduler performs more general tasks and might be better suited for batch jobs.
It does not have an advanced gradual delivery mechanism.
You can learn more about the multi-cluster-scheduler on .
If you want to read about multi-cluster-scheduler in action, Admiralty has an — workflows, events, CI, and CD in Kubernetes.
Other tools and solutions
Connecting and managing multiple clusters is a complex task; there is no universal solution.
If you want to delve deeper into this topic, here are a few resources:
- — a tool that connects overlay networks of different Kubernetes clusters.
- Retail network Target uses .
- Try using IPV6 and .
- You can use a service mesh, for example, .
- Cilium, a container network interface plugin, offers , which allows combining multiple clusters.
That's all for today.
Thank you for reading until the end!
If you know of a more effective way to connect multiple clusters, .
We will add your method to the links.
Special thanks to Chris Nesbitt-Smith () and Vincent De Smet () (reliability engineer at ) for reading the article and sharing helpful information about how federation works.
Allikas: habr.com
