Velkommen til en serie af korte vejledninger om Kubernetes. Dette er en regelmæssig kolonne med de mest interessante spørgsmål, vi modtager online og på vores træninger. Besvaret af en Kubernetes-ekspert.
Dagens ekspert er Daniele Polencic (). Daniele arbejder som instruktør og softwareudvikler hos .
Hvis du vil have svar på dit spørgsmål i det næste indlæg, eller på .
Gik du glip af de tidligere indlæg? .
Hvordan forbinder man Kubernetes-klynger i forskellige datacentre?
Kort fortalt: , og jeg anbefaler også at læse om og .
Ofte bliver infrastrukturen replikeret og distribueret på tværs af forskellige regioner, især i kontrollerede miljøer.
Hvis én region er utilgængelig, omdirigeres trafikken til en anden for at undgå nedetid.
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 elementer.
Dine klynger kan være placeret i forskellige cloud-tjenester og lokalt.
Men hvordan planlægger man infrastrukturen til en sådan geografisk spredning?
Skal man skabe en stor klynge på tværs af flere cloud-miljøer med et samlet netværk?
Eller skal man oprette mange små klynger og finde en måde at kontrollere og synkronisere dem på?
En ledende klynge
At oprette en klynge på et samlet netværk er ikke så nemt.
Forestil dig, at der sker en uheld, og forbindelsen mellem segmenterne i klyngen er tabt.
Hvis du har én masterserver, vil halvdelen af ressourcerne ikke kunne modtage nye kommandoer, fordi de ikke kan oprette forbindelse til masteren.
Og på samme tid har du gamle routing-tabeller (kube-proxy kan ikke hente nye) og ingen ekstra pods (kubelet kan ikke anmode om opdateringer).
Det bliver endnu værre; hvis Kubernetes ikke ser en node, markerer den den som tabt og fordeler de manglende pods til de eksisterende noder.
Resultatet er, at du har dobbelt så mange pods.
Hvis du opretter én masterserver for hver region, vil der være problemer med consensus-algoritmen i etcd-databasen.bem. red. — Faktisk skal et etcd-database ikke nødvendigvis være på masterserverne. Den kan køre på en separat gruppe servere i en region. Men så får man også et punkt for klyngefejl. Men det er hurtigt.)
etcd bruger , for at blive enige om værdien, før den skrives til disk.
Det vil sige, at de fleste instanser skal opnå konsensus, før tilstanden kan skrives til etcd.
Hvis forsinkelsen mellem etcd-instanserne pludselig stiger, som i tilfældet med tre etcd-instanser i forskellige regioner, tager det lang tid at blive enige om værdien og skrive den til disk.
Dette påvirker også Kubernetes-controllere.
Controller-manageren har brug for mere tid til at registrere ændringen og skrive svaret til databasen.
Og eftersom der ikke kun er én controller, men flere, giver det en kædereaktion, og hele klyngen begynder at arbejde meget langsomt..
etcd er så følsom over for forsinkelse, at .
Der findes i øjeblikket ikke gode eksempler på et stort netværk for én klynge.
Generelt forsøger udviklerfællesskabet og SIG-cluster-gruppen at finde ud af, hvordan man orkestrerer klynger, på samme måde som Kubernetes orkestrerer containere.
Mulighed 1: klyngefederation med kubefed.
Det officielle svar fra SIG-cluster er, .
For første gang forsøgte man at administrere en samling klynger som én enhed ved hjælp af værktøjet kube federation.
Starten var god, men til slut blev kube federation ikke populær, fordi den ikke understøttede alle ressourcer.
Den understøttede sammenflettede distributionsmetoder og tjenester, men for eksempel ikke StatefulSets.
Og desuden blev konfigurationen af federation overført i form af annotationer, hvilket ikke var særligt fleksibelt.
Forestil dig, hvordan man kan beskrive opdeling af replikaer for hver klynge i federation ved hjælp af kun annotationer.
Det blev en fuldstændig rod.
SIG-cluster har lavet et stort stykke arbejde efter kubefed v1 og besluttede at tage en anden tilgang til problemet.
I stedet for annotationer besluttede de at udgive en controller, der installeres på klyngerne. Den kan konfigureres med brugerdefinerede ressourceoplysninger (Custom Resource Definition, CRD).
For each resource that will be part of the federation, you have a custom CRD definition consisting of three sections:
- standard resource definition, such as deployment;
- section
placement, where you define how the resource will be distributed in the federation; - section
override, where for a specific resource you can override the weight and parameters from placement.
Here is an example of a combined 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: 5As you can see, the deployment is distributed across two clusters: cluster1 og cluster2.
The first cluster supplies three replicas, while the second has a value of 5 set.
If you need more control over the number of replicas, kubefed2 provides 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: 2The CRD structure and API are still not quite ready, and active work is being done in the official project repository.
Keep track of kubefed2, but remember that it is not yet suitable for production environments.
Learn more about kubefed2 from in the Kubernetes blog and in the .
Option 2: merging clusters in the style of Booking.com
The developers of Booking.com did not work on kubefed v2, but they came up with Shipper — an operator for deployment across multiple clusters, in multiple regions and in multiple clouds.
Somewhat similar to kubefed2.
Both tools allow configuring a deployment strategy across multiple clusters (which clusters are used and how many replicas they have).
Men The task of Shipper is to reduce the risk of errors during deployment.
In Shipper, you can define a series of steps that describe the division of replicas between the previous and current deployments and the volume of incoming traffic.
When you send a resource to a cluster, the Shipper controller gradually deploys this change across all the merged clusters.
Moreover, Shipper is very limited.
For eksempel, it accepts Helm charts as input. og ikke understøtter vanilla-ressourcer.
Generelt fungerer Shipper på følgende måde.
I stedet for standardlevering 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 dens tætte integration med Helm gør det kun besværligt.
Hvad nu hvis vi alle skifter fra Helm til eller ?
Lær mere om Shipper og dets filosofi i .
Hvis du vil dykke ned i koden, .
Mulighed 3: "magisk" sammensmeltning af klynger
Kubefed v2 og Shipper arbejder med federation af klynger, hvilket giver klynger nye ressourcer gennem brugerdefinerede ressourcebeskrivelser.
Men hvad hvis du ikke ønsker at omskrive alle leverancer, StatefulSets, DaemonSets osv. for at fusionere?
Hvordan inkluderer man en eksisterende klynge i en federation uden at ændre YAML?
, der arbejder med planlægningsarbejdsbelastninger i klynger.
Men i stedet for at finde på en ny måde at interagere med klyngen og indkapsle ressourcer i brugerdefinerede beskrivelser, integreres multi-cluster-scheduler i Kubernetes' standard livscyklus og opfanger alle opkald, der opretter pods.
Hver oprettet pod bliver straks erstattet med en dummy.
multi-cluster-scheduler bruger , for at opfange opkaldet og oprette en inaktiv pod-dummy.
Den oprindelige pod går igennem endnu en planlægningscyklus, hvor der træffes beslutningen om placering efter at have forespurgt hele federation.
Til sidst leveres pod'en til den ønskede klynge.
Resultatet er, at du har en ekstra pod, der ikke laver noget, bare fylder plads.
Fordelen er, at du ikke behøvede at skrive nye ressourcer til at fusionere leverancer.
Hver ressource, der opretter en pod, er automatisk klar til at fusionere.
Det er interessant, for pludselig har du forsyninger fordelt over flere regioner, og du bemærker det ikke engang. Dog er det ret risikabelt, da alt her afhænger af magi.
Men hvis Shipper forsøger at mildne konsekvenserne af forsyningerne, udfører multi-cluster-scheduler mere generelle opgaver og passer muligvis bedre til batchjob.
Den har ikke en avanceret mekanisme til trinvise leverancer.
Du kan læse mere om multi-cluster-scheduler på .
Hvis du ønsker at læse om multi-cluster-scheduler i aktion, har Admiralty en – arbejdsgange, hændelser, CI og CD i Kubernetes.
Andre værktøjer og løsninger
At forbinde flere klynger og administrere dem er en kompleks opgave, der ikke har en universel løsning.
Hvis du ønsker at udforske dette emne nærmere, her er nogle ressourcer:
- – et værktøj til at forbinde overlay-netværk mellem forskellige Kubernetes-klynger.
- Detailkæden Target bruger .
- Forsøg at bruge IPV6 og .
- Du kan bruge service mesh, såsom .
- Cilium, en netværksplugin til containere, tilbyder , som gør det muligt at kombinere flere klynger.
Det er alt for i dag.
Tak fordi du læste med til slut!
Hvis du kender en bedre måde at forbinde flere klynger på, .
Vi tilføjer din metode til links.
Særlig tak til Chris Nesbitt-Smith () og Vincent De Smet () (reliability engineer hos ) for at have læst artiklen og delt nyttige oplysninger om, hvordan federation fungerer.
Kilde: habr.com
