Hvordan koble Kubernetes-klynger i forskjellige datasentre

Velkommen til en rekke korte guider om Kubernetes. Dette er en regelmessig spalte med de mest interessante spørsmålene vi får online og på våre kurs. Svar fra Kubernetes-ekspert.

Dagens ekspert er Daniele Polencic (Daniele Polencic). Daniele jobber som instruktør og programvareutvikler hos Learnk8s.

Hvis du vil ha svar på spørsmålet ditt i neste innlegg, kontakt oss via e-post eller inn i Twitter: @learnk8s.

Gikk du glipp av de forrige innleggene? Finn dem her.

Hvordan koble Kubernetes-klynger i forskjellige datasentre?

Kort sagt: kommer Kubefed v2 snart, og jeg anbefaler å lese om Shipper og prosjektet multi-cluster-scheduler..

Det er ganske vanlig at infrastrukturen replikeres og distribueres over forskjellige regioner, spesielt i kontrollerte miljøer.

Hvis én region går ned, blir trafikken omdirigert til en annen for å unngå avbrudd.

Med Kubernetes kan vi bruke en lignende strategi og fordele arbeidsbelastninger over forskjellige regioner.

Du kan ha én eller flere klynger per team, region, miljø, eller en kombinasjon av disse elementene.

Klyngene dine kan være plassert i forskjellige skyer og i lokale miljøer.

Men hvordan planlegger du infrastrukturen for så stort geografisk spredning?
Burde du opprette én stor klynge over flere skymiljøer med ett felles nettverk?
Eller opprette mange små klynger og finne en måte å administrere og synkronisere dem på?

Én styrende klynge

Å opprette én klynge med ett felles nettverk er ikke så enkelt.

Tenk deg at du har en feil, og tilkoblingen mellom segmentene av klyngen er tapt.

Hvis du har én master-server, vil halve ressursene ikke kunne motta nye kommandoer fordi de ikke kan kontakte masteren.

Og da har du gamle rutetabeller (kube-proxy kan ikke laste inn nye) og ingen ekstra pod-er (kubelet kan ikke be om oppdateringer).

Hva verre er, hvis Kubernetes ikke ser noden, merker den den som tapt og fordeler manglende pod-er til eksisterende noder.

Resultatet er at du ender opp med dobbelt så mange pod-er.

Hvis du lager én master-server i hver region, vil det oppstå problemer med algoritmen for å oppnå konsensus i etcd-databasen.red. — Faktisk trenger ikke etcd-databasen å være på master-serverne. Den kan kjøres på en egen gruppe servere i én region. Men dette fører til et punktsvikt i klyngen. På den positive siden går det raskt.)

etcd bruker raft-algoritmen, for å oppnå konsensus før verdien skrives til disk.
Det vil si at flertallet av instansene må bli enige før tilstanden kan skrives til etcd.

Hvis forsinkelsen mellom etcd-instansene øker betydelig, slik som med tre etcd-instanser i forskjellige regioner, tar det lang tid å oppnå konsensus og skrive verdien til disk.
Dette gjenspeiles også i Kubernetes-kontrollere.

Kontrollereren trenger mer tid for å registrere endringen og skrive svaret til databasen.

Og siden det ikke bare er én, men flere controllere, blir det en kjedereaksjon, og hele klyngen begynner å fungere veldig sakte..

etcd er så sensitivt for forsinkelse at den offisielle dokumentasjonen anbefaler å bruke SSD-er i stedet for vanlige harddisker..

Det finnes for øyeblikket ikke gode eksempler på store nettverk for én klynge.

Hovedsakelig prøver fellesskapet av utviklere og SIG-cluster-gruppen å finne ut hvordan man skal orkestrere klynger på samme måte som Kubernetes orkestrerer containere.

Alternativ 1: klyngefederasjon med kubefed

Det offisielle svaret fra SIG-cluster er kubefed2, den nye versjonen av den originale klienten og kube federasjonsoperatøren..

For første gang prøvde man å administrere en samling klynger som ett objekt med hjelp av verktøyet kube federation.

Starten var god, men til slutt ble kube federation ikke populært fordi det ikke støttet alle ressurser.

Det støttet sammenflettede forsyninger og tjenester, men for eksempel ikke StatefulSets.
I tillegg ble konfigurasjonen av fedreasjonen levert som annotasjoner og var ikke spesielt fleksibel.

Tenk deg hvordan man kan beskrive replikeringsdeling for hver klynge i fedreasjonen med bare annotasjoner.

Det ble et fullstendig kaos.

SIG-cluster har gjort et stort arbeid etter kubefed v1 og besluttet å nærme seg problemet fra en annen vinkel.

I stedet for annotasjoner besluttet de å utgi en kontroller som installeres på klyngene. Den kan konfigureres ved hjelp av Custom Resource Definition (CRD).

For each resource that will be part of the federation, you have a custom CRD definition consisting of three sections:

• the standard resource definition, such as a deployment;
• med bryteren for pseudoklassen placement, where you define how the resource will be distributed within the federation;
• med bryteren for pseudoklassen override, where the weight and parameters from placement can be overridden for a specific resource.

Here's an example of a federated deployment with placement and override sections.

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

As you can see, the deployment is distributed across two clusters: cluster1 og cluster2.

The first cluster provides three replicas, while the second has a value of 5.

