A Kubernetes magas rendelkezésre állása biztosítja, hogy a klaszter meghibásodások esetén is működőképes maradjon. Ez az útmutató bemutatja, hogyan tervezhet és telepíthet egy hibatűrő Kubernetes-klasztert, kitérve a lényeges összetevőkre, a redundanciastratégiákra és a konfigurációs lépésekre.

Legfontosabb elvitelek:

• Miért fontos a magas rendelkezésre állás?: Megelőzi a hardverhibák, hálózati problémák vagy karbantartás okozta leállásokat.
• Alapvető stratégiák:
  • Használjon több vezérlősík-csomópontot az egyetlen meghibásodási pont kiküszöbölésére.
  • A rugalmasság érdekében ossza el a munkacsomópontokat zónák vagy régiók között.
  • Terheléselosztók alkalmazása a forgalom kezelésére és a zökkenőmentes feladatátvétel biztosítására.
• Kritikus alkatrészek:
  • Az API-kiszolgálónak, az etcd adatbázisnak, az ütemezőnek és a vezérlőkezelőknek redundanciára van szükségük.
  • Válasszon a rétegzett vagy a külső etcd topológiák közül a rendszer összetettsége és mérete alapján.
• Telepítési lépések:
  • Használat kubeadm a klaszter beállításához.
  • Konfigurálja a terheléselosztókat, az állapotellenőrzéseket és a munkavégző csomópontokat.
  • Rendszeresen tesztelje a feladatátvételi és biztonsági mentési folyamatokat.

A magas rendelkezésre állás gondos tervezést, robusztus infrastruktúrát és folyamatos tesztelést igényel az állandó teljesítmény és üzemidő biztosítása érdekében.

[ Kube 1.5 ] Nagy rendelkezésre állású Kubernetes klaszter beállítása lépésről lépésre | Keepalived és Haproxy

Nagy rendelkezésre állású Kubernetes klaszter megtervezése

Egy magas rendelkezésre állású (HA) Kubernetes klaszter építésekor kulcsfontosságú, hogy a tervet világos üzleti és technikai célokkal össhangoljuk. Gondos tervezés nélkül egy olyan rendszerhez juthatunk, amely vagy túlbonyolított, vagy túl törékeny ahhoz, hogy megfeleljen a rendelkezésre állási igényeinknek. Az alábbiakban megvizsgáljuk a főbb szempontokat és az architektúrális döntéseket, amelyek segítenek megtalálni a megfelelő egyensúlyt.

Üzleti és műszaki követelmények felmérése

Kezd azzal, hogy meghatározod a leállási időre és az adatvesztésre vonatkozó toleranciádat. Ezek a paraméterek befolyásolják majd a klasztereddel kapcsolatos összes technikai döntésedet.

• Helyreállítási idő célkitűzés (RTO)Ez azt méri, hogy milyen gyorsan kell a rendszereknek helyreállniuk egy meghibásodás után. Például, ha vállalkozása megköveteli, hogy a rendszerek 5 percen belül működőképesek legyenek, akkor automatizált feladatátvételi folyamatokra és előre konfigurált készenléti erőforrásokra lesz szüksége. Másrészt, ha a hosszabb helyreállítási idők elfogadhatóak, választhat egyszerűbb, költséghatékonyabb megoldásokat, amelyek manuális beavatkozást igényelnek.
• Recovery Point Objective (RPO)Ez határozza meg, hogy mennyi adatvesztés elfogadható. Például egy pénzügyi kereskedési platformnak nulla adatvesztésre lehet szüksége, ami szinkron adatreplikációt tesz szükségessé. Eközben egy e-kereskedelmi platform tolerálhat egy kis adathézagot a rendszer bonyolultságának csökkentése érdekében.

Azt is meg kell határoznia, hogy mennyi idő alatt szeretne elérhető lenni. Tájékoztatásul:

• 99,9% üzemidő évente körülbelül 8,77 óra leállást tesz lehetővé.
• 99.99% üzemidő ez nagyjából 52,6 percre csökken.

Ezenkívül vegye figyelembe az alkalmazás forgalmi mintáit és skálázási igényeit. Az előre látható forgalmi csúcsok eltérő stratégiákat igényelnek, mint a hirtelen, kiszámíthatatlan ugrásokat tapasztaló alkalmazások. Az erőforrás-igényes munkaterhelések speciális csomópont-készleteket igényelhetnek testreszabott hardverbeállításokkal, ami befolyásolja a munkaterhelések zónák közötti elosztását.

Ezek a mérőszámok alkotják a klaszterarchitektúra alapját, egyensúlyt teremtve a műszaki hatékonyság és az üzleti igények között. A következő lépés annak meghatározása, hogy a földrajzi eloszlás hogyan befolyásolja a tervet.

Regionális és zonális architektúrák kiválasztása

A klaszter földrajzi elosztásának módja nagy szerepet játszik annak ellenálló képességében. Mind a zónás, mind a regionális architektúrák eltérő előnyöket kínálnak az igényeidtől függően.

