Üdvözöljük Kubernetes Quick Start sorozatunkban. Ez egy rendszeres rovat a legérdekesebb kérdésekkel, amelyeket online és képzéseinken kapunk. Kubernetes szakértő válaszol.
A mai szakértő Daniel Polenchik (). Daniel oktatóként és szoftverfejlesztőként dolgozik a cégnél .
Ha kérdésére választ szeretne kapni a következő bejegyzésben, vagy .
Lemaradtál a korábbi bejegyzésekről? .
Hogyan lehet Kubernetes-fürtöket csatlakoztatni a különböző adatközpontokban?
tömören: , és azt is ajánlom, hogy olvassa el и .
Az infrastruktúra gyakran replikálódik és különböző régiók között van elosztva, különösen ellenőrzött környezetben.
Ha az egyik régió nem elérhető, a forgalmat egy másikba irányítják át a fennakadások elkerülése érdekében.
A Kubernetes segítségével hasonló stratégiát használhat, és megoszthatja a munkaterheléseket a különböző régiókban.
Csapatonként, régiónként, környezetenként vagy ezen elemek kombinációjánként egy vagy több fürt lehet.
A fürtök különböző felhőkben és helyszíni környezetben tárolhatók.
De hogyan tervezi meg az infrastruktúrát ilyen földrajzi kiterjedéshez?
Egy nagy fürtöt kell létrehoznia több felhőkörnyezethez egyetlen hálózaton keresztül?
Vagy sok kis klasztere van, és megtalálja a módját ezek vezérlésére és szinkronizálására?
Egy vezetői klaszter
Egy fürt létrehozása egyetlen hálózaton nem is olyan egyszerű.
Képzelje el, hogy balesetet szenvedett, és a fürtszegmensek közötti kapcsolat megszakad.
Ha van egy főkiszolgálója, akkor az erőforrások fele nem tud új parancsokat fogadni, mert nem tudnak kapcsolatba lépni a főkiszolgálóval.
És ugyanakkor vannak régi útválasztó táblái (kube-proxy nem tud letölteni újakat), és nincs további pod (a kubelet nem kérhet frissítéseket).
Tovább rontja a helyzetet, hogy ha a Kubernetes nem lát egy csomópontot, azt árvaként jelöli meg, és a hiányzó podokat szétosztja a meglévő csomópontok között.
Ennek eredményeként kétszer annyi hüvelye van.
Ha minden régióhoz készít egy főkiszolgálót, akkor problémák lesznek az etcd adatbázisban lévő konszenzus algoritmussal. (kb. szerk. — Valójában az etcd adatbázisnak nem kell feltétlenül a főkiszolgálókon található. Ugyanabban a régióban a szerverek külön csoportján futtatható. Igaz, egyúttal a fürt meghibásodási pontját is megszerezve. De gyorsan.)
etcd használ hogy megtárgyalja az értéket, mielőtt lemezre írja.
Ez azt jelenti, hogy a példányok többségének konszenzusra kell jutnia, mielőtt az állapotot az etcd-be írnák.
Ha az etcd-példányok közötti késleltetés drámaian megnő, mint három különböző régióban található etcd-példány esetében, akkor hosszú időt vesz igénybe az érték egyeztetése és a lemezre írása.
Ez tükröződik a Kubernetes vezérlőkben.
A vezérlő menedzsernek több időre van szüksége, hogy megismerje a változást és megírja a választ az adatbázisba.
És mivel nem egy vezérlő van, hanem több, láncreakció következik be, és az egész klaszter nagyon lassan kezd el működni.
Az etcd annyira látenciaérzékeny, hogy .
Jelenleg nincs jó példa egyetlen klaszter nagy hálózatára.
Alapvetően a fejlesztői közösség és a SIG-fürtcsoport azt próbálja kitalálni, hogyan lehet a fürtöket ugyanúgy hangszerelni, mint a Kubernetes a konténereket.
1. lehetőség: fürt-összevonás kubefeddel
Hivatalos válasz a SIG-klasztertől - .
Első alkalommal próbáltuk meg a fürtgyűjteményt egyetlen objektumként kezelni a kube összevonási eszköz segítségével.
A kezdet jó volt, de végül a kube szövetség sosem lett népszerű, mert nem támogatott minden forrást.
Támogatta az egyesített szállításokat és szolgáltatásokat, de például a StatefulSets-et nem.
Ezenkívül az összevonási konfigurációt megjegyzések formájában továbbították, és nem volt rugalmas.
Képzelje el, hogyan tudná leírni a replika particionálását az összevonás egyes fürtjeihez pusztán megjegyzésekkel.
Teljes káosz volt.
A SIG-cluster sokat dolgozott a kubefed v1 után, és úgy döntött, hogy más szemszögből közelíti meg a problémát.
A megjegyzések helyett úgy döntöttek, hogy kiadnak egy vezérlőt, amely a fürtökre van telepítve. Egyéni erőforrás-meghatározások (CRD) segítségével testreszabható.
Minden egyes erőforráshoz, amely az összevonás részét képezi, egyéni CRD-definíciója van három részből:
- egy erőforrás szabványos meghatározása, például telepítés;
- rész
placement, ahol meghatározhatja, hogy az erőforrás hogyan kerüljön elosztásra a szövetségben; - rész
override, ahol egy adott erőforrásnál felülírhatja a súlyt és a paramétereket elhelyezésből.
Íme egy példa egy kombinált szállításra elhelyezési és felülbírálási szakaszokkal.
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: 5Mint látható, a kínálat két klaszter között oszlik meg: cluster1 и cluster2.
Az első fürt három replikát biztosít, a második pedig 5-re van állítva.
Ha jobban szeretné szabályozni a replikák számát, a kubefed2 egy új ReplicaSchedulingPreference objektumot biztosít, ahol a replikák súlyozhatók:
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 struktúra és az API még nincs teljesen készen, a hivatalos projekttárban pedig aktív munka folyik.
Tartsa szemmel a kubefed2-t, de ne feledje, hogy még nem alkalmas gyártásra.
További információ a kubefed2-ről innen a Kubernetesről szóló blogban és in .
2. lehetőség: klaszterek kombinálása Booking.com stílusban
A Booking.com fejlesztői nem dolgoztak a kubefed v2-n, de kitalálták a Shippert – egy operátort, amely több klaszteren, több régióban és több felhőben is szállít.
némileg hasonlít a kubefed2-hez.
Mindkét eszköz lehetővé teszi a többfürtös üzembe helyezési stratégia testreszabását (mely fürtöket használják, és hány replikával rendelkeznek).
De A feladó célja a szállítás során előforduló hibák kockázatának csökkentése.
A Szállítóban meghatározhat egy sor lépést, amelyek leírják a replikák felosztását az előző és a jelenlegi telepítés között, valamint a bejövő forgalom mennyiségét.
Amikor egy erőforrást egy fürtbe küld, a szállítóvezérlő fokozatosan kiadja a változást az összes csatlakoztatott fürtben.
Ezenkívül a szállító nagyon korlátozott.
Például sisak diagramokat fogad be bemenetként és nem támogatja a vaníliaforrásokat.
Általánosságban elmondható, hogy a Shipper így működik.
A normál kézbesítés helyett létre kell hoznia egy alkalmazás-erőforrást, amely egy Helm diagramot tartalmaz:
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 jó lehetőség több fürt kezelésére, de a Helmmel való szoros kapcsolata csak akadályozza.
Mi van, ha mindannyian Helmről váltunk vagy ?
Tudjon meg többet a Shipperről és filozófiájáról itt .
Ha bele akar ásni a kódba, .
3. lehetőség: „varázslatos” fürtegyesítés
A Kubefed v2 és a szállító együttműködik a fürt-összevonással, új erőforrásokat biztosítva a fürtök számára az egyéni erőforrás-definíción keresztül.
De mi van akkor, ha nem akarja átírni az összes szállítást, StatefulSets, DaemonSets stb. egyesítést?
Hogyan vehetünk fel egy meglévő fürtöt a szövetségbe a YAML módosítása nélkül?
, amely a fürtök munkaterhelésének ütemezésével foglalkozik.
De ahelyett, hogy új módot találnának a fürttel való interakcióra és az erőforrások egyéni definíciókba csomagolására, a többfürtös ütemező be van ágyazva a szabványos Kubernetes életciklusba, és elfogja az összes sorba rendezést létrehozó hívást.
Minden létrehozott pod azonnal lecserélődik egy dummyre.
több klaszteres ütemező használat a hívás lehallgatásához és egy tétlen álpad létrehozásához.
Az eredeti pod egy újabb tervezési cikluson megy keresztül, ahol a teljes szövetség lekérdezése után döntés születik az elhelyezésről.
Végül a pod a célcsoporthoz kerül.
Ennek eredményeként van egy extra tok, amely nem csinál semmit, csak helyet foglal.
Előnye, hogy nem kellett új forrásokat írnia a kellékek kombinálásához.
Minden egyes állományt létrehozó erőforrás automatikusan készen áll az összevonásra.
Ez azért érdekes, mert hirtelen több régióban elosztják a készleteket, és észre sem vetted. Ez azonban meglehetősen kockázatos, mert itt minden a varázslaton nyugszik.
De míg a Shipper leginkább a szállítások hatását próbálja mérsékelni, a többfürtös ütemező általánosabb feladatokat kezel, és talán jobban megfelel a kötegelt munkákhoz.
Nem rendelkezik fejlett fokozatos kézbesítési mechanizmussal.
A multi-cluster-ütemezőről bővebben a következő címen olvashat .
Ha szeretne olvasni a multi-cluster-ütemező működéséről, az Admiralty megtette — munkafolyamatok, események, CI és CD Kubernetes.
Egyéb eszközök és megoldások
Több fürt összekapcsolása és kezelése összetett feladat, és nincs univerzális megoldás.
Ha tovább szeretné vizsgálni ezt a témát, íme néhány forrás:
- egy olyan eszköz, amely összekapcsolja a különböző Kubernetes-fürtök átfedő hálózatait.
- Kiskereskedelmi lánc Megcélzott felhasználások .
- Próbáld meg az IPV6 és .
- Használhat például szervizhálót .
- A Cilium, egy konténer hálózati interfész bővítmény kínál , amely lehetővé teszi több klaszter kombinálását
Ez minden mára
Köszönöm, hogy végigolvastad!
Ha tudja, hogyan lehet több klasztert hatékonyabban összekapcsolni, .
Az Ön módszerét hozzáadjuk a linkekhez.
Külön köszönet Chris Nesbitt-Smithnek () és Vincent de Sme () (megbízhatósági mérnök be ) a cikk elolvasásához és a szövetség működésével kapcsolatos hasznos információk megosztásához.
Forrás: will.com