Wolkom by de Kubernetes Quick Start Series. Dit is in reguliere kollum mei de meast nijsgjirrige fragen dy't wy online en yn ús trainingen krije. Kubernetes saakkundige antwurden.
De ekspert fan hjoed is Daniel Polenchik (). Daniel wurket as ynstrukteur en softwareûntwikkelder yn .
As jo in antwurd wolle op jo fraach yn 'e folgjende post, of .
Foarige berjochten mist? .
Hoe kinne jo Kubernetes-klusters ferbine yn ferskate datasintra?
Koartsein: , en ik riede jo ek om te lêzen oer и .
Hiel faak wurdt ynfrastruktuer replikearre en ferdield oer ferskate regio's, foaral yn kontroleare omjouwings.
As ien regio net beskikber is, wurdt ferkear omlaat nei in oare om ûnderbrekkingen te foarkommen.
Mei Kubernetes kinne jo in ferlykbere strategy brûke en workloads fersprieden oer ferskate regio's.
Jo kinne ien of mear klusters hawwe per team, regio, omjouwing, of in kombinaasje fan dizze.
Jo klusters kinne wurde hosted yn ferskate wolken en on-premises.
Mar hoe planje de ynfrastruktuer foar sa'n geografyske sprieding?
Moatte jo ien grut kluster meitsje foar ferskate wolkomjouwings oer ien netwurk?
Of in protte lytse klusters hawwe en in manier fine om se te kontrolearjen en te syngronisearjen?
Ien liederskipskluster
It meitsjen fan ien kluster oer ien netwurk is net sa maklik.
Stel jo foar dat jo in ûngelok hawwe, ferbining tusken klustersegminten is ferlern.
As jo ien master tsjinner, de helte fan de boarnen sil net by steat wêze om te ûntfangen nije kommando's omdat se sille net by steat wêze om kontakt opnimme mei de master.
En tagelyk hawwe jo âlde routingtabellen (kube-proxy kin gjin nije ynlade) en gjin ekstra pods (kubelet kin net freegje foar updates).
Noch slimmer, as Kubernetes gjin knooppunt kin sjen, markearret it it as wees en ferspriedt ûntbrekkende pods nei besteande knooppunten.
As gefolch hawwe jo twa kear safolle pods.
As jo meitsje ien master tsjinner foar eltse regio, der sil wêze problemen mei de konsensus algoritme yn de etcd databank. (ca. ed. - Yn feite, de etcd databank hoecht net te lizzen op de master tsjinners. It kin wurde útfierd op in aparte groep servers yn deselde regio. Lykwols, hawwen krigen tagelyk in punt fan falen fan in kluster. Mar gau.)
etcd brûkt om in wearde iens te meitsjen foardat it op skiif skriuwt.
Dat is, de measte gefallen moatte in konsensus berikke foardat de steat skreaun wurde kin oan ensfh.
As de wachttiid tusken etcd eksimplaren nimt ta dramatysk, lykas it gefal is mei trije etcd eksimplaren yn ferskillende regio, it duorret in lange tiid in ûnderhanneljen in wearde en skriuw it op skiif.
Dit wurdt ek wjerspegele yn Kubernetes-controllers.
De controllerbehearder hat mear tiid nedich om te learen oer de feroaring en it antwurd op 'e databank te skriuwen.
En om't d'r net ien kontrôler is, mar ferskate, in kettingreaksje wurdt krigen, en de hiele kluster begjint te wurkjen hiel stadich.
etcd is sa latency gefoelich dat .
D'r binne op it stuit gjin goede foarbylden fan in grut netwurk foar ien kluster.
Yn prinsipe besykje de ûntwikkeldersmienskip en de SIG-klustergroep út te finen hoe't jo klusters op deselde manier kinne orkestrearje as Kubernetes konteners orkestreart.
Opsje 1: federate klusters mei kubefed
Offisjeel antwurd fan SIG-kluster - .
Foar it earst besochten wy in samling klusters as ien objekt te behearjen mei it kube-federaasje-ark.
It begjin wie goed, mar op it lêst waard kube federaasje net populêr, om't it net alle middels stipe.
It stipe federearre foarrieden en tsjinsten, mar net bygelyks StatefulSets.
Ek waard de federaasjekonfiguraasje trochjûn yn 'e foarm fan annotaasjes en wie net fleksibel.
Stel jo foar hoe't jo de ferdieling fan replika's foar elk kluster yn in federaasje kinne beskriuwe mei ien inkelde annotaasje.
It draaide út op in folsleine rommel.
SIG-cluster die in geweldige baan nei kubefed v1 en besleat om it probleem út in oare hoeke te benaderjen.
Ynstee fan annotaasjes besleaten se in controller frij te litten dy't is ynstalleare op klusters. It kin wurde konfigurearre mei help fan oanpaste boarne definysjes (Custom Resource Definition, CRD).
Foar elke boarne dy't diel útmeitsje fan 'e federaasje hawwe jo in oanpaste CRD-definysje mei trije seksjes:
- in standert definysje fan in boarne, lykas ynset;
- ôfdieling
placement, wêr't jo beskiede hoe't de boarne yn 'e federaasje ferdield wurdt; - ôfdieling
override, wêr foar in spesifike boarne kinne jo oerskriuwe it gewicht en parameters fan pleatsing.
Hjir is in foarbyld fan in bondele levering mei pleatsing en oerskriuwe seksjes.
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: 5Sa't jo sjen kinne, is it oanbod ferdield yn twa klusters: cluster1 и cluster2.
It earste kluster leveret trije replika's, en de twadde hat in wearde fan 5.
As jo mear kontrôle nedich hawwe oer it oantal replika's, leveret kubefed2 in nij ReplicaSchedulingPreference-objekt wêr't replika's kinne wurde gewicht:
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: 2De CRD-struktuer en API binne noch net hielendal klear, en aktyf wurk is oan 'e gong yn' e offisjele projektrepository.
Hâld kubefed2 yn 'e gaten, mar tink dat it noch net goed genôch is foar in produksjeomjouwing.
Learje mear oer kubefed2 fan op de Kubernetes blog en .
Opsje 2: klusters kombinearje yn Booking.com-styl
De ûntwikkelders fan Booking.com dogge net mei kubefed v2, mar se kamen mei Shipper, in operator foar levering op meardere klusters, meardere regio's en meardere wolken.
wat gelyk oan kubefed2.
Beide ark kinne jo jo multi-cluster-ynsetstrategy oanpasse (hokker klusters wurde brûkt en hoefolle replika's se hawwe).
mar De taak fan de skipper is it risiko fan ferstjoerflaters te ferminderjen.
Yn Shipper kinne jo in searje stappen definiearje dy't de ferdieling fan replika's beskriuwe tusken de foarige en aktuele ynset en it folume fan ynkommende ferkear.
As jo in boarne nei in kluster triuwe, set de Shipper-kontrôler dizze feroaring ynkrementeel yn nei alle federearre klusters.
Ek Shipper is tige beheind.
Bygelyks, it akseptearret roer charts as ynfier en stipet gjin vanille-boarnen.
Yn algemiene termen wurket Shipper sa.
Ynstee fan standert levering, moatte jo in applikaasje-boarne meitsje dy't in Helm-diagram omfettet:
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 is in goede opsje foar it behearen fan meardere klusters, mar syn nauwe relaasje mei Helm stiet allinich yn 'e wei.
Wat as wy allegear oerskeakelje fan Helm nei of ?
Learje mear oer Shipper en syn filosofy by .
As jo yn 'e koade wolle grave, .
Opsje 3: "magyske" kluster gearfoegjen
Kubefed v2 en Shipper wurkje mei klusterfederaasje, en leverje nije boarnen oan klusters fia oanpaste boarne-definysje.
Mar wat as jo net alle leveringen, StatefulSets, DaemonSets, ensfh wolle oerskriuwe om te fusearjen?
Hoe kinne jo in besteande kluster opnimme yn federaasje sûnder YAML te feroarjen?
, dy't him dwaande hâldt mei it plannen fan wurkdruk op klusters.
Mar ynstee fan it útfine fan in nije manier om te ynteraksje mei it kluster en it ynpakken fan boarnen yn oanpaste definysjes, wurdt multi-cluster-scheduler ynjeksje yn 'e standert Kubernetes-libbenssyklus en ûnderskept alle oproppen dy't pods meitsje.
Elke oanmakke pod wurdt fuortendaliks ferfongen troch in dummy.
multi-cluster-scheduler brûkt om de oprop te ûnderskeppen en in idle dummy pod te meitsjen.
De orizjinele pod giet troch in oare skemasyklus wêr't, nei it pollen fan 'e heule federaasje, in hostingbeslút wurdt makke.
Uteinlik wurdt de pod levere oan it doelkluster.
As gefolch hawwe jo in ekstra pod dy't neat docht, gewoan romte nimt.
It foardiel is dat jo gjin nije boarnen hoege te skriuwen om foarrieden te kombinearjen.
Elke boarne dy't in pod oanmakket, is automatysk klear om federearre te wurden.
Dit is nijsgjirrich, om't jo ynienen foarrieden hawwe ferdield oer ferskate regio's, en jo hawwe net opmurken. Dit is lykwols frij riskant, om't hjir alles op magy is.
Mar wylst Shipper foaral besiket de effekten fan ferstjoeringen te beheinen, is multi-cluster-scheduler algemiener en miskien better geskikt foar batchbanen.
It hat gjin avansearre meganisme foar graduale levering.
Mear oer multi-cluster-scheduler is te finen op .
As jo wolle lêze oer multi-cluster-scheduler yn aksje, hat Admiraliteit - workflows, eveneminten, CI en CD Kubernetes.
Oare ark en oplossings
Ferbining en behear fan meardere klusters is in komplekse taak, en d'r is gjin universele oplossing.
As jo mear wolle leare oer dit ûnderwerp, binne hjir wat boarnen:
- is in ark dat ferbynt overlay netwurken fan ferskate Kubernetes klusters.
- De Target retailketen brûkt .
- Besykje IPV6 en .
- Jo kinne bygelyks in tsjinstmesh brûke .
- Cilium, in plugin foar kontenernetwurkynterface, biedt , wêrmei jo ferskate klusters kombinearje kinne
Dat is alles foar hjoed
Tankewol foar it lêzen oant it ein!
As jo witte hoe't jo meardere klusters effisjinter kinne ferbine, .
Wy sille jo metoade tafoegje oan 'e keppelings.
Spesjale tank oan Chris Nesbitt-Smith () and Vincent de Sme () (reliability engineer yn ) foar it lêzen fan it artikel en it dielen fan nuttige ynformaasje oer hoe't de federaasje wurket.
Boarne: www.habr.com