• Zonális architektúrákEzek egyetlen régión belül több rendelkezésre állási zónában telepítenek erőforrásokat. Védelmet nyújtanak az egyes adatközpontok meghibásodásai ellen, miközben alacsony késleltetést biztosítanak az összetevők között. Ez a beállítás jól alkalmazható lokalizált problémák, például áramkimaradások vagy hálózati hibák kezelésére egy adott zónán belül.
• Regionális építészetekEzek az erőforrásokat több földrajzi régió között osztják el, védelmet nyújtva a nagyszabású katasztrófák, például természeti események vagy regionális hálózati kimaradások ellen. Ez a megközelítés azonban gyakran nagyobb késleltetést eredményez, ami befolyásolhatja az olyan komponensek teljesítményét, mint az etcd, és a klaszter általános válaszidejét.

A regionális telepítések a globális felhasználói bázissal rendelkező alkalmazásokhoz, vagy akkor működnek a legjobban, ha a szabályozások előírják az adatok adott országokban történő tárolását. Ideálisak olyan szervezetek számára is, amelyek szigorú katasztrófa utáni helyreállítási igényekkel rendelkeznek.

A legtöbb HA beállításnál egy többzónás szabályozási sík kiegyensúlyozott megközelítést kínál. Azáltal, hogy a vezérlősík-csomópontokat egyetlen régión belül három rendelkezésre állási zónában helyezi el, biztosítható, hogy az etcd akkor is fenntartsa a kvórumot, ha az egyik zóna meghibásodik. Ez a megközelítés hibatűrést biztosít a régiók közötti kommunikáció késleltetési hátrányai nélkül.

A munkacsomópontok hasonló eloszlási mintákat követhetnek, de itt nagyobb rugalmasságot biztosítunk. Az állapot nélküli alkalmazások bármely csomóponton futtathatók, míg az állapotalapú munkaterhelések gondos elhelyezést igényelhetnek annak biztosítása érdekében, hogy az adatok továbbra is elérhetők maradjanak, és a teljesítmény konzisztens maradjon.

Hálózati és redundanciakövetelmények

Egy robusztus hálózati stratégia kulcsfontosságú mind az észak-déli forgalom (kliens-klaszter), mind a kelet-nyugati forgalom (klaszterösszetevők közötti kommunikáció) támogatásához. A redundancia több rétegen nem képezheti alku tárgyát.

• Használat több terheléselosztó -vel /egészség zónák között elosztott ellenőrzések. Minden terheléselosztónak képesnek kell lennie a teljes forgalmi terhelés kezelésére, hogy kiküszöbölje az egyszeres meghibásodási pontokat.
• Biztosítsa hálózati útvonal diverzitás a csatlakozási problémák elkerülése érdekében. A zónák közötti forgalomnak több fizikai útvonalon kell keresztülhaladnia, és az Ön felhőszolgáltató vagy adatközpontnak redundáns hálózati infrastruktúrát kell kínálnia.
• Mert DNS és szolgáltatásfelderítés, telepítsen több DNS-kiszolgálót megfelelő TTL-konfigurációkkal a fürt végpontjaihoz. Bár a DNS-alapú terheléselosztás redundanciát eredményez, vegye figyelembe, hogy az ügyféloldali DNS-gyorsítótárazás késleltetheti a feladatátvétel észlelését.

Amikor a állandó kötetek, biztosítsa, hogy a tároló elérhető maradjon zónahibák esetén is. Ez magában foglalhatja a zónák közötti replikációt vagy az elosztott tárolórendszereket. Emellett tervezzen elegendő hálózati sávszélességet az adatszinkronizálás kezeléséhez a helyreállítási események során, különösen nagy adathalmazok esetén.

Ha fontolgatod A Serverion infrastruktúrájaGlobális adatközponti helyszíneik erős támogatást nyújtanak mind a zonális, mind a regionális architektúrákhoz. VPS és dedikált szerveropcióik szilárd számítási alapot biztosítanak a klasztercsomópontok számára, míg tárhelyszolgáltatásaik lehetővé teszik a hibrid telepítéseket, amelyek ötvözik a felhő rugalmasságát a helyszíni beállítások vezérlésével. Ráadásul redundáns hálózati infrastruktúrájukat úgy építették fel, hogy kezelje a nagy rendelkezésre állású klaszterek csatlakozási igényeit, biztosítva, hogy a Kubernetes telepítés rugalmas és megbízható maradjon.

Magas rendelkezésre állású alapvető komponensek és topológiák

Egy nagy rendelkezésre állású Kubernetes klaszter létrehozása azt jelenti, hogy meg kell érteni a rendszer működését biztosító alapvető összetevőket, és el kell dönteni, hogyan rendezzük el őket. Ezek a döntések közvetlenül befolyásolják a klaszter megbízhatóságát, teljesítményét és összetettségét.

A HA legfontosabb Kubernetes-összetevői

A vezérlősík a Kubernetes klaszter gerince. Magában foglalja a következőket: API-kiszolgáló, ütemező, kontroller menedzserek, és stb., amelyek mindegyike kritikus szerepet játszik a működés fenntartásában.