If you need more control over the number of replicas, kubefed2 offers a new object called ReplicaSchedulingPreference, where replicas can be distributed by weight:

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

The CRD structure and API are not quite ready, and active work is ongoing in the official project repository.

Keep an eye on kubefed2, but remember that it is not suitable for production environments yet.

Learn more about kubefed2 from the official article on kubefed2 in the Kubernetes blog and in the official kubefed project repository..

Option 2: merging clusters in the style of Booking.com

Developers at Booking.com did not work on kubefed v2, but they created Shipper — an operator for deployment across multiple clusters, across various regions and clouds.

Shipper similar to kubefed2.

Both tools allow you to configure a deployment strategy across multiple clusters (which clusters are used and how many replicas they have).

Men The task of Shipper is to minimize the risk of errors during deployment.

In Shipper, you can define a series of steps that describe the distribution of replicas between the previous and current deployment and the volume of incoming traffic.

When you send a resource to a cluster, the Shipper controller gradually rolls out this change across all federated clusters.

Moreover, Shipper is very limited.

For eksempel, it accepts Helm charts as input. og ikkje støttar vanilla ressursar.
Generelt fungerer Shipper slik:

I staden for standard levering, må du opprette ei applikasjonsressurs som inkluderer ein Helm-chart:

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 er ein god løysing for å administrere fleire klynger, men den tette forbindelsen til Helm kan vere ein hindring.

Kva om vi alle går frå Helm til (forresten, utviklingen hans foregår nå i et eget repository), altså for behandling av tillegg YAML-filer fra spesielle kustomiseringsmapper (detaljer om deres bruk finnes i eller kapitan?

Lær meir om Shipper og filosofien bak i denne offisielle pressemeldinga.

Om du vil dykke ned i koden, gå til det offisielle prosjektlageret.

Alternative 3: «magisk» samanslåing av klynger

Kubefed v2 og Shipper fungerer med føderasjonen av klynger og gir klyngene nye ressursar gjennom brukardefinerte ressursar.

Men kva om du ikkje vil skrive om alle leveransar, StatefulSets, DaemonSets, osv. for å slå saman?

Korleis inkludere ein eksisterande klynge i føderasjonen utan å endre YAML?

multi-cluster-scheduler er eit prosjekt frå Admirality, som handterer planlegging av arbeidslastar i klynger.

Men i staden for å finne opp ein ny måte å interagere med klyngen på og pakke ressursar inn i brukardefinerte definisjonar, integrerer multi-cluster-scheduler seg i den vanlege livssyklus-prosedyrane til Kubernetes og fanger alle kall som opprettar poddar.

Kvar pod som blir oppretta, blir straks erstatta med ein plassholder.

multi-cluster-scheduler bruker web-hooks for å modifisere tilgangen, for å fange opp kallet og lage ein inaktiv pod-plassholder.

Den originale podden går gjennom eit nytt planleggingssyklus, der det blir fatta ei avgjerd om plassering etter å ha spurt heile føderasjonen.

Til slutt blir podden levert til den målretta klynga.

Resultatet er at du har ei overflødig podd, som ikkje gjer noko, berre tar opp plass.

Fordelen er at du slepp å skrive nye ressursar for å slå saman leveransane.

Kvar ressurs som opprettar ein podd, er automatisk klar til samanslåing.

Det er interessant, for plutselig har du leveranser fordelt over flere regioner, men du har ikke lagt merke til det. Men, dette er ganske risikabelt, for her holder alt på magi.

Men hvis Shipper prøver å dempe konsekvensene av leveransene, utfører multi-cluster-scheduler mer generelle oppgaver og kan kanskje være bedre egnet for batch-jobber.

Den har ikke en avansert mekanisme for gradvise leveranser.

Mer om multi-cluster-scheduler kan du lese på siden til det offisielle depotet.

Hvis du vil lese om multi-cluster-scheduler i aksjon, har Admiralty et interessant bruksområde med Argo – arbeidsflyter, hendelser, CI og CD i Kubernetes.

Andre verktøy og løsninger

Å koble sammen flere klynger og administrere dem er en kompleks oppgave; det finnes ingen universell løsning.

Hvis du vil utforske dette emnet nærmere, her er noen ressurser:

• Submariner fra Rancher – et verktøy som forbinder overlay-nettverk fra forskjellige Kubernetes-klynger.
• Detaljhandelskjeden Target bruker Unimatrix sammen med Spinnaker for å orkestrere distribusjonen på flere klynger.
• Prøv å bruke IPV6 og et felles nettverk i flere regioner.
• Du kan bruke service mesh, for eksempel Istio for å forbinde flere klynger.
• Cilium, en nettverksplugin for containere, tilbyr cluster mesh-funksjonen, som gjør det mulig å kombinere flere klynger

Det er alt for i dag

Takk for at du leste helt til slutt!

Hvis du har tips om hvordan man bedre kan koble sammen flere klynger, fortell oss.

Vi vil legge til metoden din til lenkene.

Spesiell takk til Chris Nesbitt-Smith (Chris Nesbitt-Smith) og Vincent De Smet (Vincent De Smet) (reliability engineer at swatmobile.io) for å ha lest artikkelen og delt nyttig informasjon om hvordan federasjonen fungerer.

Kilde: habr.com