Tere tulemast Kubernetese kiirkäivitussarja. See on tavaline veerg kõige huvitavamate küsimustega, mida saame veebis ja koolitustel. Kubernetese ekspert vastab.
Tänane ekspert on Daniel Polenchik (). Daniel töötab instruktori ja tarkvaraarendajana .
Kui soovite oma küsimusele vastust järgmises postituses, või .
Kas jäid eelmised postitused vahele? .
Kuidas ühendada Kubernetese klastreid erinevates andmekeskustes?
Lühidalt: , ja ma soovitan teil ka lugeda и .
Üsna sageli on infrastruktuur paljundatud ja jaotatud eri piirkondade vahel, eriti kontrollitud keskkondades.
Kui üks piirkond pole saadaval, suunatakse liiklus katkestuste vältimiseks ümber teise.
Kubernetese abil saate kasutada sarnast strateegiat ja jagada töökoormust eri piirkondade vahel.
Teil võib olla üks või mitu klastrit meeskonna, piirkonna, keskkonna või nende kombinatsiooni kohta.
Teie klastreid saab majutada mitmes pilves ja kohapeal.
Kuidas aga planeerida infrastruktuuri sellise geograafilise leviku jaoks?
Kas peate looma ühe suure klastri mitme pilvekeskkonna jaoks ühe võrgu kaudu?
Või teil on palju väikeseid klastreid ja leiate viisi nende juhtimiseks ja sünkroonimiseks?
Üks juhtimisklaster
Ühe klastri loomine ühe võrgu kaudu pole nii lihtne.
Kujutage ette, et teil on õnnetus, ühenduvus klastri segmentide vahel katkeb.
Kui teil on üks peaserver, ei saa pooled ressurssidest uusi käske vastu võtta, kuna nad ei saa ülemserveriga ühendust.
Ja samal ajal on teil vanad marsruutimistabelid (kube-proxy ei saa uusi alla laadida) ja täiendavaid kaustasid pole (kubelet ei saa värskendusi küsida).
Veelgi hullem, kui Kubernetes ei näe sõlme, märgib see selle orvuks ja jagab puuduvad kaustad olemasolevatele sõlmedele.
Selle tulemusena on teil kaks korda rohkem kaunasid.
Kui teete iga piirkonna kohta ühe peaserveri, tekib etcd andmebaasi konsensusalgoritmiga probleeme. (u. toim. - Tegelikult ei pea etcd andmebaas asuma peaserverites. Seda saab käitada samas piirkonnas asuvas eraldi serverirühmas. Kuid olles samal ajal saanud klastri tõrkepunkti. Aga kiiresti.)
etcd kasutab et leppida kokku väärtuses enne selle kettale kirjutamist.
See tähendab, et enamik eksemplare peab jõudma konsensusele, enne kui oleku saab kirjutada jne.
Kui etcd eksemplaride vaheline latentsusaeg tõuseb hüppeliselt, nagu kolme etcd eksemplari puhul erinevates piirkondades, kulub väärtuses kokkuleppimiseks ja kettale kirjutamiseks palju aega.
See kajastub ka Kubernetese kontrollerites.
Kontrolleri haldur vajab rohkem aega, et muudatusest teada saada ja vastuse andmebaasi kirjutada.
Ja kuna kontrollerit pole mitte üks, vaid mitu, tekib ahelreaktsioon ja kogu klaster hakkab väga aeglaselt tööle.
etcd on nii latentsustundlik, et .
Praegu pole häid näiteid suure võrgu kohta ühe klastri jaoks.
Põhimõtteliselt üritavad arendajate kogukond ja SIG-klastri rühm välja mõelda, kuidas klastreid orkestreerida samal viisil, nagu Kubernetes orkestreerib konteinereid.
1. valik: liitklastrid koos kubefediga
Ametlik vastus SIG-klastrilt - .
Esmakordselt proovisime kube ühendamise tööriista abil klastrite kogu hallata ühe objektina.
Algus oli hea, kuid lõpuks ei saanud kube föderatsioon populaarseks, sest ei toetanud kõiki ressursse.
See toetas ühendatud tarneid ja teenuseid, kuid mitte näiteks StatefulSetsi.
Samuti anti föderatsiooni konfiguratsioon märkuste kujul ja see ei olnud paindlik.
Kujutage ette, kuidas saate ühe märkuse abil kirjeldada föderatsiooni iga klastri koopiate jaotust.
See osutus täielikuks jamaks.
SIG-klaster tegi pärast kubefed v1 kasutamist suurepärast tööd ja otsustas läheneda probleemile teise nurga alt.
Märkuste asemel otsustasid nad vabastada kontrolleri, mis on installitud klastritesse. Seda saab konfigureerida kohandatud ressursimääratluste abil (kohandatud ressursi määratlus, CRD).
Iga ühendatava ressursi jaoks on teil kohandatud CRD määratlus kolmes jaotises.
- ressursi standardmääratlus, näiteks juurutamine;
- lõik
placement, kus määrate, kuidas ressurssi föderatsioonis jaotatakse; - lõik
override, kus konkreetse ressursi puhul saate paigutusest lähtuva kaalu ja parameetrite alistada.
Siin on näide komplekteeritud tarne kohta koos paigutuse ja alistamise jaotistega.
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: 5Nagu näete, on pakkumine jagatud kahte klastrisse: cluster1 и cluster2.
Esimene klaster pakub kolme koopiat ja teise koopia väärtus on 5.
Kui vajate rohkem kontrolli koopiate arvu üle, pakub kubefed2 uut ReplicaSchedulingPreference objekti, kus replikaid saab kaaluda:
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: 2CRD struktuur ja API pole veel päris valmis ning ametlikus projektihoidlas käib aktiivne töö.
Hoidke kubefed2-l silma peal, kuid pidage meeles, et see pole veel tootmiskeskkonna jaoks piisavalt hea.
Lisateavet kubefed2 kohta leiate aadressilt Kubernetese ajaveebis ja .
2. valik: Booking.com-i stiilis rühmitamine
Booking.com-i arendajad ei tegelenud kubefed v2-ga, kuid nad leidsid Shipperi, operaatori, kes tarnib mitmes klastris, mitmes piirkonnas ja mitmes pilves.
mõnevõrra sarnane kubefed2-ga.
Mõlemad tööriistad võimaldavad teil kohandada mitme klastri juurutusstrateegiat (millisi klastreid kasutatakse ja kui palju koopiaid neil on).
Kuid Saatja ülesanne on vähendada saatmisvigade riski.
Saates saate määratleda rea samme, mis kirjeldavad koopiate jaotust eelmise ja praeguse juurutuse vahel ning sissetuleva liikluse mahtu.
Kui surute ressursi klastrisse, juurutab saatja kontroller selle muudatuse järk-järgult kõikidesse liitklastritesse.
Ka saatja on väga piiratud.
Näiteks see võtab sisendiks Helmi diagramme ja ei toeta vaniljeressursse.
Üldiselt töötab saatja järgmiselt.
Tavalise distributsiooni asemel peate looma rakenduse ressursi, mis sisaldab Helmi diagrammi:
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: 3Saatja on hea valik mitme klastri haldamiseks, kuid tema lähedane suhe Helmiga segab ainult seda.
Mis siis, kui me kõik Helmi asemel vahetaksime või ?
Lisateavet saatja ja tema filosoofia kohta leiate aadressilt .
Kui soovite koodi süveneda, .
Valik 3: "maagiline" klastri liitmine
Kubefed v2 ja saatja töötavad koos klastri liitmisega, pakkudes kohandatud ressursimääratluse kaudu klastritele uusi ressursse.
Aga mis siis, kui te ei soovi kõiki liidetavaid tarvikuid, StatefulSets, DaemonSets jne ümber kirjutada?
Kuidas kaasata olemasolev klaster föderatsiooni ilma YAML-i muutmata?
, mis käsitleb klastrite töökoormuse ajastamist.
Kuid selle asemel, et leiutada uus viis klastriga suhtlemiseks ja ressursside kohandatud definitsioonidesse mähkimine, sisestatakse Kubernetese standardsesse elutsüklisse mitme klastri planeerija, mis peatab kõik kõned, mis loovad kaustasid.
Iga loodud kaun asendatakse kohe mannekeeniga.
mitme klastri ajakava kasutamine kõne pealtkuulamiseks ja jõudeoleku mannekeeni loomiseks.
Algne pod läbib teise ajastamistsükli, kus pärast kogu föderatsiooni küsitlemist tehakse hostimisotsus.
Lõpuks tarnitakse pod sihtklastrisse.
Selle tulemusena on teil lisakast, mis ei tee midagi, võtab lihtsalt ruumi.
Eeliseks on see, et tarnete kombineerimiseks ei pea te uusi ressursse kirjutama.
Iga ressurss, mis loob podi, on automaatselt liitmiseks valmis.
See on huvitav, sest teil on järsku tarned jaotatud mitmesse piirkonda ja te ei märganud. See on aga üsna riskantne, sest siin toetub kõik maagiale.
Kuid kui Shipper püüab peamiselt leevendada saadetiste mõju, on mitme klastri ajakava üldisem ja võib-olla paremini sobilik partiitööde jaoks.
Sellel puudub täiustatud järkjärguline kohaletoimetamise mehhanism.
Lisateavet mitme klastri ajakava kohta leiate aadressilt .
Kui soovite lugeda mitme klastri ajakava kohta töös, on Admiraliteedil see olemas - töövood, sündmused, CI ja CD Kubernetes.
Muud tööriistad ja lahendused
Mitme klastri ühendamine ja haldamine on keeruline ülesanne ning pole olemas ühtset lahendust, mis sobiks kõigile.
Kui soovite selle teema kohta rohkem teada saada, on siin mõned ressursid:
- on tööriist, mis ühendab erinevate Kubernetese klastrite ülekattevõrke.
- Target jaekett kasutab .
- Proovige kasutada IPV6 ja .
- Võite kasutada näiteks teenindusvõrku .
- Pakutakse konteineri võrguliidese pistikprogrammi Cilium , mis võimaldab ühendada mitu klastrit
See on tänaseks kõik
Aitäh lõpuni lugemise eest!
Kui teate, kuidas mitut klastrit tõhusamalt ühendada, .
Lisame linkidele teie meetodi.
Eriline tänu Chris Nesbitt-Smithile () ja Vincent de Sme () (usaldusinsenerile sisse ) artikli lugemise ja kasuliku teabe jagamise eest liidu toimimise kohta.
Allikas: www.habr.com