• API-kiszolgálóAz API-kiszolgáló a központi csomópont, amely feldolgozza a kéréseket a következő helyekről: kubectl, munkacsomópontok és egyéb belső komponensek. Több API-kiszolgáló zónákon átívelő futtatása biztosítja, hogy egy kiszolgáló elvesztése ne zavarja meg a klaszter működését.
• ÜtemezőAz ütemező a rendelkezésre álló erőforrások és a meghatározott korlátozások alapján rendeli hozzá a podokat a csomópontokhoz. Bár több ütemezőt is telepíthet redundancia céljából, egyszerre csak egy hoz aktívan döntéseket. Ha az aktív ütemező meghibásodik, egy másik lép közbe.
• KontrollerkezelőkEzek folyamatosan figyelik a klaszter állapotát, biztosítva, hogy az erőforrások a kívánt konfigurációhoz igazodjanak. Vezetőválasztást használnak, így csak egy példány kezeli aktívan az erőforrásokat, míg a biztonsági mentések készen állnak az átvételre, ha szükséges.
• stb.Ez az elosztott kulcs-érték tároló konfigurációs adatokat, titkos kódokat és állapotinformációkat tárol. Konszenzusos algoritmust használ, amely a csomópontok többségét (kvórumot) igényli a működéshez. Például egy háromcsomópontos etcd klaszter képes kezelni egy csomópont elvesztését a funkcionalitás elvesztése nélkül.
• KubeletAz egyes munkacsomópontokon futó kubelet kommunikál az API-kiszolgálóval, hogy fogadja a pod specifikációit és jelentse a csomópont állapotát. Bár maguk a kubeletek nincsenek fürtözötten a magas rendelkezésre állás érdekében, több munkacsomópont megléte biztosítja a munkaterhelések folytatását akkor is, ha egyes csomópontok meghibásodnak.

Miután megértette ezeket az összetevőket, a következő lépés az igényeinek leginkább megfelelő topológia kiválasztása.

HA topológiák: Halmozott vs. külső etcd

A vezérlősík komponenseinek rendszerezésekor két fő lehetőség közül választhatunk, mindegyiknek megvannak a maga kompromisszumai a megbízhatóság és a bonyolultság tekintetében.

• Halmozott etcd topológiaItt az etcd példányok a vezérlősík komponenseivel együtt, ugyanazon a csomóponton helyezkednek el. Ez a beállítás egyszerűbben telepíthető és kevesebb szervert igényel. Azonban kockázatot jelent: ha egy vezérlősík csomópont meghibásodik, mind a vezérlősík szolgáltatásai, mind egy etcd tag elvész.
• Külső etcd topológiaEbben a megközelítésben az etcd a vezérlősíktól elkülönített, dedikált csomópontokon fut. Ez az elkülönítés jobb izolációt biztosít, és lehetővé teszi az erőforrások független skálázását, így jó választás nagyobb vagy igényesebb környezetekhez.

Funkció	Halmozott stb.	Külső stb.
Beállítás bonyolultsága	Könnyebb telepítés és kezelés	Több csomópontot és felügyeletet igényel
Erőforrások elkülönítése	Megosztott erőforrások vezérlősíkkal	Dedikált erőforrások az etcd számára
Hiba hatása	Az etcd és a vezérlősík is érintett	A hibákat függetlenül kezelik
skálázhatóság	Megosztott erőforrások által korlátozva	Független skálázás lehetséges

Kisebb telepítések esetén egy rétegzett topológia egyszerűbb kiindulópontot kínál megfelelő redundanciával. Másrészt a nagyobb klaszterek vagy a szigorú rendelkezésre állási igényekkel rendelkezők profitálhatnak egy külső etcd beállítás fokozott rugalmasságából.

Miután kiválasztotta a topológiát, a következő lépés a terheléselosztók konfigurálása a zökkenőmentes működés biztosítása érdekében.

Terheléselosztó konfigurációja

A terheléselosztók kulcsszerepet játszanak az API-kérések több API-kiszolgáló közötti elosztásában és a feladatátvételek kezelésében, amikor a szerverek leállnak. Enélkül a klienseknek az egyes API-kiszolgáló végpontokat kellene nyomon követniük, ami bonyolítaná a folyamatot.

Egy megfelelően konfigurált terheléselosztónak a következőket kell tennie:

• Végezzen egészségügyi ellenőrzéseket a /egészség minden API-kiszolgáló végpontján. A HTTP 200 válasz a készenlétet jelzi, míg a HTTP 500 problémát jelez. Az állapotellenőrzéseknek 10–15 másodpercenként kell futniuk, 5 másodperces időtúllépéssel a problémák gyors észlelése érdekében.
• A kérések egyenletes elosztása érdekében a Kubernetes API-kiszolgálók állapot nélküliek. A munkamenet-affinitás általában nem szükséges, így a forgalom zökkenőmentesen áramolhat még kiszolgálóhibák esetén is.
• SSL-lezárás kezelése. A TLS-feldolgozást átveheti a terheléselosztón, hogy csökkentse az API-kiszolgálók munkaterhelését, vagy titkosított forgalmat továbbítson a végpontok közötti titkosítás érdekében, ha a megfelelőség megköveteli.

A fokozott redundancia érdekében telepítsen több terheléselosztót különböző zónákban. A DNS-alapú terheléselosztás egy újabb feladatátvételi réteget biztosíthat, de ne feledje, hogy a DNS-gyorsítótárazás késéseket okozhat az átmenetek során.

