Hur man kopplar samman Kubernetes-kluster i olika datacenter

Välkommen till en serie korta vägledningar om Kubernetes. Detta är en regelbunden kolumn med de mest intressanta frågorna som vi får online och under våra utbildningar. Svaren ges av en expert på Kubernetes.

Dagens expert är Daniele Polencic (Daniele Polencic). Daniele arbetar som instruktör och mjukvaruutvecklare på Learnk8s.

Om du vill få svar på din fråga i nästa inlägg, kontakta oss via e-post eller i Twitter: @learnk8s.

Missade du tidigare inlägg? Sök efter dem här.

Hur kopplar man samman Kubernetes-kluster i olika datacenter?

Kortfattat: snart lanseras Kubefed v2, och jag rekommenderar också att läsa om Shipper och -projektet multi-cluster-scheduler..

Ofta replikeras och distribueras infrastrukturen ö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.

Dina kluster kan vara värd i olika moln och i lokala miljöer.

Men hur planerar man infrastrukturen för så stor geografisk spridning?
Ska man skapa ett stort kluster över flera moln i ett enhetligt nätverk?
Eller skapa många små kluster och hitta sätt att kontrollera och synkronisera dem?

Ett ledande kluster

Att skapa ett kluster i ett enhetligt nätverk är inte så enkelt.

Tänk dig att du har en krasch, förbindelsen mellan klustersegmenten har förlorats.

Om du har en enda master-server kan hälften av resurserna inte ta emot nya kommandon eftersom de inte kan nå master-servern.

Och med gamla routingtavlor (kube-proxy kan inte ladda nya) och inga extra poddar (kubelet kan inte begära uppdateringar).

Ännu värre, om Kubernetes inte ser en nod, markerar den den som förlorad och distribuerar de saknade poddarna till befintliga noder.

Resultatet blir att du har dubbelt så många poddar.

Om du har en master-server för varje region kan det uppstå problem med algoritmen för att nå konsensus i databasen etcd.Obs. red. — Faktum är att etcd-databasen inte nödvändigtvis behöver befinna sig på master-servrarna. Den kan köras på en separat grupp servrar i samma region. Men då får man en sårbar punkt i klustret. Å andra sidan går det snabbt.)

etcd använder raft-algoritmen, för att enas om ett värde innan det skrivs till disk.
Det vill säga, de flesta instanser måste nå enighet innan tillståndet kan skrivas till etcd.

Om fördröjningen mellan etcd-instanser ökar kraftigt, som i fallet med tre etcd-instanser i olika regioner, tar det lång tid att enas om värdet och skriva det till disk.
Det återspeglas också på Kubernetes-kontrollerna.

Kontrollernas manager behöver mer tid för att få reda på en ändring och skriva svaret till databasen.

Och eftersom det inte bara finns en kontrollant utan flera, blir det en kedjereaktion, och hela klustret börjar arbeta mycket långsamt..

etcd är så känslig för fördröjning att den officiella dokumentationen rekommenderar att använda SSD istället för vanliga hårddiskar..

Det finns för närvarande inga bra exempel på ett stort nätverk för ett enda kluster.

I huvudsak försöker utvecklarsamhället och SIG-cluster-gruppen förstå hur man orkestrerar kluster på samma sätt som Kubernetes orkestrerar containrar.

Alternativ 1: klusterfederation med kubefed

Det officiella svaret från SIG-cluster är: kubefed2, den nya versionen av den ursprungliga klienten och operatören för kube federation..

Att för första gången försöka hantera en samling kluster som ett enda objekt skedde med hjälp av verktyget kube federation.

Det började bra, men i slutändan blev kube federation aldrig populärt eftersom det inte stödde alla resurser.

Det stödde sammanslagna distributioner och tjänster, men till exempel inte StatefulSets.
Och dessutom överfördes konfigurationen för federation som anteckningar och saknade flexibilitet.

Tänk dig hur man skulle kunna beskriva uppdelningen av repliker för varje kluster i federationen med hjälp av enbart anteckningar.

Det blev en total röra.

SIG-cluster gjorde ett stort arbete efter kubefed v1 och beslutade att ta itu med problemet från ett annat håll.

Istället för anteckningar bestämde de sig för att släppa en kontroller som installeras på klustren. Den kan konfigureras med hjälp av anpassade resursdefinitioner (Custom Resource Definition, CRD).

För varje resurs som kommer att ingå i federation har du en anpassad CRD-definition med tre sektioner:

• standardresursdefinition, till exempel en deployment;
• med pseudoklassomkopplare placement, där du definierar hur resursen ska distribueras i federation;
• med pseudoklassomkopplare override, där du kan åsidosätta vikt och parametrar från placement för en specifik resurs.

Här är ett exempel på en samlad distribution med platser och överskrivningar.

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: 5

Som du ser, är distributionen fördelad över två kluster: cluster1 och cluster2.

Det första klustret tillhandahåller tre repliker, medan det andra är angivet med värdet 5.

Om du behöver mer kontroll över antalet repliker, erbjuder kubefed2 ett nytt objekt ReplicaSchedulingPreference, där repliker kan fördelas efter vikt:

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: 2

Strukturen för CRD och API är fortfarande inte helt färdiga, och det pågår aktivt arbete i projektets officiella repository.

