Velkommen til vår Kubernetes Quick Start-serie. Dette er en vanlig spalte med de mest interessante spørsmålene vi mottar på nettet og i treningene våre. Kubernetes-eksperten svarer.
Dagens ekspert er Daniel Polenchik (). Daniel jobber som instruktør og programvareutvikler hos .
Hvis du vil ha svar på spørsmålet ditt i neste innlegg, eller .
Gikk du glipp av tidligere innlegg? .
Hvordan koble sammen Kubernetes-klynger i forskjellige datasentre?
kort: , og jeg anbefaler også å lese om и .
Ganske ofte blir infrastruktur replikert og distribuert på tvers av forskjellige regioner, spesielt i kontrollerte miljøer.
Hvis en region er utilgjengelig, omdirigeres trafikken til en annen for å unngå avbrudd.
Med Kubernetes kan du bruke en lignende strategi og fordele arbeidsbelastninger på tvers av ulike regioner.
Du kan ha en eller flere klynger per team, region, miljø eller en kombinasjon av disse elementene.
Klyngene dine kan hostes i forskjellige skyer og lokale.
Men hvordan planlegger du infrastruktur for en slik geografisk spredning?
Trenger du å lage én stor klynge for flere skymiljøer over ett enkelt nettverk?
Eller har mange små klynger og finne en måte å kontrollere og synkronisere dem på?
Én lederklynge
Å lage én klynge over et enkelt nettverk er ikke så lett.
Tenk deg at du har en ulykke, forbindelsen mellom klyngesegmenter går tapt.
Hvis du har én hovedserver, vil ikke halvparten av ressursene kunne motta nye kommandoer fordi de ikke vil kunne kontakte masteren.
Og samtidig har du gamle rutetabeller (kube-proxy kan ikke laste ned nye) og ingen ekstra pods (kubelet kan ikke be om oppdateringer).
For å gjøre vondt verre, hvis Kubernetes ikke ser en node, markerer den den som foreldreløs og distribuerer de manglende podene til eksisterende noder.
Som et resultat har du dobbelt så mange pods.
Hvis du lager én hovedserver for hver region, vil det være problemer med konsensusalgoritmen i etcd-databasen. (ca. utg. — Etcd-databasen trenger faktisk ikke nødvendigvis å være plassert på hovedserverne. Den kan kjøres på en egen gruppe servere i samme region. Riktignok, samtidig får et poeng av svikt i klyngen. Men raskt.)
etcd bruker for å forhandle verdien før du skriver den til disk.
Det vil si at et flertall av instanser må komme til konsensus før staten kan skrives til etcd.
Hvis latensen mellom etcd-forekomster øker dramatisk, slik tilfellet er med tre etcd-forekomster i forskjellige regioner, tar det lang tid å forhandle frem en verdi og skrive den til disk.
Dette gjenspeiles i Kubernetes-kontrollere.
Kontrolløren trenger mer tid til å lære om endringen og skrive svaret til databasen.
Og siden det ikke er én kontroller, men flere, en kjedereaksjon resulterer og hele klyngen begynner å jobbe veldig sakte.
etcd er så latenssensitiv at .
Det finnes foreløpig ingen gode eksempler på et stort nettverk for en enkelt klynge.
I utgangspunktet prøver utviklerfellesskapet og SIG-klyngegruppen å finne ut hvordan man kan orkestrere klynger på samme måte som Kubernetes orkestrerer containere.
Alternativ 1: klyngeføderasjon med kubefed
Offisielt svar fra SIG-cluster - .
For første gang prøvde vi å administrere en samling av klynger som et enkelt objekt ved å bruke kube-føderasjonsverktøyet.
Starten var bra, men til slutt ble kubeforbundet aldri populært fordi det ikke støttet alle ressursene.
Den støttet fødererte leveranser og tjenester, men ikke StatefulSets, for eksempel.
Forbundskonfigurasjonen ble også overført i form av merknader og var ikke fleksibel.
Tenk deg hvordan du kan beskrive replikapartisjoneringen for hver klynge i en føderasjon ved å bruke bare merknader.
Det var et komplett rot.
SIG-cluster gjorde mye arbeid etter kubefed v1 og bestemte seg for å nærme seg problemet fra en annen vinkel.
I stedet for merknader bestemte de seg for å gi ut en kontroller som er installert på klynger. Den kan tilpasses ved hjelp av Custom Resource Definitions (CRDs).
For hver ressurs som vil være en del av føderasjonen, har du en tilpasset CRD-definisjon med tre seksjoner:
- standard definisjon av en ressurs, for eksempel distribusjon;
- seksjon
placement, hvor du definerer hvordan ressursen skal fordeles i føderasjonen; - seksjon
override, hvor du for en spesifikk ressurs kan overstyre vekten og parameterne fra plassering.
Her er et eksempel på en kombinert leveranse med plasserings- og overstyringsseksjoner.
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: 5Som du kan se, er tilbudet fordelt på to klynger: cluster1 и cluster2.
Den første klyngen leverer tre kopier, og den andre er satt til 5.
Hvis du trenger mer kontroll over antall replikaer, gir kubefed2 et nytt ReplicaSchedulingPreference-objekt der replikaer kan vektes:
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-strukturen og API er ikke helt klare ennå, og aktivt arbeid er i gang i det offisielle prosjektlageret.
Hold øye med kubefed2, men husk at den ennå ikke egner seg for produksjon.
Lær mer om kubefed2 fra i bloggen om Kubernetes og i .
Alternativ 2: kombinere klynger i Booking.com-stil
Utviklerne av Booking.com jobbet ikke på kubefed v2, men de kom med Shipper – en operatør for levering på flere klynger, i flere regioner og i flere skyer.
ligner litt på kubefed2.
Begge verktøyene lar deg tilpasse din multi-cluster-distribusjonsstrategi (hvilke klynger som brukes og hvor mange replikaer de har).
Men Senderens mål er å redusere risikoen for feil under levering.
I Shipper kan du definere en rekke trinn som beskriver delingen av replikaer mellom forrige og nåværende distribusjon og volumet av innkommende trafikk.
Når du skyver en ressurs til en klynge, ruller avsenderkontrolleren ut denne endringen trinnvis på tvers av alle de sammenkoblede klyngene.
Senderen er også svært begrenset.
For eksempel, den godtar rorkart som input og støtter ikke vaniljeressurser.
Generelt sett fungerer Shipper slik.
I stedet for standard levering, må du opprette en applikasjonsressurs som inkluderer et rordiagram:
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: 3Avsender er et godt alternativ for å administrere flere klynger, men det nære forholdet til Helm kommer bare i veien.
Hva om vi alle bytter fra Helm til eller ?
Finn ut mer om Shipper og dens filosofi på .
Hvis du vil grave i koden, .
Alternativ 3: "magisk" klyngesammenslåing
Kubefed v2 og Shipper jobber med cluster federation, og gir nye ressurser til klynger gjennom tilpasset ressursdefinisjon.
Men hva om du ikke vil omskrive alle leveranser, StatefulSets, DaemonSets osv. for å slå sammen?
Hvordan inkludere en eksisterende klynge i en føderasjon uten å endre YAML?
, som omhandler planlegging av arbeidsbelastninger på klynger.
Men i stedet for å komme opp med en ny måte å samhandle med klyngen på og pakke inn ressurser i egendefinerte definisjoner, er multi-cluster-scheduler innebygd i standard Kubernetes-livssyklus og fanger opp alle anrop som skaper pods.
Hver opprettet pod erstattes umiddelbart med en dummy.
multi-cluster-scheduler-bruk for å avlytte samtalen og lage en inaktiv dummy pod.
Den opprinnelige poden går gjennom en annen planleggingssyklus der det tas en plasseringsbeslutning etter avstemning av hele forbundet.
Til slutt blir poden levert til målklyngen.
Som et resultat har du en ekstra pod som ikke gjør noe, bare tar opp plass.
Fordelen er at du ikke trengte å skrive nye ressurser for å kombinere forsyninger.
Hver ressurs som oppretter en pod er automatisk klar til å slås sammen.
Dette er interessant, for plutselig har du forsyninger fordelt på flere regioner, og du la ikke engang merke til det. Dette er imidlertid ganske risikabelt, fordi alt her hviler på magi.
Men mens Shipper prøver å dempe virkningen av leveranser, håndterer multi-cluster-scheduler mer generelle oppgaver og er kanskje bedre egnet for batchjobber.
Den har ikke en avansert gradvis leveringsmekanisme.
Mer om multi-cluster-scheduler finner du på .
Hvis du vil lese om multi-cluster-scheduler i aksjon, har Admiralty — arbeidsflyter, arrangementer, CI og CD Kubernetes.
Andre verktøy og løsninger
Å koble til og administrere flere klynger er en kompleks oppgave, og det er ingen universell løsning.
Hvis du vil utforske dette emnet videre, her er noen ressurser:
- er et verktøy som kobler sammen overleggsnettverk av forskjellige Kubernetes-klynger.
- Butikkjede Target bruker .
- Prøv å bruke IPV6 og .
- Du kan for eksempel bruke et servicenettverk .
- Cilium, en plugin for containernettverksgrensesnitt, tilbyr , som lar deg kombinere flere klynger
Det var alt for i dag
Takk for at du leser til slutt!
Hvis du vet hvordan du kobler sammen flere klynger mer effektivt, .
Vi legger til metoden din i lenkene.
Spesiell takk til Chris Nesbitt-Smith () og Vincent de Sme () (pålitelighetsingeniør i ) for å lese artikkelen og dele nyttig informasjon om hvordan forbundet fungerer.
Kilde: www.habr.com