Ha a Serverion infrastruktúráját használod, az ő dedikált szerverek robusztus vezérlési sík teljesítményt biztosítanak, míg a VPS opciók ideálisak kisebb rendszerek számára. Világszerte adatközpontokkal rendelkezik, a Serverion támogatja a többzónás konfigurációkat, és terheléselosztó eszközöket kínál a forgalom hatékony elosztásához, még kihívást jelentő hálózati körülmények között is.

sbb-itb-59e1987

Lépésről lépésre útmutató: HA Kubernetes telepítése a kubeadm segítségével

Most, hogy ismeri az összetevőket és a topológiákat, itt az ideje felépíteni a nagy rendelkezésre állású Kubernetes-klasztert. Ehhez az útmutatóhoz a kubeadm-et fogjuk használni – ez leegyszerűsíti a telepítést, miközben továbbra is lehetővé teszi a konfiguráció vezérlését.

Infrastruktúra beállítása és előfeltételek

Kezdje azzal, hogy felkészíti az infrastruktúráját az éles munkaterhelések kezelésére.

Legalább három vezérlősík-csomópontra lesz szükséged (minimum: 2 CPU-mag és 4 GB RAM; ajánlott: 4 mag és 8 GB RAM) és legalább két munkacsomópontra (minimum: 1 mag és 2 GB RAM). Telepíts egy támogatott Linux-disztribúciót, például Ubuntu 20.04/22.04-et, CentOS 8-at vagy Rocky Linux 9-et minden csomópontra. Győződj meg róla, hogy minden csomópont egyedi állomásnévvel rendelkezik, és képes kommunikálni a többivel a hálózaton keresztül.

Csere letiltása minden csomóponton, mivel a Kubernetes nem támogatja. Futtassa sudo swapoff -a és kommentelje ki a swap bejegyzéseket /etc/fstab a módosítás véglegesítéséhez. Nyissa meg a szükséges portokat: 6443 (API szerver), 2379-2380 (etcd), 10250 (kubelet) és 10251-10252 (ütemező/vezérlő-kezelő).

Telepítsen egy konténer futásidejű minden csomóponton. A legtöbb felhasználó a containerd-t választja, amely jól támogatott. Konfigurálja úgy, hogy a systemd-t használja cgroup illesztőprogramként, hogy összhangban legyen a Kubernetes alapértelmezett beállításaival. Ezután telepítse a kubeadm, a kubelet és a kubectl csomagokat az összes csomópontra, ügyelve arra, hogy mindegyik ugyanazt a Kubernetes verziót fussa, így elkerülhetők a kompatibilitási problémák.

Állítson be egy terheléselosztó a klaszter inicializálása előtt. A terheléselosztó lehet hardveralapú, egy felhőszolgáltató kínálatának része, vagy egy szoftveres megoldás, mint például a HAProxy. A 6443-as porton kell figyelnie, és a forgalmat továbbítania a vezérlősík csomópontjain található API-kiszolgálókhoz.

Globálisan hibatűrő beállításhoz érdemes dedikált szervereket használni a vezérlősík csomópontjaihoz, és VPS-példányokat a munkacsomópontokhoz.

Vezérlősík csomópontjainak beállítása

Az első vezérlősík-csomópont a klaszter alapja. Parancssori jelzők használata helyett hozz létre egy kubeadm konfigurációs fájlt a HA-beállítások meghatározásához.

Hozz létre egy fájlt, melynek neve kubeadm-config.yaml és adja meg a klaszter konfigurációját. Állítsa be a vezérlősíkVégpont a terheléselosztó címére és portjára. Halmozott etcd topológia esetén a kubeadm automatikusan konfigurálja az etcd-t a vezérlősík csomópontjain. Ha külső etcd-t használ, adja meg a végpontokat ebben a fájlban.

Inicializálja az első vezérlősík csomópontot a következő paranccsal:
sudo kubeadm init --config=kubeadm-config.yaml --upload-certs
A --feltöltési-tanúsítványok A flag leegyszerűsíti a tanúsítványok más vezérlősík-csomópontokra való kiosztásának folyamatát. Ez a lépés néhány percet vesz igénybe, és további csomópontok hozzáadásához illesztési parancsokat fog kimeneti.

Tárold ezeket az illesztési parancsokat biztonságosan – bizalmas tokeneket tartalmaznak. Ezután konfiguráld a kubectl-t az első vezérlősík csomóponton:
mkdir -p $HOME/.kube && sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

További csomópontok hozzáadása előtt telepítsen egy, a környezetének megfelelő CNI bővítményt.

Az inicializálási kimenetből származó join parancs segítségével adja hozzá a fennmaradó vezérlősík-csomópontokat:
sudo kubeadm join load-balancer-ip:6443 --token --discovery-token-ca-cert-hash sha256: --vezérlősík --tanúsítványkulcs
Futtassa ezt a parancsot minden további vezérlősík-csomóponton.

Ellenőrizze, hogy az összes vezérlősík-csomópont működik-e a következő futtatásával:
kubectl csomópontok beolvasása
Az összes csomópontnak „Kész” állapottal kell rendelkeznie a listában.

