Welkom by die Kubernetes Quick Start-reeks. Hierdie is 'n gereelde rubriek met die interessantste vrae wat ons aanlyn en in ons opleiding ontvang. Kubernetes-kundige antwoorde.
Vandag se kenner is Daniel Polenchik (). Daniel werk as 'n instrukteur en sagteware-ontwikkelaar in .
As jy 'n antwoord op jou vraag in die volgende pos wil hê, of .
Vorige plasings gemis? .
Hoe om Kubernetes-klusters in verskillende datasentrums te verbind?
kortliks: , en ek raai jou ook aan om oor te lees и .
Dikwels word infrastruktuur gerepliseer en oor verskillende streke versprei, veral in beheerde omgewings.
As een streek nie beskikbaar is nie, word verkeer na 'n ander herlei om onderbrekings te vermy.
Met Kubernetes kan jy 'n soortgelyke strategie gebruik en werkladings oor verskillende streke versprei.
Jy kan een of meer groepe per span, streek, omgewing of 'n kombinasie hiervan hê.
Jou trosse kan oor verskeie wolke en op die perseel gehuisves word.
Maar hoe om die infrastruktuur vir so 'n geografiese verspreiding te beplan?
Moet u een groot groepering vir verskeie wolkomgewings oor 'n enkele netwerk skep?
Of het jy baie klein groepe en vind 'n manier om hulle te beheer en te sinchroniseer?
Een leierskapgroepering
Dit is nie so maklik om een groep oor 'n enkele netwerk te skep nie.
Stel jou voor jy het 'n ongeluk, konneksie tussen groepsegmente is verlore.
As jy een meesterbediener het, sal die helfte van die hulpbronne nie nuwe opdragte kan ontvang nie omdat hulle nie die meester sal kan kontak nie.
En terselfdertyd het jy ou roeteringstabelle (kube-proxy kan nie nuwes aflaai nie) en geen bykomende peule nie (kubelet kan nie navraag doen vir opdaterings nie).
Nog erger, as Kubernetes nie 'n nodus kan sien nie, merk dit dit as wees gelaat en versprei ontbrekende peule na bestaande nodusse.
As gevolg hiervan het jy twee keer soveel peule.
As jy een meesterbediener per streek maak, sal daar probleme met die konsensusalgoritme in die etcd-databasis wees. (ongeveer. ed. - Trouens, die etcd-databasis hoef nie op die hoofbedieners geleë te wees nie. Dit kan op 'n aparte groep bedieners in dieselfde streek uitgevoer word. Om egter terselfdertyd 'n punt van mislukking van 'n kluster te ontvang. Maar vinnig.)
etcd gebruik om oor 'n waarde ooreen te kom voordat dit op skyf geskryf word.
Dit wil sê, die meeste gevalle moet 'n konsensus bereik voordat die staat aan ens geskryf kan word.
As die latensie tussen etcd-instansies die hoogte inskiet, soos die geval is met drie etcd-instansies in verskillende streke, neem dit lank om oor 'n waarde ooreen te kom en dit op skyf te skryf.
Dit word ook in Kubernetes-beheerders weerspieël.
Die beheerderbestuurder het meer tyd nodig om oor die verandering te leer en die antwoord op die databasis te skryf.
En aangesien die beheerder nie een is nie, maar verskeie, 'n kettingreaksie word verkry, en die hele groep begin baie stadig werk.
etcd is so latency sensitief dat .
Daar is tans geen goeie voorbeelde van 'n groot netwerk vir 'n enkele groepering nie.
Basies probeer die ontwikkelaargemeenskap en die SIG-groepering uitvind hoe om groepe te orkestreer op dieselfde manier as wat Kubernetes houers orkestreer.
Opsie 1: federate clusters met kubefed
Amptelike antwoord van SIG-cluster - .
Vir die eerste keer het ons probeer om 'n versameling groepe as 'n enkele voorwerp te bestuur deur die kube-federasie-instrument te gebruik.
Die begin was goed, maar op die ou end het kube-federasie nie gewild geword nie, want dit het nie alle hulpbronne ondersteun nie.
Dit het gefedereerde voorrade en dienste ondersteun, maar byvoorbeeld nie StatefulSets nie.
Die federasie-konfigurasie is ook in die vorm van aantekeninge deurgegee en was nie buigsaam nie.
Stel jou voor hoe jy die verdeling van replikas vir elke groep in 'n federasie kan beskryf deur 'n enkele aantekening te gebruik.
Dit het geblyk 'n volledige gemors te wees.
SIG-cluster het goeie werk gedoen ná kubefed v1 en besluit om die probleem vanuit 'n ander hoek te benader.
In plaas van aantekeninge, het hulle besluit om 'n beheerder vry te stel wat op groepe geïnstalleer is. Dit kan gekonfigureer word met behulp van pasgemaakte hulpbrondefinisies (Custom Resource Definition, CRD).
Vir elke hulpbron wat gefedereer sal word, het jy 'n pasgemaakte CRD-definisie in drie afdelings:
- 'n standaarddefinisie van 'n hulpbron, soos ontplooiing;
- afdeling
placement, waar jy definieer hoe die hulpbron in die federasie versprei sal word; - afdeling
override, waar jy vir 'n spesifieke hulpbron die gewig en parameters van plasing kan ignoreer.
Hier is 'n voorbeeld van 'n gebundelde aflewering met plasings- en ignoreerafdelings.
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: 5Soos u kan sien, is die aanbod in twee groepe verdeel: cluster1 и cluster2.
Die eerste groep verskaf drie replikas, en die tweede een het 'n waarde van 5.
As jy meer beheer oor die aantal replikas benodig, verskaf kubefed2 'n nuwe ReplicaSchedulingPreference-objek waar replikas geweeg kan word:
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: 2Die CRD-struktuur en API is nog nie heeltemal gereed nie, en aktiewe werk is aan die gang in die amptelike projekbewaarplek.
Hou kubefed2 dop, maar hou in gedagte dat dit nog nie goed genoeg is vir 'n produksie-omgewing nie.
Kom meer te wete oor kubefed2 van op die Kubernetes-blog en .
Opsie 2: Groepering van Booking.com-styl
Die ontwikkelaars van Booking.com het nie met kubefed v2 te doen gehad nie, maar hulle het vorendag gekom met Shipper, 'n operateur vir aflewering op veelvuldige groepe, veelvuldige streke en veelvuldige wolke.
ietwat soortgelyk aan kubefed2.
Beide instrumente laat jou toe om jou multi-kluster-ontplooiingstrategie aan te pas (watter groepe word gebruik en hoeveel replikas hulle het).
Maar Versender se werk is om die risiko van afleweringsfoute te verminder.
In Shipper kan jy 'n reeks stappe definieer wat die verdeling van replikas tussen die vorige en huidige ontplooiings en die hoeveelheid inkomende verkeer beskryf.
Wanneer jy 'n hulpbron na 'n kluster toe stoot, ontplooi die Versender-beheerder daardie verandering inkrementeel na al die gefedereerde clusters.
Versender is ook baie beperk.
Byvoorbeeld, dit neem Helm-kaarte as inset en ondersteun nie vanieljebronne nie.
In algemene terme werk Versender soos volg.
In plaas van 'n standaardverspreiding, moet jy 'n toepassingshulpbron skep wat 'n Helm-grafiek insluit:
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: 3Versender is 'n goeie opsie om veelvuldige groepe te bestuur, maar sy noue verhouding met Helm staan net in die pad.
Wat as ons almal oorskakel van Helm na of ?
Kom meer te wete oor Shipper en sy filosofie by .
As jy in die kode wil delf, .
Opsie 3: "magic" cluster samesmelting
Kubefed v2 en Shipper werk saam met groeperingsfederasie deur nuwe hulpbronne aan groepe te verskaf deur 'n pasgemaakte hulpbrondefinisie.
Maar wat as jy nie al die voorrade, StatefulSets, DaemonSets, ens. wat saamgevoeg moet word, wil herskryf nie?
Hoe om 'n bestaande groepering by federasie in te sluit sonder om YAML te verander?
, wat handel oor die skedulering van werkladings op groepe.
Maar in plaas daarvan om 'n nuwe manier uit te vind om met die groep te kommunikeer en hulpbronne in pasgemaakte definisies te verpak, word multi-kluster-skeduleerder in die standaard Kubernetes-lewensiklus ingespuit en onderskep alle oproepe wat peule skep.
Elke geskepte peul word onmiddellik met 'n dummy vervang.
multi-kluster-skeduleerder gebruike om die oproep te onderskep en 'n ledige dummy pod te skep.
Die oorspronklike peul gaan deur 'n ander skeduleringsiklus waar, nadat die hele federasie gepeil is, 'n gasheerbesluit geneem word.
Uiteindelik word die peul by die teikengroep afgelewer.
As gevolg hiervan het jy 'n ekstra peul wat niks doen nie, net spasie opneem.
Die voordeel is dat jy nie nuwe hulpbronne hoef te skryf om voorrade te kombineer nie.
Elke hulpbron wat 'n peul skep, is outomaties gereed om gefedereer te word.
Dit is interessant, want jy het skielik voorrade wat oor verskeie streke versprei is, en jy het dit nie opgemerk nie. Dit is egter nogal riskant, want hier berus alles op magie.
Maar terwyl Versender hoofsaaklik probeer om die uitwerking van verskepings te versag, is multi-kluster-skeduleerder meer algemeen en miskien beter geskik vir bondeltake.
Dit het nie 'n gevorderde meganisme vir geleidelike aflewering nie.
Meer oor multi-kluster-skeduleerder kan gevind word by .
As jy wil lees oor multi-cluster-skeduleerder in aksie, het Admiraliteit - werkstrome, gebeure, CI en CD Kubernetes.
Ander gereedskap en oplossings
Die koppeling en bestuur van veelvuldige groepe is 'n komplekse taak, en daar is geen een-grootte-pas-almal oplossing nie.
As jy meer oor hierdie onderwerp wil leer, is hier 'n paar hulpbronne:
- is 'n instrument wat oorlegnetwerke van verskillende Kubernetes-klusters verbind.
- Die Target-kleinhandelketting gebruik .
- Probeer om IPV6 en .
- Jy kan byvoorbeeld 'n diensnetwerk gebruik .
- Cilium, 'n houernetwerkkoppelvlak-inprop, bied , wat jou toelaat om verskeie trosse te kombineer
Dis al vir vandag
Dankie dat jy tot die einde gelees het!
As jy weet hoe om veelvuldige trosse meer doeltreffend te verbind, .
Ons sal jou metode by die skakels voeg.
Spesiale dank aan Chris Nesbitt-Smith () en Vincent de Sme () (aan die betroubaarheidsingenieur in ) vir die lees van die artikel en die deel van nuttige inligting oor hoe die federasie werk.
Bron: will.com