Velkommen til Kubernetes Quick Start-serien. Dette er en regelmæssig klumme med de mest interessante spørgsmål, vi modtager online og i vores træninger. Kubernetes-ekspertsvar.
Dagens ekspert er Daniel Polenchik (). Daniel arbejder som instruktør og softwareudvikler i .
Hvis du vil have svar på dit spørgsmål i næste indlæg, eller .
Gik du glip af tidligere indlæg? .
Hvordan forbinder man Kubernetes-klynger i forskellige datacentre?
Kort: , og jeg råder dig også til at læse om и .
Ganske ofte bliver infrastruktur replikeret og fordelt på tværs af forskellige regioner, især i kontrollerede miljøer.
Hvis en region ikke er tilgængelig, omdirigeres trafikken til en anden for at undgå afbrydelser.
Med Kubernetes kan du bruge en lignende strategi og fordele arbejdsbelastninger på tværs af forskellige regioner.
Du kan have en eller flere klynger pr. team, region, miljø eller en kombination af disse.
Dine klynger kan hostes på tværs af flere skyer og på stedet.
Men hvordan planlægger man infrastrukturen til en sådan geografisk spredning?
Har du brug for at oprette én stor klynge til flere cloudmiljøer over et enkelt netværk?
Eller har mange små klynger og finde en måde at kontrollere og synkronisere dem på?
Én ledelsesklynge
Det er ikke så let at oprette en klynge over et enkelt netværk.
Forestil dig, at du kommer ud for en ulykke, forbindelsen mellem klyngesegmenter går tabt.
Hvis du har én masterserver, vil halvdelen af ressourcerne ikke være i stand til at modtage nye kommandoer, fordi de ikke vil være i stand til at kontakte masteren.
Og samtidig har du gamle rutetabeller (kube-proxy kan ikke downloade nye) og ingen yderligere pods (kubelet kan ikke forespørge efter opdateringer).
Endnu værre, hvis Kubernetes ikke kan se en node, markerer den den som forældreløs og distribuerer manglende pods til eksisterende noder.
Som et resultat har du dobbelt så mange bælg.
Hvis du laver én masterserver pr. region, vil der være problemer med konsensusalgoritmen i etcd-databasen. (ca. udg. - Faktisk behøver etcd-databasen ikke være placeret på masterserverne. Det kan køres på en separat gruppe af servere i samme region. Men at have modtaget samtidig et fejlpunkt for en klynge. Men hurtigt.)
etcd bruger at blive enige om en værdi, før du skriver den til disk.
Det vil sige, at de fleste instanser skal nå til konsensus, før staten kan skrives til etcd.
Hvis latensen mellem etcd-instanser skyder i vejret, som det er tilfældet med tre etcd-instanser i forskellige regioner, tager det lang tid at blive enige om en værdi og skrive den til disk.
Dette afspejles også i Kubernetes-controllere.
Controllermanageren har brug for mere tid til at lære om ændringen og skrive svaret til databasen.
Og da controlleren ikke er én, men flere, der opnås en kædereaktion, og hele klyngen begynder at arbejde meget langsomt.
etcd er så latensfølsom, at .
Der er i øjeblikket ingen gode eksempler på et stort netværk for en enkelt klynge.
Dybest set forsøger udviklerfællesskabet og SIG-klyngegruppen at finde ud af, hvordan man kan orkestrere klynger på samme måde, som Kubernetes orkestrerer containere.
Mulighed 1: forbundne klynger med kubefed
Officielt svar fra SIG-cluster - .
For første gang forsøgte vi at administrere en samling af klynger som et enkelt objekt ved hjælp af kube-føderationsværktøjet.
Begyndelsen var god, men i sidste ende blev kube federation ikke populær, fordi den ikke understøttede alle ressourcer.
Det understøttede fødererede forsyninger og tjenester, men for eksempel ikke StatefulSets.
Også forbundskonfigurationen blev vedtaget i form af annoteringer og var ikke fleksibel.
Forestil dig, hvordan du kan beskrive opdelingen af replikaer for hver klynge i en føderation ved hjælp af en enkelt annotering.
Det viste sig at være et komplet rod.
SIG-cluster gjorde et godt stykke arbejde efter kubefed v1 og besluttede at nærme sig problemet fra en anden vinkel.
I stedet for annoteringer besluttede de at frigive en controller, der er installeret på klynger. Det kan konfigureres ved hjælp af brugerdefinerede ressourcedefinitioner (Custom Resource Definition, CRD).
For hver ressource, der vil blive fødereret, har du en tilpasset CRD-definition i tre sektioner:
- en standarddefinition af en ressource, såsom udrulning;
- sektion
placement, hvor du definerer, hvordan ressourcen skal fordeles i føderationen; - sektion
override, hvor du for en specifik ressource kan tilsidesætte vægt og parametre fra placering.
Her er et eksempel på en bundtet levering med placerings- og tilsidesættelsessektioner.
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 forsyningen opdelt i to klynger: cluster1 и cluster2.
Den første klynge leverer tre replikaer, og den anden har en værdi på 5.
Hvis du har brug for mere kontrol over antallet af replikaer, leverer kubefed2 et nyt ReplicaSchedulingPreference-objekt, hvor replikaer kan vægtes:
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 klar endnu, og der er aktivt arbejde i gang i det officielle projektlager.
Hold øje med kubefed2, men husk at den endnu ikke er god nok til et produktionsmiljø.
Lær mere om kubefed2 fra på Kubernetes-bloggen og .
Mulighed 2: Gruppering af Booking.com-stil
Udviklerne af Booking.com beskæftigede sig ikke med kubefed v2, men de kom op med Shipper, en operatør til levering på flere klynger, flere regioner og flere skyer.
ligner lidt kubefed2.
Begge værktøjer giver dig mulighed for at tilpasse din multi-cluster-implementeringsstrategi (hvilke klynger der bruges, og hvor mange replikaer de har).
Men Afsenderens opgave er at reducere risikoen for leveringsfejl.
I Shipper kan du definere en række trin, der beskriver opdelingen af replikaer mellem den tidligere og nuværende implementering og mængden af indgående trafik.
Når du skubber en ressource til en klynge, implementerer Shipper-controlleren trinvist denne ændring til alle de fødererede klynger.
Også afsender er meget begrænset.
For eksempel, det tager Helm-diagrammer som input og understøtter ikke vanilje-ressourcer.
Generelt fungerer afsender som følger.
I stedet for en standarddistribution skal du oprette en applikationsressource, der inkluderer et Helm-diagram:
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 er en god mulighed for at administrere flere klynger, men dets tætte forhold til Helm kommer kun i vejen.
Hvad hvis vi alle skifter fra Helm til eller ?
Lær mere om Shipper og hans filosofi på .
Hvis du vil grave i koden, .
Mulighed 3: "magisk" klyngesammenlægning
Kubefed v2 og Shipper arbejder med cluster federation ved at levere nye ressourcer til klynger gennem en tilpasset ressourcedefinition.
Men hvad nu hvis du ikke vil omskrive alle de forsyninger, StatefulSets, DaemonSets osv., der skal slås sammen?
Hvordan inkluderer man en eksisterende klynge i føderation uden at ændre YAML?
, som omhandler planlægning af arbejdsbelastninger på klynger.
Men i stedet for at opfinde en ny måde at interagere med klyngen på og indpakke ressourcer i brugerdefinerede definitioner, injiceres multi-cluster-scheduler i Kubernetes standard-livscyklus og opfanger alle opkald, der skaber pods.
Hver oprettet pod erstattes straks med en dummy.
multi-cluster-planlægningsbrug for at opsnappe opkaldet og oprette en inaktiv dummy pod.
Den originale pod gennemgår endnu en planlægningscyklus, hvor der efter polling af hele føderationen træffes en værtsbeslutning.
Til sidst leveres poden til målklyngen.
Som et resultat har du en ekstra pod, der ikke gør noget, bare optager plads.
Fordelen er, at du ikke behøver at skrive nye ressourcer for at kombinere forsyninger.
Hver ressource, der opretter en pod, er automatisk klar til at blive sammenføjet.
Det er interessant, fordi man pludselig har forsyninger fordelt på flere regioner, og man lagde ikke mærke til det. Dette er dog ret risikabelt, for her hviler alt på magi.
Men mens Shipper hovedsageligt forsøger at afbøde virkningerne af forsendelser, er multi-cluster-scheduler mere generel og måske bedre egnet til batchjob.
Den har ikke en avanceret gradvis leveringsmekanisme.
Mere om multi-cluster-scheduler kan findes på .
Hvis du vil læse om multi-cluster-scheduler i aktion, har Admiralty - arbejdsgange, events, CI og CD Kubernetes.
Andre værktøjer og løsninger
At forbinde og administrere flere klynger er en kompleks opgave, og der er ingen ensartet løsning.
Hvis du vil lære mere om dette emne, er her nogle ressourcer:
- er et værktøj, der forbinder overlejringsnetværk af forskellige Kubernetes-klynger.
- Target detailkæden bruger .
- Prøv at bruge IPV6 og .
- Du kan f.eks. bruge et servicenet .
- Cilium, et plugin til containernetværksinterface, tilbyder , som giver dig mulighed for at kombinere flere klynger
Det var alt for i dag
Tak fordi du læste med til slutningen!
Hvis du ved, hvordan du mere effektivt forbinder flere klynger, .
Vi tilføjer din metode til linkene.
Særlig tak til Chris Nesbitt-Smith () og Vincent de Sme () (til pålidelighedsingeniøren i ) for at læse artiklen og dele nyttige oplysninger om, hvordan forbundet fungerer.
Kilde: www.habr.com