Üdvözöljük a Kubernetes rövid útmutatók sorozatában. Ez egy rendszeres rovat a legérdekesebb kérdéseinkről, amelyeket online és a tréningjeinken kapunk. A Kubernetes szakértője válaszol.
A mai szakértő — Daniele Polencic (). Daniele oktató és fejlesztő a .
Ha szeretné, hogy a kérdésére a következő bejegyzésben válaszoljunk, Kubernetes Slack-csatornáján. .
Lemaradt a korábbi bejegyzésekről? .
Hogyan lehet összekapcsolni a Kubernetes klasztereket eltérő adatközpontokban?
Röviden: , és azt javaslom, olvassa el a és .
Nagyon gyakran az infrastruktúra replikálva és szétszórva van különböző régiókban, különösen kontrollerált környezetekben.
Ha egy régió nem elérhető, a forgalom áthelyeződik egy másikra, hogy elkerüljük a leállásokat.
A Kubernetes esetében hasonló stratégiát lehet alkalmazni, és el lehet osztani a munkaterheléseket különböző régiók között.
Lehet, hogy egy vagy több klasztere van csapatonként, régiónként, környezetenként vagy ezek kombinációjaként.
A klaszterei különböző felhőkben és helyi környezetben is elhelyezhetők.
De hogyan tervezheti meg az infrastruktúrát egy ilyen földrajzi szórás esetén?
Egy nagy klasztert kell létrehozni több felhői környezetben egyetlen hálózaton?
Vagy sok kis klasztert kell létrehozni, és meg kell találni a módot ezek irányítására és szinkronizálására?
Egy vezető klaszter
Egy klaszter létrehozása egyetlen hálózaton nem olyan egyszerű.
Képzelje el, hogy baleset történik, és elveszik a kapcsolat a klaszter szegmensei között.
Ha van egy mester szervere, a források fele nem fog tudni új parancsokat kapni, mert nem tudnak kapcsolatba lépni a mesterrel.
Ebben az esetben régi iránytáblái (kube-proxy nem tud betölteni újakat) és nincsenek további podok (a kubelet nem tud frissítéseket kérni).
Ami még rosszabb, ha a Kubernetes nem lát egy csomópontot, akkor elveszettként jelöli meg, és az elveszett podokat a meglévő csomópontokra osztja el.
Ennek eredményeként kétszer annyi podot fog kapni.
Ha minden régiónként egy mester szervert hoz létre, problémákba ütközik az etcd adatbázis konszenzus-elérési algoritmusával.Megjegyzés - Az etcd adatbázisnak nem feltétlenül kell a mester szervereken lennie. Egy külön csoport szerveren is futhat egy régión belül. Igaz, hogy ezzel a klaszter hibahelyévé válik. De gyors.)
Az etcd a következőt használja , hogy egyezteti az értékeket, mielőtt azokat a lemezre írnák.
Tehát a legtöbb példánynak konszenzusra kell jutnia, mielőtt az állapotot be lehetne írni az etcd-be.
Ha az etcd példányok közötti késleltetés drámaian megnő, mint például három etcd példány esetén, amelyek különböző régiókban találhatók, sok időbe telik az értékek egyeztetése és a lemezre írása.
Ez a Kubernetes vezérlőire is hatással van.
A vezérlők menedzserének több időbe telik, hogy tudomást szerezzen a változásról, és a választ beírja az adatbázisba.
Mivel nem egy, hanem több vezérlő van, láncreakció alakul ki, és az egész klaszter nagyon lassan kezd működni..
Az etcd annyira érzékeny a késleltetésre, hogy .
Jelenleg nem léteznek jó példák egy nagy hálózatra egy klaszter számára.
Főként a fejlesztői közösség és a SIG-cluster csoport próbálja megérteni, hogyan lehet klasztereket orkestrálni, ahogyan a Kubernetes orkestrálja a konténereket.
1. lehetőség: klaszterek szövetsége kubefed segítségével
A SIG-cluster hivatalos válasza - .
Először próbálták meg egy kollekció klasztereit egységes objektumként kezelni a kube federation eszközzel.
A kezdet jól indult, de végül a kube federation nem vált népszerűvé, mert nem támogatta az összes erőforrást.
Támogatta a frissítéseket és a szolgáltatásokat, de például a StatefulSets-et nem.
Ráadásul a szövetség konfigurációt annotációk formájában adták át, és nem volt rugalmas.
Képzelje el, hogyan lehet minden klaszter számára a replikák szétválasztását annotációk segítségével leírni egy szövetségben.
Teljes káosz lett belőle.
A SIG-cluster nagy munkát végzett a kubefed v1 után, és úgy döntöttek, hogy más megközelítést alkalmaznak.
Az annotációk helyett úgy döntöttek, hogy kiadnak egy vezérlőt, amelyet a klaszterekre telepítenek. Ezt egyéni erőforrás-definíciókkal (Custom Resource Definition, CRD) lehet konfigurálni.
Minden forráshoz, amely a szövetségbe tartozik, van egy felhasználó által meghatározott CRD három szakaszból álló.
- szabványos erőforrásdefiníció, például deploy;
- szakasza
elhelyezés, ahol meghatározza, hogyan lesz az erőforrás elosztva a szövetségben; - szakasza
felülírás, ahol egy adott erőforrás esetén felülírhatók a súly és elhelyezési paraméterek.
Itt van egy példa a kombinált szállításra az elhelyezés és az felülírás részeivel.
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: 5Ahogy látja, a szállítás két klaszterre van elosztva: cluster1 és cluster2.
Az első klaszter három replikát szolgáltat, míg a második esetében az érték 5.
Ha több ellenőrzésre van szüksége a replikák számával kapcsolatban, a kubefed2 új ReplicaSchedulingPreference objektumot kínál, ahol a replikák súly alapján oszthatók el:
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: 2A CRD és az API struktúrája még nem teljesen készen áll, és a projekt hivatalos tárolójában aktívan dolgoznak.
Kövessen minket a kubefed2-nél, de ne feledje, hogy a működési környezethez még nem alkalmas.
Tudjon meg többet a kubefed2-ről a a Kubernetes blogban és a .
2. opción: klaszterek egyesítése a Booking.com stílusában
A Booking.com fejlesztői nem foglalkoztak a kubefed v2-vel, de kitalálták a Shippert, egy operátort, amely több klaszteren, több régióban és több felhőben történő szállításra szolgál.
valamivel hasonló a kubefed2-höz.
Mindkét eszköz lehetővé teszi a több klaszteren való telepítési stratégia beállítását (mely klasztereket használjuk és hány replikájuk van).
sokkal hasznosabb kulcsokkal használni: A Shipper feladata a szállítási hibák kockázatának csökkentése.
A Shipperben meghatározhat egy sor lépést, amelyek leírják a replikák elosztását a korábbi és a aktuális telepítés között és a bejövő forgalom mértékét.
Amikor erőforrást küld a klaszterbe, a Shipper vezérlője fokozatosan telepíti ezt a változást az összes egyesített klaszterre.
A Shipper azonban nagyon korlátozott.
Például, Elfogadja a Helm-chartokat bemeneti adatként. és nem támogatja a vanilla erőforrásokat.
Általánosságban elmondható, hogy a Shipper a következőképpen működik.
A standard szállítás helyett létre kell hozni egy alkalmazás erőforrást, amely tartalmaz egy Helm chart-ot:
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: 3A Shipper nem rossz választás több klaszter kezelésére, de a Helm-mel való szoros kapcsolata csak nehezíti a helyzetet.
Mi lenne, ha mindannyian átállnánk a Helm-ről vagy ?
Tudjon meg többet a Shipper-ről és filozófiájáról a .
Ha bele akar nézni a kódba, .
3. lehetőség: a "varázslatos" klaszterek egyesítése
A Kubefed v2 és a Shipper klaszter-federációval működnek, új erőforrásokat biztosítva a klaszterek számára egyedi erőforrás definíciókon keresztül.
De mi van, ha nem akarja újraírni az összes telepítést, StatefulSet-et, DaemonSet-et stb. az egyesítéshez?
Hogyan lehet egy meglévő klasztert a federációba bevonni YAML megváltoztatása nélkül?
amely a klaszterek terhelésának ütemezésével foglalkozik.
De ahelyett, hogy új módot találnánk a klaszterekkel való interakcióra és erőforrásokat egyedi definíciókba csomagolnánk, a multi-cluster-scheduler integrálódik a Kubernetes szabványos élettartam ciklusába és elfog minden hívást, amely pod-ok létrehozására irányul.
Minden létrehozott pod azonnal egy helyettesítőre cserélődik.
A multi-cluster-scheduler hogy elfogja a hívást és egy inaktív pod helyettesítőt hozzon létre.
Az eredeti pod átmegy egy újabb ütemezési cikluson, ahol a federáció teljes körű áttekintésével hoznak döntést a telepítésről.
Végül a pod a cél klaszterbe kerül.
Végül van egy felesleges pod, amely semmit nem csinál, csak helyet foglal.
Az előny az, hogy nem kellett új erőforrásokat írnia az összesítéshez.
Minden erőforrás, amely pod-ot hoz létre, automatikusan készen áll az egyesítésre.
Ez érdekes, hiszen hirtelen szállítmányok érkeznek több régióból, és talán még nem is vették észre. Azonban ez meglehetősen kockázatos, mert mindez varázslaton alapul.
De ha a Shipper főként azt próbálja enyhíteni, ami a szállítmányok következménye, a multi-cluster-scheduler általánosabb feladatokat lát el, és talán jobban illik a csomagküldési feladatokhoz.
Nincs fejlett, fokozatos szállítmányozási mechanizmusa.
További információ a multi-cluster-scheduler-ről található a .
Ha szeretné látni a multi-cluster-scheduler működését, az Admiralty rendelkezik egy — munkafolyamatokkal, eseményekkel, CI-vel és CD-vel Kubernetesben.
Egyéb eszközök és megoldások
Több klaszter összekapcsolása és kezelése bonyolult feladat, univerzális megoldás nem létezik.
Ha szeretné jobban megismerni ezt a témát, itt van néhány forrás:
- — egy eszköz, amely összekapcsolja a különböző Kubernetes klaszterek overlay-hálózatait.
- A Target kiskereskedelmi hálózat az .
- Próbálja ki az IPV6-ot és .
- Használhat service mesh-t, például .
- A Cilium, a konténerhálózati interfész plugin, kínál , amely lehetővé teszi több klaszter kombinálását.
Ennyi mára.
Köszönöm, hogy végigolvasta!
Ha tudja, hogyan lehet hatékonyabban összekapcsolni több klasztert, .
Hozzáadjuk a módszerét a hivatkozásokhoz.
Külön köszönet Chris Nesbitt-Smith-nek () és Vincent De Smet-nek () (a swatmobile.io megbízhatósági mérnökének) Üdvözöljük a sorozatban.
Forrás: habr.com