Az etcd és a terheléselosztók konfigurálása

Finomhangolja az etcd és a terheléselosztó beállításait a HA beállítás befejezéséhez.

Ha egymásra helyezett etcd topológiát használ, a kubeadm automatikusan konfigurálja azt. Külső etcd klaszterek esetén az etcd-t dedikált csomópontokon kell beállítani, biztonságos kommunikációs tanúsítványokat kell generálni, és minden etcd tagot konfigurálni kell a többi felismerésére. Mindig páratlan számú etcd tagot használjon (pl. 3, 5 vagy 7) a kvórum fenntartása érdekében hibák esetén.

Az etcd állapotát a következő futtatásával ellenőrizheti:
sudo kubectl exec -n kube-system etcd- -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key végpont állapota
Minden végpontnak egészségesként kell jelentenie.

Terheléselosztók esetén konfiguráljon állapotellenőrzéseket a következők figyelésére: /egészség végpont az egyes API-kiszolgálók 6443-as portján. Állítsa az intervallumot 10 másodpercre 5 másodperces időtúllépéssel, és gondoskodjon arról, hogy a nem megfelelő állapotú kiszolgálók automatikusan eltávolításra és újra hozzáadásra kerüljenek, amikor helyreállnak.

A terheléselosztó teszteléséhez állítsa le az API-kiszolgálót egy vezérlősík-csomóponton (sudo systemctl stop kubelet) és ellenőrizze, hogy a kubectl parancsok továbbra is működnek-e. Indítsa újra a szolgáltatást, és győződjön meg arról, hogy a csomópont újra csatlakozik a fürthöz.

Ha több terheléselosztót használ, konfigurálja őket aktív-passzív beállításban, vagy használjon DNS-körforgásos multiplexelést a kezdeti terheléselosztáshoz. Dokumentálja a feladatátvételi eljárásokat, amelyek segítenek csapatának a terheléselosztóval kapcsolatos problémák kezelésében.

Munkavégző csomópontok hozzáadása és a fürt állapotának tesztelése

A munkacsomópontok a klaszter gerincét alkotják, és számítási teljesítményt biztosítanak az alkalmazásai számára. Hozzáadásuk egyszerű, de teszteléssel biztosítható a klaszter rugalmassága.

Használd a kezdeti kubeadm beállítás során megadott worker node join parancsot:
sudo kubeadm join load-balancer-ip:6443 --token --discovery-token-ca-cert-hash sha256:
Ha a token lejárt, létrehozhat egy újat.

Ellenőrizd, hogy a munkacsomópontok sikeresen csatlakoztak-e a következő futtatásával:
kubectl csomópontok beolvasása
Minden csomópontnak „Kész” állapotot kell mutatnia. Ha egy csomópont „NotReady” állapotban marad, vizsgálja meg a kubelet naplókat a következővel:
sudo journalctl -u kubelet -f

Telepítsen egy tesztalkalmazást a fürt állapotának megerősítéséhez. Például hozzon létre egy nginx központi telepítést több replikával:
kubectl hozzon létre egy telepítést nginx-test --image=nginx --replicas=5
Ezután ellenőrizze a pod eloszlását a csomópontok között:
kubectl kap podokat -o széles

Szimuláljon hibákat a HA funkcionalitás teszteléséhez. Vezérlősík-csomópontok esetén állítsa le a kubelet szolgáltatást egy csomóponton, és ellenőrizze, hogy a kubectl parancsok továbbra is működnek-e. Ha háromnál több vezérlősík-csomópontja van, próbáljon meg két csomópontot egyszerre leállítani – a klaszternek működőképesnek kell maradnia, amíg a csomópontok többsége egészséges.

Munkacsomópontok esetén szimuláljon egy hibát egy csomópont lezárásával és lecsapolásával:
kubectl kordon && kubectl drain --ignore-daemonsets --delete-emptydir-data
Figyeld meg, ahogy a Kubernetes átütemezi a podokat más csomópontokra.

A klaszter összetevőinek monitorozása a következővel:
kubectl komponensállapotok lekérése és kubectl get pods -n kube-system
Minden rendszerpodnak futnia kell, és az összetevőknek egészséges állapotot kell jelenteniük. A folyamatos monitorozáshoz használjon olyan eszközöket, mint a Prometheus, hogy idővel nyomon kövesse a metrikák változását.

Ne felejtsd el beállítani etcd és tanúsítványmentésekRendszeresen tesztelje a biztonsági mentési és visszaállítási eljárásait nem termelési környezetben, hogy biztosítsa azok hatékonyságát.

Miután a nagy rendelkezésre állású Kubernetes-klasztere működőképes és tesztelt, készen áll a folyamatos működés támogatására és a rutinszerű karbantartás magabiztos elvégzésére.

Ajánlott gyakorlatok a HA Kubernetes műveletekhez

Egy nagy rendelkezésre állású Kubernetes-klaszter beállítása csak az első lépés. Ahhoz, hogy hatékonyan és megbízhatóan működjön, a folyamatos monitorozásra, tesztelésre és a működési legjobb gyakorlatokra kell összpontosítania. Ezek a lépések segítenek fenntartani a teljesítményt, elkerülni az állásidőt, és biztosítani, hogy a klaszter rugalmas maradjon.

