Note. iwwersat.: dëst Material ass vun engem pädagogesche Projet ass d'Äntwert op eng populär Fro beim Design vun Kubernetes-baséiert Infrastruktur. Mir hoffen, datt zimlech detailléiert Beschreiwunge vun de Vir- an Nodeeler vun all Optioun Iech hëllefen déi bescht Wiel fir Äre Projet ze maachen.
TL; DR: dee selwechte Set vun Aarbechtslaascht kann op e puer grousse Cluster lafen (all Cluster wäert eng grouss Unzuel vun Aarbechtslaascht hunn) oder op ville klengen (mat enger klenger Unzuel un Aarbechtsbelaaschtungen an all Cluster).
Drënner ass eng Tabell déi d'Virdeeler an Nodeeler vun all Approche evaluéiert:
Wann Dir Kubernetes als Plattform benotzt fir Uwendungen ze lafen, entstinn e puer fundamental Froen dacks iwwer d'Intricacies vun der Opstellung vu Cluster:
- Wéi vill Cluster soll ech benotzen?
- Wéi grouss soll ech se maachen?
- Wat soll all Cluster enthalen?
An dësem Artikel wäert ech probéieren all dës Froen ze beäntweren andeems Dir d'Virdeeler an Nodeeler vun all Approche analyséiert.
Erklärung vun enger Fro
Als Softwareentwéckler entwéckelt a bedreift Dir wahrscheinlech vill Uwendungen zur selwechter Zäit.
Zousätzlech si vill Instanzen vun dësen Uwendungen méiglecherweis a verschiddenen Ëmfeld lafen - zum Beispill kënnen dës sinn dev, Test и prod.
D'Resultat ass eng ganz Matrix vun Uwendungen an Ëmfeld:
Uwendungen an Ëmfeld
D'Beispill hei uewen stellt 3 Uwendungen an 3 Ëmfeld duer, wat am Ganzen 9 méiglech Optiounen resultéiert.
All Applikatioun Instanz ass eng selbststänneg Deployment Eenheet mat där onofhängeg vun aneren geschafft ka ginn.
notéiert dat Applikatioun Instanz kann aus ville besteet Komponenten, wéi Frontend, Backend, Datebank, etc. Am Fall vun enger Mikroservicer Applikatioun enthält d'Instanz all Mikroservicer.
Als Resultat hu Kubernetes Benotzer verschidde Froen:
- Sollen all Applikatioun Instanzen an engem Cluster gesat ginn?
- Ass et derwäert e separaten Cluster fir all Applikatiounsinstanz ze hunn?
- Oder vläicht sollt eng Kombinatioun vun den uewe genannten Approche benotzt ginn?
All dës Optiounen sinn zimlech liewensfäeg, well Kubernetes e flexibele System ass deen d'Fäegkeeten vum Benotzer net limitéiert.
Hei sinn e puer vun de méigleche Weeër:
- ee grousse gemeinsame Stärekoup;
- vill kleng héich spezialiséiert Stärekéip;
- ee Stärekoup pro Applikatioun;
- ee Stärekoup pro Ëmfeld.
Wéi hei ënnendrënner, sinn déi éischt zwou Approche um Géigendeel Enn vun der Skala vun Optiounen:
Vun e puer grouss Cluster (lénks) bis vill kleng (riets)
Am Allgemengen gëtt ee Stärekoup als "méi grouss" ugesinn wéi en aneren wann et eng méi grouss Zomm vu Wirbelen a Pods huet. Zum Beispill, e Stärekoup mat 10 Noden an 100 Pods ass méi grouss wéi e Stärekoup mat 1 Node an 10 Pods.
Ma, loosst eis ufänken!
1. Ee grousse gemeinsame Stärekoup
Déi éischt Optioun ass all Aarbechtslaascht an engem Cluster ze placéieren:
Ee grousse Cluster
An dëser Approche gëtt de Cluster als Universal benotzt Infrastruktur Plattform - Dir deploy einfach alles wat Dir braucht an engem existente Kubernetes Cluster.
Kubernetes erlaabt Deeler vum Cluster logesch vuneneen ze trennen, sou datt all Applikatiounsinstanz säin eegene Nummraum kann hunn.
Loosst eis d'Virdeeler an Nodeeler vun dëser Approche kucken.
+ Effizient Notzung vu Ressourcen
Mat engem eenzege Cluster brauch Dir nëmmen eng Kopie vun all de Ressourcen, déi néideg sinn fir de Kubernetes Cluster ze lafen an ze managen.
Zum Beispill, ass dëst wouer fir Master Wirbelen. Typesch huet all Kubernetes Stärekoup 3 Meeschterknäppchen, sou datt fir een eenzege Cluster hir Zuel esou bleift (zum Verglach, 10 Cluster brauche 30 Meeschterknoten).
Déi uewe genannte Subtilitéit gëllt och fir aner Servicer, déi iwwer de ganze Cluster operéieren, sou wéi Lastbalancer, Ingress Controller, Authentifikatioun, Logging an Iwwerwaachungssystemer.
An engem eenzege Cluster kënnen all dës Servicer gläichzäiteg fir all Aarbechtslaascht benotzt ginn (et ass net néideg fir Kopien vun hinnen ze kreéieren, sou wéi de Fall mat multiple Cluster).
+ Bëlleg
Als Konsequenz vun der uewen, manner Cluster sinn normalerweis méi bëlleg well et keng Overhead Käschten sinn.
Dëst ass besonnesch wouer fir Master Noden, déi e wesentleche Betrag u Sue kënne kaschten, egal wéi se gehost ginn (op der Plaz oder an der Wollek).
E puer geréiert Kubernetes Servicer, wéi z oder , liwwert d'Kontrollschicht gratis. An dësem Fall ass d'Käschte vum Problem manner akut.
Et ginn och geréiert Servicer déi e fixe Betrag fir d'Operatioun vun all Kubernetes Cluster berechnen (zum Beispill, ).
+ Effikass Administratioun
Ee Cluster ze managen ass méi einfach wéi e puer ze managen.
Administratioun kann déi folgend Aufgaben enthalen:
- Kubernetes Versioun Update;
- Opstellung vun enger CI/CD Pipeline;
- Installatioun vum CNI Plugin;
- Astelle vun engem Benotzer Authentifikatioun System;
- Installatioun vun engem Zougang Controller;
a vill anerer ...
Am Fall vun engem Cluster musst Dir dëst alles nëmmen eemol maachen.
Fir vill Cluster musse Operatioune vill Mol widderholl ginn, wat méiglecherweis e puer Automatisatioun vu Prozesser an Tools erfuerdert fir Konsistenz a Konsistenz am Prozess ze garantéieren.
An elo e puer Wierder iwwert d'Nodeeler.
- Eenzege Punkt vun Echec
Am Fall vun Refus den eenzegen de Stärekoup wäert ophalen direkt ze schaffen all dat Aarbechtsbelaaschtungen!
Et gi vill Weeër wéi d'Saache falsch kënne goen:
- d'Aktualiséierung vu Kubernetes féiert zu onerwaarte Nebenwirkungen;
- E Cluster-breet Komponent (Zum Beispill, e CNI Plugin) fänkt un net wéi erwaart ze schaffen;
- ee vun de Stärekoup Komponente ass net richteg konfiguréiert;
- Feeler an der Basisdaten Infrastruktur.
Een esou Tëschefall kann e grousse Schued un all Aarbechtslaascht verursaachen, déi an engem gemeinsame Cluster gehost ginn.
- Keng steiwe Isolatioun
Lafen an engem gemeinsame Cluster bedeit datt Uwendungen d'Hardware, d'Netzwierkfäegkeeten an de Betribssystem op de Clusternoden deelen.
An engem Sënn sinn zwee Container mat zwou verschiddenen Uwendungen déi um selwechten Node lafen, wéi zwee Prozesser déi op der selwechter Maschinn lafen déi deeselwechten OS Kernel lafen.
Linux Behälter bidden eng Form vun Isolatioun, awer et ass net bal sou staark wéi déi vu virtuelle Maschinnen. Am Wesentlechen ass e Prozess an engem Container dee selwechte Prozess deen um Hostbetribssystem leeft.
Dëst kann e Sécherheetsprobleem sinn: Dës Arrangement erlaabt theoretesch onrelatéierten Uwendungen mateneen ze kommunizéieren (entweder bewosst oder zoufälleg).
Zousätzlech deelen all Aarbechtslaascht an engem Kubernetes Cluster e puer Cluster-breet Servicer wéi - dëst erlaabt Uwendungen d'Servicer vun aneren Uwendungen am Cluster ze fannen.
All déi uewe genannte Punkte kënnen ënnerschiddlech Bedeitungen hunn ofhängeg vun den Uwendungssécherheetsufuerderunge.
Kubernetes bitt verschidde Tools fir Sécherheetsprobleemer ze vermeiden wéi z и . Wéi och ëmmer, se richteg opzestellen erfuerdert eng gewëssen Erfahrung; Zousätzlech kënnen se net absolut all Sécherheetslächer zoumaachen.
Et ass wichteg ëmmer ze erënneren datt Kubernetes ursprénglech fir entworf gouf deelen, net fir Isolatioun a Sécherheet.
- Mangel u strenge Multi-Locatioun
Wéinst der Iwwerfloss vu gemeinsame Ressourcen an engem Kubernetes Cluster, ginn et vill Weeër fir verschidden Uwendungen openeen op d'Zänn ze trëppelen.
Zum Beispill kann eng Applikatioun eng gemeinsam Ressource monopoliséieren (wéi CPU oder Erënnerung) an aner Applikatiounen, déi um selwechten Node lafen, den Zougang dozou verweigeren.
Kubernetes bitt verschidde Mechanismen fir dëst Verhalen ze kontrolléieren, wéi z (kuckt och den Artikel ""- ca. Iwwersetzung), и . Wéi och ëmmer, wéi am Fall vu Sécherheet, ass hir Konfiguratioun zimmlech net trivial a si kënnen net absolut all onerwaart Nebenwirkungen verhënneren.
- Grouss Zuel vu Benotzer
Am Fall vun engem eenzege Stärekoup musst Dir Zougang zu vill Leit opmaachen. A wat hir Zuel méi grouss ass, dest méi héich ass de Risiko datt se eppes "briechen".
Am Cluster kënnt Dir kontrolléieren wien wat maache kann mat (kuckt Artikel ""- ca. Iwwersetzung). Wéi och ëmmer, et verhënnert d'Benotzer net eppes bannent de Grenze vun hirem Verantwortungsberäich ze "briechen".
- Cluster kënnen net onbestëmmt wuessen
De Stärekoup dee fir all Aarbechtslaascht benotzt gëtt wäert wahrscheinlech zimlech grouss sinn (wat d'Zuel vun den Noden a Pods ugeet).
Awer hei entsteet en anere Problem: Cluster zu Kubernetes kënnen net onbestëmmt wuessen.
Et gëtt eng theoretesch Limit op der Clustergréisst. Zu Kubernetes ass et ongeféier .
Allerdéngs, am richtege Liewen, Problemer kann vill méi fréi ufänken - zum Beispill, just mat .
D'Tatsaach ass datt grouss Cluster eng héich Laascht op der Kubernetes Kontrollschicht setzen. An anere Wierder, de Stärekoup ze halen an effizient ze lafen erfuerdert virsiichteg Ofstëmmung.
Dëst Thema gëtt an engem verwandten Artikel um Original Blog mam Numm "".
Awer loosst eis de Géigendeel Approche betruechten: vill kleng Cluster.
2. Vill kleng, spezialiséiert Cluster
Mat dëser Approche benotzt Dir e separaten Cluster fir all Element deen Dir ofsetzt:
Vill kleng Cluster
Fir den Zweck vun dësem Artikel, ënner deployable Element bezitt sech op eng Instanz vun enger Applikatioun - zum Beispill eng Dev Versioun vun enger separater Applikatioun.
Dës Strategie benotzt Kubernetes als spezialiséiert runtime fir eenzel Applikatioun Instanzen.
Loosst eis d'Virdeeler an Nodeeler vun dëser Approche kucken.
+ Limitéiert "Blastradius"
Wann e Cluster klappt, sinn déi negativ Konsequenzen nëmme limitéiert op déi Aarbechtsbelaaschtungen, déi an deem Cluster ofgebaut goufen. All aner Aarbechtsbelaaschtunge bleiwen onberéiert.
+ Isolatioun
Workloads, déi an eenzelne Cluster gehost ginn, deelen keng Ressourcen wéi Prozessor, Erënnerung, Betribssystem, Netzwierk oder aner Servicer.
D'Resultat ass eng enk Isolatioun tëscht onrelatéierten Uwendungen, wat fir hir Sécherheet profitabel ka sinn.
+ Kleng Zuel vu Benotzer
Virausgesat datt all Cluster nëmmen e limitéierten Set vun Aarbechtslaascht enthält, gëtt d'Zuel vun de Benotzer mat Zougang zu deem reduzéiert.
Wat manner Leit Zougang zum Stärekoup hunn, wat manner de Risiko ass datt eppes "brach".
Loosst eis d'Nodeeler kucken.
- Ineffizient Notzung vu Ressourcen
Wéi virdru scho gesot, erfuerdert all Kubernetes Cluster e spezifesche Set vu Gestiounsressourcen: Masterknäppchen, Kontrollschichtkomponenten, Iwwerwaachungs- a Logbicherléisungen.
Am Fall vun enger grousser Zuel vu klenge Stärekéip muss e méi groussen Undeel vun de Ressourcen un d'Gestioun zougewisen ginn.
- Deier
Ineffizient Notzung vu Ressourcen bréngt automatesch héich Käschten mat.
Zum Beispill, d'Erhalen vun 30 Meeschternoden amplaz vun dräi mat der selwechter Rechenkraaft wäert onbedéngt d'Käschte beaflossen.
- Schwieregkeeten an der Verwaltung
Multiple Kubernetes Cluster ze managen ass vill méi schwéier wéi nëmmen een ze managen.
Zum Beispill musst Dir d'Authentifikatioun an d'Autorisatioun fir all Cluster konfiguréieren. D'Kubernetes Versioun muss och e puer Mol aktualiséiert ginn.
Dir musst méiglecherweis Automatiséierung benotzen fir all dës Aufgaben méi effizient ze maachen.
Loosst eis elo manner extrem Szenarie kucken.
3. Ee Stärekoup pro Applikatioun
An dëser Approche erstellt Dir e separaten Cluster fir all Instanzen vun enger bestëmmter Applikatioun:
Cluster pro Applikatioun
Dëse Wee kann als Generaliséierung vum Prinzip ugesi ginn "separat Cluster pro Equipe”, well normalerweis eng Team vun Ingenieuren eng oder méi Uwendungen entwéckelt.
Loosst eis d'Virdeeler an Nodeeler vun dëser Approche kucken.
+ De Cluster kann un d'Applikatioun ugepasst ginn
Wann eng Applikatioun speziell Bedierfnesser huet, kënne se an engem Cluster ëmgesat ginn ouni aner Cluster ze beaflossen.
Esou Bedierfnesser kënnen GPU Aarbechter, bestëmmte CNI Plugins, e Service Mesh oder en aneren Service enthalen.
All Cluster kann op d'Applikatioun ugepasst ginn, déi dran leeft, sou datt et nëmmen enthält wat néideg ass.
- Verschidde Ëmfeld an engem Stärekoup
Den Nodeel vun dëser Approche ass datt Uwendungsinstanzen aus verschiddenen Ëmfeld am selwechte Cluster coexistéieren.
Zum Beispill leeft d'Prod Versioun vun der Applikatioun am selwechte Cluster wéi d'Dev Versioun. Dëst bedeit och datt d'Entwéckler am selwechte Cluster operéieren an deem d'Produktiounsversioun vun der Applikatioun operéiert gëtt.
Wann, wéinst den Handlungen vun Entwéckler oder Feeler an der Dev Versioun, e Feeler am Cluster geschitt, da kéint d'Prod Versioun och potenziell leiden - e groussen Nodeel vun dëser Approche.
A schliisslech de leschte Szenario op eiser Lëscht.
4. Ee Stärekoup pro Ëmwelt
Dëse Szenario beinhalt d'Allokéiere vun engem separaten Cluster fir all Ëmfeld:
Ee Stärekoup pro Ëmfeld
Zum Beispill kënnt Dir Cluster hunn dev, Test и prod, an deem Dir all Instanzen vun der Applikatioun leeft, déi zu engem spezifeschen Ëmfeld gewidmet ass.
Hei sinn d'Virdeeler an Nodeeler vun dëser Approche.
+ Isolatioun vum Prod Ëmfeld
An dëser Approche sinn all Ëmfeld vuneneen isoléiert. Wéi och ëmmer, an der Praxis ass dëst besonnesch wichteg an engem prod Ëmfeld.
Produktiounsversioune vun der Applikatioun sinn elo onofhängeg vun deem wat an anere Stärekéip an Ëmfeld geschitt.
Op dës Manéier, wann e Problem op eemol am Dev-Cluster entsteet, wäerten d'Prod-Versioune vun den Uwendungen weider schaffen wéi wann näischt geschitt wier.
+ De Stärekoup kann un d'Ëmwelt ugepasst ginn
All Cluster kann op seng Ëmwelt ugepasst ginn. Zum Beispill kënnt Dir:
- Installatioun Tools fir Entwécklung an Debugging am Dev Cluster;
- installéieren Test Kaderen an Tools am Cluster Test;
- benotzen méi mächteg Hardware an Reseau Channels am Stärekoup prod.
Dëst erlaabt Iech d'Effizienz vun der Applikatiounsentwécklung an der Operatioun ze erhéijen.
+ Den Zougang zum Produktiounscluster beschränken
De Besoin fir direkt mat engem Prod Cluster ze schaffen entsteet selten, sou datt Dir de Krees vu Leit, déi Zougang dozou hunn, wesentlech limitéiere kënnt.
Dir kënnt nach méi wäit goen an de Leit den Zougang zu dësem Stärekoup ganz verweigeren, an all Deployementer ausféieren mat engem automatiséierte CI / CD Tool. Esou eng Approche miniméiert de Risiko vu mënschleche Feeler genau do wou et am meeschte relevant ass.
An elo e puer Wierder iwwert d'Nodeeler.
- Keng Isolatioun tëscht Uwendungen
Den Haapt Nodeel vun der Approche ass de Mangel u Hardware a Ressource Isolatioun tëscht Uwendungen.
Onbezunnen Uwendungen deelen Clusterressourcen: de Systemkär, de Prozessor, d'Erënnerung an e puer aner Servicer.
Wéi erwähnt, kann dëst potenziell geféierlech sinn.
- Onméiglechkeet Applikatioun Ofhängegkeeten ze lokaliséieren
Wann eng Applikatioun speziell Ufuerderungen huet, da musse se iwwer all Cluster zefridden sinn.
Zum Beispill, wann eng Applikatioun eng GPU erfuerdert, da muss all Cluster op d'mannst een Aarbechter mat enger GPU enthalen (och wann et nëmme vun där Applikatioun benotzt gëtt).
Als Resultat riskéiere mir méi héich Käschten an ineffizient Notzung vu Ressourcen.
Konklusioun
Wann Dir e spezifesche Set vun Uwendungen hutt, kënnen se an e puer grouss Cluster oder vill kleng plazéiert ginn.
Den Artikel diskutéiert d'Virdeeler an Nodeeler vu verschiddenen Approchen, rangéiert vun engem globale Cluster bis e puer kleng an héich spezialiséiert:
- eng grouss allgemeng Stärekoup;
- vill kleng héich spezialiséiert Stärekéip;
- ee Stärekoup pro Applikatioun;
- ee Stärekoup pro Ëmfeld.
Also wéi eng Approche sollt Dir huelen?
Wéi ëmmer hänkt d'Äntwert vum Gebrauchsfall of: Dir musst d'Virdeeler an Nodeeler vu verschiddene Approche weien an déi optimal Optioun wielen.
Allerdéngs ass d'Wiel net limitéiert op d'Beispiller hei uewen - Dir kënnt all Kombinatioun vun hinnen benotzen!
Zum Beispill kënnt Dir e puer Cluster fir all Team organiséieren: en Entwécklungscluster (an deem et Ëmfeld gëtt dev и Test) a Cluster fir Produktioun (wou d'Produktiounsëmfeld läit).
Baséierend op d'Informatioun an dësem Artikel kënnt Dir d'Virdeeler an Nodeeler entspriechend fir e spezifesche Szenario optimiséieren. Vill Gléck!
PS
Liest och op eisem Blog:
- «";
- «";
- «";
- «".
Source: will.com