Hur man kopplar ihop Kubernetes-kluster i olika datacenter
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 (Daniele Polencic). Daniel arbetar som instruktör och mjukvaruutvecklare på Learnk8s.
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 flotte algoritmfö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.
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.
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.
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.
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:
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 webhooks för åtkomständringfö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å officiella förvarssida.
Om du vill läsa om multi-cluster-scheduler i aktion så har Admiralty intressant användningsfall med Argo — 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:
Submariner från Rancher är ett verktyg som kopplar samman överlagringsnätverk av olika Kubernetes-kluster.
Cilium, en plugin för containernätverksgränssnitt, erbjuder klusternätfunktion, 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, berätta för oss.
Vi lägger till din metod i länkarna.
Speciellt tack till Chris Nesbitt-Smith (Chris Nesbitt-Smith) och Vincent de Sme (Vincent De Smet) (tillförlitlighetsingenjör i swatmobile.io) för att läsa artikeln och dela användbar information om hur förbundet fungerar.