Felügyelet és karbantartás

A hatékony monitorozás a magas rendelkezésre állás (HA) gerince. Használjon olyan eszközöket, mint a Prométheusz és Grafana a kulcsfontosságú mutatók, például a CPU-használat, a memória-fogyasztás, a hálózati késleltetés és az etcd teljesítményének nyomon követéséhez. Fordítson különös figyelmet az etcd állapotára azáltal, hogy monitorozási mutatók például a vezetőválasztások, a javaslathibák és a lemez I/O késleltetése. Állítson be riasztásokat a kritikus küszöbértékekhez – például, ha a CPU-használat meghaladja a 80%-t több csomóponton, vagy ha az etcd késleltetése meghaladja a 100 ms-ot, azonnali beavatkozásra van szükség. Használja rendszeresen a etcdctl végpont állapota parancsot annak biztosítására, hogy az összes etcd tag szinkronizálva legyen és megfelelően működjön.

Tartsd naprakészen a Kubernetes komponenseidet strukturált ütemterv szerint. Tervezz negyedéves frissítéseket a kisebb kiadásokhoz, és alkalmazd azokat. biztonsági javítások amint elérhetővé válnak. A frissítéseket mindig teszteld egy előzetes telepítés előtt egy átmeneti környezetben. Frissítéskor az etcd-t és a Kubernetes-t külön kezeld a kockázatok minimalizálása érdekében – soha ne frissítsd mindkettőt egyszerre.

A tanúsítványkezelés egy másik kritikus terület. A Kubernetes tanúsítványok jellemzően egy év után lejárnak, ezért elengedhetetlen az automatikus megújítás. Használjon olyan eszközöket, mint a... kubeadm vagy tanúsítványkezelő a megújítások kezelésére és a lejárati dátumok szoros figyelemmel kísérésére. Havonta tesztelje a megújítási folyamatokat, hogy elkerülje a lejárt tanúsítványok okozta váratlan leállásokat.

Központosítsa a naplóösszesítést olyan eszközökkel, mint például Fluentd vagy Folyékony bitEz megkönnyíti az események összekapcsolását a csomópontok és komponensek között az incidensekre adott válaszok során. Ezen monitorozási és karbantartási gyakorlatok bevezetésével korán felismerheti a potenciális problémákat, segítve a klaszter rendelkezésre állásának védelmét.

Hibatűrő és biztonsági mentési eljárások tesztelése

A monitorozás önmagában nem elég – a feladatátvételi és biztonsági mentési folyamatokat is szigorúan tesztelni kell. Végezzen havi hibainjektálási teszteket a valós hibák szimulálására. Például állítsa le a vezérlősík csomópontjait, hozzon létre hálózati partíciókat, vagy terhelje túl a munkacsomópontokat, hogy lássa, hogyan reagál a rendszere. Kövesse nyomon az egyes forgatókönyvek helyreállítási idejét, és törekedjen azok csökkentésére.

Rendszeresen tesztelje az etcd biztonsági mentési és visszaállítási eljárásait az adatok integritásának biztosítása érdekében. Végezze el ezeket a teszteket egy külön környezetben a pontosság ellenőrzése és a visszaállításhoz szükséges idő mérése érdekében. Ha a visszaállítási folyamat meghaladja a helyreállítási idő célkitűzését (RTO), fontolja meg a gyorsabb tárolási megoldásokat vagy az eljárások egyszerűsítését. Automatizálja az etcd biztonsági mentéseit hatóránként, és tárolja azokat elosztott helyeken a fokozott biztonság érdekében.

Az alkalmazásszintű feladatátvételi tesztelés ugyanilyen fontos. Használjon olyan eszközöket, mint a Káosz majom vagy Lakmusz hogy véletlenszerűen leállítsa a podokat vagy csomópontokat munkaidőben. Ez segít azonosítani, hogy az alkalmazásai képesek-e a hibákat a felhasználók befolyásolása nélkül kezelni.

Készítsen részletes runbookokat a gyakori hibaforgatókönyvekhez. Ezeknek tartalmazniuk kell lépésről lépésre kidolgozott helyreállítási utasításokat, eszkalációs kapcsolattartókat és döntési fákat a különböző típusú incidensekhez. Frissítse ezeket a dokumentumokat minden incidens után, és tesztelje őket különböző csapattagokkal az érthetőség és a használhatóság biztosítása érdekében.

A biztonsági mentések ellenőrzése túlmutat a biztonsági mentések egyszerű létrehozásán. Rendszeresen állítsa vissza a fürt állapotát elszigetelt környezetekben, és ellenőrizze, hogy az alkalmazások a várt módon működnek-e. Teszteljen teljes fürt-visszaállításokat, valamint egyedi névtér-helyreállításokat, hogy felkészüljön a különféle katasztrófaforgatókönyvekre.

HA alkalmazások tervezése

