Välkommen till vår Kubernetes Quick Start-serie. Det här är en vanlig kolumn med de mest intressanta frågorna vi får online och i våra utbildningar. Kubernetes expertsvar.
Dagens expert är Daniel Polenchik (). Daniel arbetar som instruktör och mjukvaruutvecklare på .
Om du vill ha din fråga besvarad i nästa inlägg, eller .
Missat tidigare inlägg? .
Hur kopplar man ihop Kubernetes-kluster i olika datacenter?
I korthet: , och jag rekommenderar också att läsa om и .
Ganska ofta replikeras och distribueras infrastruktur över olika regioner, särskilt i kontrollerade miljöer.
Om en region inte är tillgänglig omdirigeras trafiken till en annan för att undvika avbrott.
Med Kubernetes kan du använda en liknande strategi och fördela arbetsbelastningar över olika regioner.
Du kan ha ett eller flera kluster per team, region, miljö eller en kombination av dessa element.
Dina kluster kan lagras i olika moln och på plats.
Men hur planerar man infrastruktur för sådan geografisk spridning?
Behöver du skapa ett stort kluster för flera molnmiljöer över ett enda nätverk?
Eller har många små kluster och hittar ett sätt att kontrollera och synkronisera dem?
Ett ledarskapskluster
Att skapa ett kluster över ett enda nätverk är inte så lätt.
Föreställ dig att du råkar ut för en olycka, anslutningen mellan klustersegment går förlorad.
Om du har en masterserver kommer hälften av resurserna inte att kunna ta emot nya kommandon eftersom de inte kommer att kunna kontakta mastern.
Och samtidigt har du gamla routingtabeller (kube-proxy kan inte ladda ner nya) och inga ytterligare poddar (kubelet kan inte begära uppdateringar).
För att göra saken värre, om Kubernetes inte ser en nod, markerar den den som föräldralös och distribuerar de saknade podarna till befintliga noder.
Som ett resultat har du dubbelt så många baljor.
Om du gör en masterserver för varje region kommer det att uppstå problem med konsensusalgoritmen i etcd-databasen. (cirka. ed. — Faktum är att etcd-databasen inte nödvändigtvis måste finnas på huvudservrarna. Det kan köras på en separat grupp av servrar i samma region. Sant, samtidigt få en punkt av misslyckande i klustret. Men snabbt.)
etcd använder för att förhandla om värdet innan du skriver det till disk.
Det vill säga att en majoritet av instanserna måste nå konsensus innan staten kan skrivas till etcd.
Om latensen mellan etcd-instanser ökar dramatiskt, vilket är fallet med tre etcd-instanser i olika regioner, tar det lång tid att förhandla fram ett värde och skriva det till disk.
Detta återspeglas i Kubernetes-kontroller.
Kontrollören behöver mer tid för att lära sig om förändringen och skriva svaret till databasen.
Och eftersom det inte finns en styrenhet, utan flera, en kedjereaktion uppstår och hela klustret börjar arbeta mycket långsamt.
etcd är så latenskänslig att .
Det finns för närvarande inga bra exempel på ett stort nätverk för ett enskilt kluster.
I grund och botten försöker utvecklargemenskapen och SIG-klustergruppen ta reda på hur man kan orkestrera kluster på samma sätt som Kubernetes orkestrerar behållare.
Alternativ 1: klusterfederation med kubefed
Officiellt svar från SIG-kluster - .
För första gången försökte vi hantera en samling kluster som ett enda objekt med hjälp av kube-federationsverktyget.
Starten var bra, men i slutändan blev kubefederationen aldrig populär eftersom den inte stödde alla resurser.
Det stödde federerade leveranser och tjänster, men inte StatefulSets, till exempel.
Dessutom överfördes federationskonfigurationen i form av anteckningar och var inte flexibel.
Föreställ dig hur du kan beskriva replikpartitioneringen för varje kluster i en federation med enbart anteckningar.
Det var en fullständig röra.
SIG-cluster gjorde mycket arbete efter kubefed v1 och bestämde sig för att närma sig problemet från en annan vinkel.
Istället för anteckningar bestämde de sig för att släppa en kontroller som är installerad på kluster. Det kan anpassas med Custom Resource Definitions (CRDs).
För varje resurs som kommer att ingå i federationen har du en anpassad CRD-definition med tre sektioner:
- standarddefinition av en resurs, till exempel distribution;
- kapitel
placement, där du definierar hur resursen ska fördelas i federationen; - kapitel
override, där du för en specifik resurs kan åsidosätta vikten och parametrarna från placeringen.
Här är ett exempel på en kombinerad leverans med placerings- och åsidosättningssektioner.
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 är utbudet fördelat över två kluster: cluster1 и cluster2.
Det första klustret tillhandahåller tre repliker, och det andra är inställt på 5.
Om du behöver mer kontroll över antalet repliker tillhandahåller kubefed2 ett nytt ReplicaSchedulingPreference-objekt där repliker kan viktas:
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 och API är inte riktigt klara än, och ett aktivt arbete pågår i det officiella projektförrådet.
Håll ett öga på kubefed2, men kom ihåg att den ännu inte är lämplig för produktion.
Lär dig mer om kubefed2 från i bloggen om Kubernetes och i .
Alternativ 2: kombinera kluster i Booking.com-stil
Utvecklarna av Booking.com arbetade inte på kubefed v2, men de kom med Shipper – en operatör för leverans på flera kluster, i flera regioner och i flera moln.
något liknande kubefed2.
Båda verktygen låter dig anpassa din distributionsstrategi för flera kluster (vilka kluster som används och hur många repliker de har).
Men Avsändarens mål är att minska risken för fel vid leverans.
I Shipper kan du definiera en serie steg som beskriver uppdelningen av repliker mellan den tidigare och nuvarande distributionen och volymen av inkommande trafik.
När du skickar en resurs till ett kluster rullar Shipper-kontrollern ut den förändringen stegvis över alla sammanfogade kluster.
Dessutom är avsändaren mycket begränsad.
Till exempel, den accepterar styrdiagram som input och stöder inte vaniljresurser.
I allmänna termer fungerar Shipper så här.
Istället för standardleverans måste du skapa en applikationsresurs som innehåller ett styrdiagram:
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 är ett bra alternativ för att hantera flera kluster, men dess nära relation med Helm kommer bara i vägen.
Tänk om vi alla byter från Helm till eller ?
Läs mer om Shipper och dess filosofi på .
Om du vill gräva i koden, .
Alternativ 3: "magisk" klustersammanslagning
Kubefed v2 och Shipper samarbetar med klusterfederation och tillhandahåller nya resurser till kluster genom anpassad resursdefinition.
Men vad händer om du inte vill skriva om alla leveranser, StatefulSets, DaemonSets, etc. för att slå samman?
Hur inkluderar man ett befintligt kluster i en federation utan att ändra YAML?
, som handlar om schemaläggning av arbetsbelastningar på kluster.
Men istället för att komma på ett nytt sätt att interagera med klustret och slå in resurser i anpassade definitioner, är multi-cluster-scheduler inbäddad i Kubernetes standardlivscykel och fångar upp alla samtal som skapar pods.
Varje skapad pod ersätts omedelbart med en dummy.
multi-kluster-schemaläggare använder för att avlyssna samtalet och skapa en ledig dummy pod.
Den ursprungliga podden går igenom ytterligare en planeringscykel där, efter att ha röstat hela förbundet, ett placeringsbeslut tas.
Slutligen levereras podden till målklustret.
Som ett resultat har du en extra pod som inte gör någonting, bara tar plats.
Fördelen är att du inte behövde skriva nya resurser för att kombinera leveranser.
Varje resurs som skapar en pod är automatiskt redo att slås samman.
Detta är intressant, för plötsligt har du förnödenheter fördelade över flera regioner, och du märkte inte ens det. Detta är dock ganska riskabelt, eftersom allt här vilar på magi.
Men medan Shipper mest försöker mildra effekterna av leveranser, hanterar multi-cluster-scheduler mer allmänna uppgifter och är kanske bättre lämpad för batchjobb.
Den har ingen avancerad gradvis leveransmekanism.
Mer om multi-cluster-scheduler finns på .
Om du vill läsa om multi-cluster-scheduler i aktion så har Admiralty — Arbetsflöden, evenemang, CI och CD Kubernetes.
Andra verktyg och lösningar
Att ansluta och hantera flera kluster är en komplex uppgift och det finns ingen universell lösning.
Om du vill utforska det här ämnet ytterligare, här är några resurser:
- är ett verktyg som kopplar samman överlagringsnätverk av olika Kubernetes-kluster.
- Detaljhandelskedjan Target uses .
- Prova att använda IPV6 och .
- Du kan till exempel använda ett servicenät .
- Cilium, en plugin för containernätverksgränssnitt, erbjuder , vilket gör att du kan kombinera flera kluster
Det är allt för idag
Tack för att du läser till slutet!
Om du vet hur du ansluter flera kluster mer effektivt, .
Vi lägger till din metod i länkarna.
Speciellt tack till Chris Nesbitt-Smith () och Vincent de Sme () (tillförlitlighetsingenjör i ) för att läsa artikeln och dela användbar information om hur förbundet fungerar.
Källa: will.com