Håll koll på kubefed2, men kom ihåg att det fortfarande inte är lämpligt för produktionsmiljöer.

Läs mer om kubefed2 i den officiella artikeln om kubefed2 i bloggen om Kubernetes och i den officiella repository för projektet kubefed.

Alternativ 2: Sammanfogning av kluster i Booking.com-stil

Utvecklarna av Booking.com har inte arbetat med kubefed v2, men de har utvecklat Shipper – en operatör för distribution över flera kluster, i flera regioner och i flera moln.

Shipper som liknar kubefed2.

Båda verktygen möjliggör konfiguration av distributionsstrategi över flera kluster (vilka kluster som används och hur många repliker de har).

Men Målet med Shipper är att minska risken för fel vid distribution.

I Shipper kan du definiera en serie steg som beskriver fördelningen av repliker mellan den tidigare och aktuella deployment samt mängden inkommande trafik.

När du skickar en resurs till ett kluster, distribuerar Shipper stegvis denna ändring över alla sammanfogade kluster.

Och dessutom är Shipper mycket begränsad.

Till exempel, den tar emot Helm-diagram som ingångsdata. och stöder inte vanilla-resurser.
I allmänhet fungerar Shipper på följande sätt.

Istället för standardleverans måste du skapa en applikationsresurs som inkluderar en 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: 3

Shipper är ett bra alternativ för att hantera flera kluster, men dess nära koppling till Helm gör bara saken svårare.

Men vad händer om vi alla går över från Helm till kustomize eller kapitan?

Läs mer om Shipper och dess filosofi i detta officiella pressmeddelande.

Om du vill gräva i koden, gå till det officiella projektförrådet.

Alternativ 3: "magisk" sammanslagning av kluster

Kubefed v2 och Shipper fungerar med federering av kluster, vilket tillhandahåller nya resurser till kluster genom användardefinierade resurser.

Men tänk om du inte vill skriva om alla leveranser, StatefulSets, DaemonSets osv. för sammanslagning?

Hur man inkluderar ett befintligt kluster i federeringen utan att ändra YAML?

multi-cluster-scheduler är ett projekt från Admirality, som arbetar med arbetsbelastningar för schemaläggning i kluster.

Men istället för att hitta på ett nytt sätt att interagera med klustret och bevara resurser i användardefinitioner, integreras multi-cluster-scheduler i den standardiserade livscykeln för Kubernetes och fångar alla anrop som skapar pods.

Varje skapad pod ersätts omedelbart med en dummy.

multi-cluster-scheduler använder webhooks för att modifiera åtkomsten, för att fånga anropet och skapa en inaktiv pod-dummy.

Den ursprungliga podden går genom ytterligare en schemaläggningscykel, där beslut om placering fattas efter att hela federationen har förfrågats.

Till slut levereras podden till det målinriktade klustret.

Som ett resultat har du en extra podd som inte gör något, bara tar upp plats.

Fördelen är att du inte behövde skriva nya resurser för att slå samman leveranser.

Varje resurs som skapar en pod är automatiskt redo för sammanslagning.

Det är intressant, eftersom du plötsligt får leveranser spridda över flera regioner, utan att du ens märker det. Men det är ganska riskabelt, eftersom allt här vilar på magi.

Men om Shipper försöker i huvudsak mildra konsekvenserna av leveranser, utför multi-cluster-scheduler mer övergripande uppgifter och kan vara bättre lämpad för paketuppdrag.

Det har ingen avancerad mekanism för gradvisa leveranser.

Mer om multi-cluster-scheduler kan du läsa på den officiella repositoriets sida.

Om du vill läsa om multi-cluster-scheduler i praktiken, har Admiralty en intressant användningsfall med Argo — arbetsflöden, händelser, CI och CD i Kubernetes.

Andra verktyg och lösningar

Att koppla samman flera kluster och hantera dem är en svår uppgift, det finns ingen universell lösning.

Om du vill fördjupa dig i detta ämne, här är några resurser:

• Submariner från Rancher — ett verktyg som kopplar samman overlay-nätverk från olika Kubernetes-kluster.
• Detailhandelskedjan Target använder Unimatrix i kombination med Spinnaker för att orkestrera distribution på flera kluster.
• Försök att använda IPV6 och ett enhetligt nätverk i flera regioner..
• Det går att använda service mesh, till exempel Istio för att koppla samman flera kluster..
• Cilium, en plugin för container-nätverksgränssnittet, erbjuder funktionen cluster mesh, vilket gör att du kan kombinera flera kluster.

Det är allt för idag.

Jag försökte att inte skriva för mycket, men ändå blev artikeln enligt min åsikt ganska lång. De andra funktionerna i unRAID är enligt min åsikt ganska enkla att konfigurera, särskilt eftersom allt ställs in med mus.

Om du vet ett effektivare sätt att koppla samman flera kluster, berätta för oss..

Vi lägger till ditt sätt bland länkarna.

Ett särskilt tack till Chris Nesbitt-Smith (Chris Nesbitt-Smith) och Vincent De Smet (Vincent De Smet) (reliability engineer på swatmobile.io) för att de läste artikeln och delade användbar information om hur federation fungerar.

Källa: habr.com