Ahhoz, hogy az alkalmazások sikeresen működjenek egy HA környezetben, a rendelkezésre állást szem előtt tartva kell megtervezni őket. Pod Disruption Budgets (PDB-k) segítsen biztosítani, hogy karbantartás vagy skálázás során minimális számú replika maradjon elérhető. Kritikus szolgáltatások esetén állítsa be percElérhető egy adott számú replikára, nem pedig egy százalékra.

Használjon affinitásellenes szabályokat az egyszeres meghibásodási pontok megelőzésére. podAntiAffinity, a replikákat különböző csomópontok vagy rendelkezésre állási zónák között terjesztheti ki. Állapotalapú alkalmazások, például adatbázisok esetén az affinitás elleni védelmet a topológia-eloszlási korlátozásokkal kombinálhatja a munkaterhelések egyenletes elosztása érdekében.

Az erőforrás-kérelmeket és -korlátokat a tényleges használati adatok alapján konfigurálhatja. Ez biztosítja, hogy a Kubernetes ütemező intelligensebb elhelyezési döntéseket hozhasson, és elkerülje az erőforrás-versengést. Tekintse át és módosítsa ezeket az értékeket negyedévente a monitorozási adatok alapján.

Az állapotellenőrzések létfontosságú szerepet játszanak az alkalmazások készenlétének fenntartásában. Használjon élőségi vizsgálatokat a nem reagáló folyamatok észlelésére, és készenléti vizsgálatokat a forgalomirányítás kezelésére. Finomhangolja az időtúllépési értékeket az egyensúly megteremtése érdekében – a túlságosan agresszív beállítások szükségtelen újraindításokat okozhatnak, míg az enyhébb beállítások lehetővé tehetik, hogy a hibás podok továbbra is fogadjanak forgalmat.

Amikor csak lehetséges, az alkalmazásokat állapot nélkülire tervezzük. A munkamenet-adatokat külső rendszerekben, például Redis vagy adatbázisokban a memóriában tárolt adatok helyett. Ez lehetővé teszi a podok újraindítását vagy skálázását a felhasználói munkamenetek befolyásolása nélkül. Az állapotot igénylő alkalmazásokhoz használjon StatefulSets-eket perzisztens kötetekkel, és gondoskodjon az adatok zónák közötti replikálásáról. Ezek a stratégiák a rugalmas infrastruktúrával párosítva segítenek biztosítani, hogy az alkalmazásai továbbra is elérhetők maradjanak.

Használata ServerionHA Kubernetes infrastruktúrája

A Serverion globális adatközpont-hálózata leegyszerűsíti a földrajzi eloszlást, ami a magas rendelkezésre állás kulcsfontosságú eleme. A valódi redundancia elérése érdekében telepítsen vezérlősík-csomópontokat több régióban. Dedikált szervereik biztosítják az etcd-klaszterekhez szükséges konzisztens teljesítményt, míg a VPS-példányok költséghatékony skálázhatóságot kínálnak a munkacsomópontok számára.

A Serverion dedikált szerverei ideálisak vezérlősík-csomópontokhoz, mivel kiküszöbölik a „zajos szomszéd” hatást, biztosítva a kiszámítható teljesítményt. A megfelelőségi követelményekkel vagy meglévő hardverbefektetésekkel rendelkező szervezetek számára a Serverion tárhelyszolgáltatásai hibrid architektúrákat tesznek lehetővé. Ez a beállítás lehetővé teszi a helyszíni infrastruktúra kombinálását az adatközpontjaikkal, nagy sávszélességű kapcsolatok támogatásával a valós idejű adatreplikáció és a zökkenőmentes feladatátvétel érdekében.

A Serverion több adatközpont-elhelyezkedése a katasztrófa utáni helyreállítást is robusztusabbá teszi. Állítson be készenléti klasztereket különböző régiókban, és használjon olyan eszközöket, mint a Velero alkalmazásszintű biztonsági mentésekhez, amelyek klaszterek között visszaállíthatók. DNS-tárhelyszolgáltatásaik lehetővé teszik az automatikus feladatátvételt a DNS-rekordok frissítésével, amikor egy elsődleges webhely offline állapotba kerül.

Ezenkívül a Serverion infrastruktúra szintű védelmet kínál és SSL tanúsítványszolgáltatások a külső és belső forgalom biztonságossá tételére egyaránt. Szerverfelügyeleti szolgáltatásaik kezelik a hardverfelügyeletet, az operációs rendszer frissítéseit és az alapvető biztonsági feladatokat, lehetővé téve csapata számára, hogy a Kubernetes-specifikus műveletekre összpontosítson. A funkciók ezen kombinációja szilárd alapot biztosít a HA Kubernetes klaszterek karbantartásához.

Következtetés

Minden tervezési döntés és működési lépés hozzájárul egy megbízható Kubernetes klaszter létrehozásához. Egy nagy rendelkezésre állású Kubernetes rendszer felépítése átgondolt tervezést, stabil kivitelezést és folyamatos karbantartást igényel mind a rugalmasság, mind a teljesítmény megőrzése érdekében.

A megfelelő topológia kiválasztása és egy megbízható terheléselosztó beállítása biztosítja a zavartalan API-hozzáférést. Sok szervezet számára a rétegzett vezérlősík-modell jó egyensúlyt teremt az egyszerűség és a megbízhatóság között. Az olyan eszközök, mint a kubeadm, megkönnyítik a telepítést és segítenek a tanúsítványok hatékony kezelésében.

