Tervetuloa Kubernetes Quick Start -sarjaan. Tämä on tavallinen kolumni, jossa on mielenkiintoisimmat kysymykset, joita saamme verkossa ja koulutuksissamme. Kubernetes-asiantuntija vastaa.
Tämän päivän asiantuntija on Daniel Polenchik (). Daniel työskentelee ohjaajana ja ohjelmistokehittäjänä .
Jos haluat vastauksen kysymykseesi seuraavassa postauksessa, tai .
Jäikö aiemmat viestit näkemättä? .
Kuinka yhdistää Kubernetes-klusterit eri datakeskuksissa?
lyhyesti: , ja suosittelen myös lukemaan aiheesta и .
Melko usein infrastruktuuria kopioidaan ja hajautetaan eri alueiden kesken, erityisesti valvotuissa ympäristöissä.
Jos jokin alue ei ole käytettävissä, liikenne ohjataan toiselle häiriön välttämiseksi.
Kubernetesin avulla voit käyttää samanlaista strategiaa ja jakaa työkuormia eri alueilla.
Sinulla voi olla yksi tai useampi klusteri per tiimi, alue, ympäristö tai näiden yhdistelmä.
Klustereitasi voidaan isännöidä useissa pilvissä ja paikan päällä.
Mutta kuinka suunnitella infrastruktuuri tällaiselle maantieteelliselle levinneisyydelle?
Onko sinun luotava yksi suuri klusteri useille pilviympäristöille yhden verkon yli?
Vai onko sinulla monia pieniä klustereita ja löydät tavan hallita ja synkronoida niitä?
Yksi johtamisklusteri
Yhden klusterin luominen yhden verkon yli ei ole niin helppoa.
Kuvittele, että sinulla on onnettomuus, yhteys klusterin segmenttien välillä katkeaa.
Jos sinulla on yksi pääpalvelin, puolet resursseista ei voi vastaanottaa uusia komentoja, koska ne eivät saa yhteyttä isäntäpalvelimeen.
Ja samaan aikaan sinulla on vanhoja reititystaulukoita (kube-proxy ei voi ladata uusia) eikä muita podeja (kubelet ei voi hakea päivityksiä).
Vielä pahempaa, jos Kubernetes ei näe solmua, se merkitsee sen orvoksi ja jakaa puuttuvat podit olemassa oleviin solmuihin.
Tämän seurauksena sinulla on kaksi kertaa enemmän paloja.
Jos teet yhden pääpalvelimen aluetta kohden, etcd-tietokannan konsensusalgoritmin kanssa tulee ongelmia. (noin toim. - Itse asiassa etcd-tietokannan ei tarvitse sijaita pääpalvelimilla. Sitä voidaan käyttää erillisessä palvelinryhmässä samalla alueella. Kuitenkin saatuaan samalla klusterin vikapisteen. Mutta nopeasti.)
etcd käyttää sopia arvosta ennen sen kirjoittamista levylle.
Eli useimpien instanssien on päästävä yksimielisyyteen ennen kuin tila voidaan kirjoittaa jne.
Jos etcd-ilmentymien välinen viive nousee pilviin, kuten kolmen etcd-esiintymän tapauksessa eri alueilla, kestää kauan sopia arvon arvosta ja kirjoittaa se levylle.
Tämä näkyy myös Kubernetes-ohjaimissa.
Ohjaimen johtaja tarvitsee enemmän aikaa perehtyäkseen muutokseen ja kirjoittaakseen vastauksen tietokantaan.
Ja koska ohjain ei ole yksi, vaan useita, saadaan aikaan ketjureaktio ja koko klusteri alkaa toimia hyvin hitaasti.
etcd on niin latenssiherkkä, että .
Tällä hetkellä ei ole olemassa hyviä esimerkkejä yhden klusterin suuresta verkosta.
Pohjimmiltaan kehittäjäyhteisö ja SIG-klusteriryhmä yrittävät selvittää, kuinka klusterit orkestroidaan samalla tavalla kuin Kubernetes orkestroi kontteja.
Vaihtoehto 1: liitä klusterit kubefedillä
Virallinen vastaus SIG-klusterilta - .
Ensimmäistä kertaa yritimme hallita klustereiden kokoelmaa yhtenä objektina käyttämällä kube federation -työkalua.
Alku oli hyvä, mutta lopulta kube federaatiosta ei tullut suosittua, koska se ei tukenut kaikkia resursseja.
Se tuki liittoutuneita tarvikkeita ja palveluita, mutta ei esimerkiksi StatefulSetsia.
Myös liittämismääritys välitettiin huomautusten muodossa, eikä se ollut joustava.
Kuvittele, kuinka voit kuvata replikoiden jakoa liiton kunkin klusterin osalta käyttämällä yhtä huomautusta.
Se osoittautui täydelliseksi sotkuksi.
SIG-klusteri teki hienoa työtä kubefed v1:n jälkeen ja päätti lähestyä ongelmaa toisesta näkökulmasta.
Merkintöjen sijaan he päättivät julkaista klusteriin asennetun ohjaimen. Se voidaan määrittää käyttämällä mukautettuja resurssimäärityksiä (Custom Resource Definition, CRD).
Jokaiselle yhdistettävälle resurssille on oma CRD-määritelmä kolmessa osiossa:
- resurssin vakiomääritelmä, kuten käyttöönotto;
- jakso
placement, jossa määrität, kuinka resurssi jaetaan liitossa; - jakso
override, jossa voit ohittaa tietyn resurssin painon ja parametrit sijoittelusta.
Tässä on esimerkki niputetusta toimituksesta, jossa on sijoitus- ja ohitusosiot.
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: 5Kuten näet, tarjonta on jaettu kahteen klusteriin: cluster1 и cluster2.
Ensimmäinen klusteri tarjoaa kolme kopiota, ja toisen arvo on 5.
Jos tarvitset enemmän replikoiden määrää, kubefed2 tarjoaa uuden ReplicaSchedulingPreference-objektin, jossa replikoita voidaan painottaa:
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-rakenne ja API eivät ole vielä aivan valmiita, ja virallisessa projektivarastossa on käynnissä aktiivinen työ.
Pidä silmällä kubefed2:ta, mutta muista, että se ei ole vielä tarpeeksi hyvä tuotantoympäristöön.
Lisätietoja kubefed2:sta osoitteesta Kubernetes-blogissa ja .
Vaihtoehto 2: Klusterointi Booking.comin tyyliin
Booking.comin kehittäjät eivät käsitelleet kubefed v2:ta, mutta he keksivät Shipperin, operaattorin, joka toimittaa useille klusteille, useille alueille ja useille pilville.
hieman samanlainen kuin kubefed2.
Molempien työkalujen avulla voit mukauttaa usean klusterin käyttöönottostrategiaasi (mitä klustereita käytetään ja kuinka monta replikaa niillä on).
Mutta Lähettäjän tehtävänä on vähentää toimitusvirheiden riskiä.
Shipperissä voit määrittää joukon vaiheita, jotka kuvaavat replikoiden jakautumista edellisen ja nykyisen käyttöönoton välillä sekä saapuvan liikenteen määrää.
Kun työnnät resurssin klusteriin, lähettäjän ohjain ottaa tämän muutoksen käyttöön asteittain kaikkiin hajautettuihin klustereihin.
Myös lähettäjä on erittäin rajoitettu.
Esimerkiksi se ottaa syötteenä Helm-kaavioita eikä tue vaniljavaroja.
Yleisesti ottaen Shipper toimii seuraavasti.
Vakiojakelun sijaan sinun on luotava sovellusresurssi, joka sisältää Helm-kaavion:
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 on hyvä vaihtoehto useiden klustereiden hallintaan, mutta sen läheinen suhde Helmiin vain häiritsee.
Mitä jos me kaikki vaihtaisimme Helmistä tai ?
Lue lisää Shipperistä ja hänen filosofiastaan osoitteessa .
Jos haluat kaivaa koodiin, .
Vaihtoehto 3: "maaginen" klusterin yhdistäminen
Kubefed v2 ja Shipper toimivat klustereiden yhdistämisen kanssa tarjoamalla uusia resursseja klusteille mukautetun resurssimäärityksen avulla.
Mutta entä jos et halua kirjoittaa uudelleen kaikkia yhdistettäviä tarvikkeita, StatefulSets-, DaemonSets- jne.?
Kuinka sisällyttää olemassa oleva klusteri liittoutumiseen muuttamatta YAML:ää?
, joka käsittelee klustereiden työkuormien ajoittamista.
Mutta sen sijaan, että keksittäisiin uusi tapa olla vuorovaikutuksessa klusterin kanssa ja käärittäisiin resurssit mukautetuiksi määrityksiksi, usean klusterin ajoitus lisätään tavalliseen Kubernetesin elinkaareen ja sieppaa kaikki puhelut, jotka luovat podeja.
Jokainen luotu pod korvataan välittömästi nukella.
usean klusterin ajoituskäyttöön siepataksesi puhelun ja luodaksesi tyhjäkäynnillä toimivan valepodin.
Alkuperäinen pod käy läpi toisen aikataulutusjakson, jossa koko liiton kyselyn jälkeen tehdään isännöintipäätös.
Lopuksi pod toimitetaan kohdeklusteriin.
Tämän seurauksena sinulla on ylimääräinen kotelo, joka ei tee mitään, vain vie tilaa.
Etuna on, että sinun ei tarvitse kirjoittaa uusia resursseja tarvikkeiden yhdistämiseen.
Jokainen podin luova resurssi on automaattisesti valmis yhdistettäväksi.
Tämä on mielenkiintoista, koska sinulla on yhtäkkiä tarvikkeita jaettu useille alueille, etkä huomannut. Tämä on kuitenkin melko riskialtista, koska täällä kaikki perustuu taikuuteen.
Mutta vaikka Shipper pyrkii pääasiassa lieventämään lähetysten vaikutuksia, moniklusterisuunnittelija on yleisempi ja sopii ehkä paremmin erätöihin.
Siinä ei ole kehittynyttä asteittaista toimitusmekanismia.
Lisää multi-cluster-schedulerista löytyy osoitteesta .
Jos haluat lukea multi-cluster-schedulerin toiminnasta, Admiralty on tehnyt sen - työnkulut, tapahtumat, CI ja CD Kubernetes.
Muut työkalut ja ratkaisut
Useiden klustereiden yhdistäminen ja hallinta on monimutkainen tehtävä, eikä ole olemassa yhtä kaikille sopivaa ratkaisua.
Jos haluat oppia lisää tästä aiheesta, tässä on joitain resursseja:
- on työkalu, joka yhdistää eri Kubernetes-klusterien peittoverkot.
- Target-kauppaketju käyttää .
- Kokeile käyttää IPV6 ja .
- Voit käyttää esimerkiksi huoltoverkkoa .
- Cilium, konttiverkkoliitäntälaajennus, tarjoaa , jonka avulla voit yhdistää useita klustereita
Siinä kaikki tältä päivältä
Kiitos kun luit loppuun!
Jos tiedät kuinka yhdistää useita klustereita tehokkaammin, .
Lisäämme linkkiin sinun menetelmäsi.
Erityinen kiitos Chris Nesbitt-Smithille () ja Vincent de Sme () (luotettavuusinsinöörille ) artikkelin lukemiseen ja hyödyllisten tietojen jakamiseen liiton toiminnasta.
Lähde: will.com