A működési siker a proaktív monitorozástól, a rendszeres feladatátvételi gyakorlatoktól és az olyan funkciókkal rendelkező alkalmazások tervezésétől függ, mint a Pod Disruption Budgets és az affinitás elleni szabályok. Ezek az intézkedések segítenek abban, hogy a munkaterhelések az infrastruktúra leállása esetén is stabilak maradjanak, biztosítva a megbízható teljesítményt.

A Serverion globális infrastruktúrája újabb megbízhatósági réteget ad ehhez a stratégiához. A földrajzi diverzitás és az erős katasztrófa-helyreállítási lehetőségek, valamint a dedikált szerverek révén segítenek fenntartani az egységes vezérlősík-teljesítményt több adatközpontban.

GYIK

Mi a különbség a halmozott és a külső etcd beállítások között a Kubernetesben, és hogyan válasszam ki a legjobbat a klaszteremhez?

A legfontosabb különbség a következők között: halmozott és külső stbd A konfigurációk abban rejlenek, hogy hol működik az etcd adatbázis, és hogyan történik a kezelése. Egymásra épülő rendszerben az etcd ugyanazon a csomópontokon fut, mint a Kubernetes vezérlősík-összetevők. Ez a módszer könnyebben megvalósítható és olcsóbb, de kompromisszummal jár: egy csomópont meghibásodása mind a vezérlősíkot, mind az etcd-t befolyásolhatja, ami jelentős zavarokat okozhat.

Ezzel szemben egy külső etcd topológia az etcd-t különálló, dedikált gépeken helyezi el. Ez a megközelítés növeli a rugalmasságot és a teljesítményt, különösen nagyobb vagy éles üzemű klaszterek esetén. Ugyanakkor nagyobb bonyolultsággal is jár a konfiguráció és a folyamatos karbantartás tekintetében.

Kisebb vagy kevésbé kritikus Kubernetes környezetek esetén egy egymásra épülő rendszer jellemzően megfelel az igényeknek. Nagyméretű vagy nagy rendelkezésre állású éles klaszterek esetén azonban a külső etcd az előnyben részesített megoldás a megbízhatóság és a stabilitás fenntartása érdekében.

Melyek a legjobb gyakorlatok egy nagy rendelkezésre állású Kubernetes-klaszter monitorozására és karbantartására az üzemidő-célok elérése érdekében?

Ahhoz, hogy a Kubernetes klaszter zökkenőmentesen működjön és megfeleljen az üzemidőre vonatkozó elvárásoknak, három kritikus réteget kell figyelnie: infrastruktúra, platform, és alkalmazásokAz olyan eszközök, mint a Prometheus, segíthetnek a lényeges mutatók nyomon követésében, míg a Grafana megkönnyíti az adatok vizualizációját. Fordítson különös figyelmet olyan mutatókra, mint a CPU-használat, a memória-fogyasztás, a pod-újraindítások és a hibaszázalékok. A riasztások beállításával gyorsan észreveheti és kezelheti a problémákat, mielőtt azok eszkalálódnának.

A fürt beállításakor tartsa be a bevált gyakorlatokat. szerep alapú hozzáférés-vezérlés (RBAC) az engedélyek hatékony kezelése, az erőforrások névterekbe rendezése a jobb struktúra érdekében, valamint több vezérlősík-csomópont telepítése terheléselosztókkal a hibatűrés javítása érdekében. A legújabb Kubernetes verzióra való rendszeres frissítés és a proaktív karbantartás ütemezése ugyanilyen fontos. Ezek az intézkedések nemcsak az állásidőt csökkentik, hanem biztosítják, hogy a klaszter az üzleti igényeknek megfelelően skálázható legyen.

Hogyan tervezhetem meg az alkalmazásaimat magas rendelkezésre állásra egy Kubernetes klaszterben?

Ahhoz, hogy alkalmazásai zökkenőmentesen fussanak egy Kubernetes klaszterben, kezdje a beállítással több replika az alkalmazásod Kubernetes Deployments segítségével. Ez elosztja a munkaterhelést, és biztosítja, hogy az alkalmazásod megszakítások nélkül tudja kezelni a pod hibákat.

Egy másik hasznos eszköz a Pod Disruption költségvetésEz a funkció segít minimális számú aktív pod fenntartásában frissítések vagy karbantartás során, csökkentve az állásidőt. A még nagyobb megbízhatóság érdekében telepítse a klasztert a következő helyekre: több zóna vagy régióEz a beállítás megvédi az alkalmazásait a helyi leállásoktól és növeli a redundanciát.

Ezekkel a módszerekkel a Kubernetes rendszered rugalmasabb lesz, biztosítva a stabil teljesítményt még akkor is, ha zavarok merülnek fel.

Kapcsolódó blogbejegyzések

• Hibatűrő adattárolás adatfolyamokhoz: alapok
• Adatbázis feladatátvételi tesztelése: legfontosabb lépések
• NGINX Config for DevOps: A szerver trükkje a leállás nélküli telepítésekhez
• Automatikus skálázás Kubernetes munkaterhelésekhez