Nota. transl.: aquest material és d'un projecte educatiu és la resposta a una pregunta popular quan es dissenya una infraestructura basada en Kubernetes. Esperem que unes descripcions prou detallades dels avantatges i els contres de cada opció us ajudin a prendre la millor elecció per al vostre projecte.
TL; DR: el mateix conjunt de càrregues de treball es pot executar en diversos clústers grans (cada clúster tindrà un gran nombre de càrregues de treball) o en molts petits (amb un petit nombre de càrregues a cada clúster).
A continuació es mostra una taula que avalua els avantatges i els contres de cada enfocament:
Quan s'utilitza Kubernetes com a plataforma per executar aplicacions, sovint sorgeixen diverses preguntes fonamentals sobre les complexitats de la configuració de clústers:
- Quants clústers he d'utilitzar?
- Què tan grans els he de fer?
- Què ha d'incloure cada clúster?
En aquest article, intentaré respondre a totes aquestes preguntes analitzant els pros i els contres de cada enfocament.
Enunciat d'una pregunta
Com a desenvolupador de programari, és probable que desenvolupi i opereu moltes aplicacions al mateix temps.
A més, és probable que moltes instàncies d'aquestes aplicacions s'executin en entorns diferents; per exemple, poden ser-ho dev, prova и producció.
El resultat és tota una matriu d'aplicacions i entorns:
Aplicacions i Entorns
L'exemple anterior representa 3 aplicacions i 3 entorns, donant com a resultat un total de 9 opcions possibles.
Cada instància d'aplicació és una unitat de desplegament autònoma amb la qual es pot treballar independentment d'altres.
Tingueu en compte que instància d'aplicació pot constar de molts components, com ara frontend, backend, base de dades, etc. En el cas d'una aplicació de microserveis, la instància inclourà tots els microserveis.
Com a resultat, els usuaris de Kubernetes tenen diverses preguntes:
- S'han de col·locar totes les instàncies de l'aplicació en un mateix clúster?
- Val la pena tenir un clúster independent per a cada instància d'aplicació?
- O potser s'hauria d'utilitzar una combinació dels enfocaments anteriors?
Totes aquestes opcions són força viables, ja que Kubernetes és un sistema flexible que no limita les capacitats de l'usuari.
Aquestes són algunes de les maneres possibles:
- un gran cúmul comú;
- molts petits clústers altament especialitzats;
- un clúster per aplicació;
- un clúster per entorn.
Com es mostra a continuació, els dos primers enfocaments es troben en extrems oposats de l'escala d'opcions:
Des d'uns quants grups grans (esquerra) fins a molts petits (dreta)
En general, un clúster es considera "més gran" que un altre si té una suma més gran de nodes i beines. Per exemple, un clúster amb 10 nodes i 100 pods és més gran que un clúster amb 1 node i 10 pods.
Bé, comencem!
1. Un gran cúmul comú
La primera opció és col·locar totes les càrregues de treball en un clúster:
Un gran cúmul
Dins d'aquest enfocament, el clúster s'utilitza com a universal plataforma d'infraestructures — Simplement implementeu tot el que necessiteu en un clúster de Kubernetes existent.
Kubernetes permet separar lògicament parts del clúster entre si, de manera que cada instància d'aplicació pot tenir el seu propi espai de noms.
Vegem els avantatges i els contres d'aquest enfocament.
+ Ús eficient dels recursos
Amb un únic clúster, només necessiteu una còpia de tots els recursos necessaris per executar i gestionar el clúster de Kubernetes.
Per exemple, això és cert per als nodes mestres. Normalment, cada clúster de Kubernetes té 3 nodes mestres, de manera que per a un sol clúster el seu nombre es mantindrà així (per a la comparació, 10 clústers necessitaran 30 nodes mestres).
La subtilesa anterior també s'aplica a altres serveis que operen a tot el clúster, com ara equilibradors de càrrega, controladors d'entrada, sistemes d'autenticació, registre i supervisió.
En un únic clúster, tots aquests serveis es poden utilitzar alhora per a totes les càrregues de treball (no cal crear-ne còpies, com és el cas de diversos clústers).
+ Barat
Com a conseqüència de l'anterior, menys clústers solen ser més barats perquè no hi ha costos generals.
Això és especialment cert per als nodes mestres, que poden costar una quantitat important de diners, independentment de com estiguin allotjats (a les instal·lacions o al núvol).
Alguns serveis gestionats de Kubernetes, com ara o , proporcioneu la capa de control de forma gratuïta. En aquest cas, el problema dels costos és menys greu.
També hi ha serveis gestionats que cobren una tarifa fixa pel funcionament de cada clúster de Kubernetes (per exemple, ).
+ Administració eficient
Gestionar un clúster és més fàcil que gestionar-ne diversos.
L'administració pot incloure les següents tasques:
- actualització de la versió de Kubernetes;
- establir un pipeline CI/CD;
- instal·lar el connector CNI;
- configurar un sistema d'autenticació d'usuaris;
- instal·lació d'un controlador d'accés;
i molts altres...
En el cas d'un clúster, haureu de fer tot això només una vegada.
Per a molts clústers, les operacions s'hauran de repetir moltes vegades, cosa que probablement requerirà certa automatització dels processos i eines per garantir la coherència i la coherència del procés.
I ara unes paraules sobre els contres.
− Punt únic de fallada
En cas de denegació l'únic el clúster deixarà de funcionar immediatament tots càrregues de treball!
Hi ha moltes maneres en què les coses poden anar malament:
- l'actualització de Kubernetes comporta efectes secundaris inesperats;
- Un component de tot el clúster (per exemple, un connector CNI) comença a no funcionar com s'esperava;
- un dels components del clúster no està configurat correctament;
- fracàs de la infraestructura subjacent.
Un d'aquests incidents pot causar danys greus a totes les càrregues de treball allotjades en un clúster compartit.
− Sense aïllament rígid
L'execució en un clúster compartit significa que les aplicacions comparteixen el maquinari, les capacitats de xarxa i el sistema operatiu als nodes del clúster.
En cert sentit, dos contenidors amb dues aplicacions diferents que s'executen al mateix node són com dos processos que s'executen a la mateixa màquina amb el mateix nucli del sistema operatiu.
Els contenidors Linux proporcionen algun tipus d'aïllament, però no és tan fort com el que proporcionen, per exemple, les màquines virtuals. En essència, un procés en un contenidor és el mateix procés que s'executa al sistema operatiu amfitrió.
Això pot ser un problema de seguretat: aquesta disposició teòricament permet que aplicacions no relacionades es comuniquin entre elles (ja sigui intencionadament o accidentalment).
A més, totes les càrregues de treball d'un clúster de Kubernetes comparteixen alguns serveis a tot el clúster, com ara - Això permet que les aplicacions trobin serveis d'altres aplicacions del clúster.
Tots els punts anteriors poden tenir significats diferents segons els requisits de seguretat de l'aplicació.
Kubernetes ofereix diverses eines per prevenir problemes de seguretat com ara и . Tanmateix, configurar-los correctament requereix una mica d'experiència; a més, no són capaços de tancar absolutament tots els forats de seguretat.
És important recordar sempre que Kubernetes va ser dissenyat originalment per a compartint, no per aïllament i seguretat.
− Absència d'un estricte multiarrendament
Tenint en compte l'abundància de recursos compartits en un clúster de Kubernetes, hi ha moltes maneres en què diferents aplicacions poden trepitjar-se mútuament.
Per exemple, una aplicació pot monopolitzar un recurs compartit (com ara la CPU o la memòria) i negar-hi l'accés a altres aplicacions que s'executen al mateix node.
Kubernetes ofereix diversos mecanismes per controlar aquest comportament, com ara (vegeu també l'article ""- aprox. trad.), и . Tanmateix, com en el cas de la seguretat, la seva configuració no és gens trivial i no són capaços d'evitar absolutament tots els efectes secundaris imprevistos.
− Gran nombre d'usuaris
En el cas d'un únic clúster, heu d'obrir-hi accés a moltes persones. I com més gran sigui el seu nombre, més gran és el risc que "trenquin" alguna cosa.
Dins del clúster podeu controlar qui pot fer què utilitzant (veure article ""- aprox. trad.). Tanmateix, no impedirà que els usuaris "trenquin" alguna cosa dins dels límits de la seva àrea de responsabilitat.
− Els clústers no poden créixer indefinidament
El clúster que s'utilitza per a totes les càrregues de treball probablement serà força gran (en termes de nombre de nodes i pods).
Però aquí sorgeix un altre problema: els clústers a Kubernetes no poden créixer indefinidament.
Hi ha un límit teòric a la mida del clúster. A Kubernetes és aproximadament .
Tanmateix, a la vida real, els problemes poden començar molt abans, per exemple, només amb .
El fet és que els grans clústers posen una càrrega elevada a la capa de control de Kubernetes. En altres paraules, mantenir el clúster en funcionament i en funcionament de manera eficient requereix una ajustada acurada.
Aquest problema s'explora en un article relacionat al bloc original anomenat "».
Però considerem l'enfocament contrari: molts grups petits.
2. Molts clústers petits i especialitzats
Amb aquest enfocament, utilitzeu un clúster independent per a cada element que implementeu:
Molts grups petits
Als efectes d'aquest article, sota element desplegable fa referència a una instància d'una aplicació, per exemple, una versió de desenvolupament d'una aplicació independent.
Aquesta estratègia utilitza Kubernetes com a especialitzat temps d'execució per a instàncies individuals d'aplicació.
Vegem els avantatges i els contres d'aquest enfocament.
+ "Radi d'explosió" limitat
Quan un clúster falla, les conseqüències negatives es limiten només a les càrregues de treball que es van desplegar en aquest clúster. La resta de càrregues de treball es mantenen intactes.
+ Aïllament
Les càrregues de treball allotjades en clústers individuals no comparteixen recursos com ara processador, memòria, sistema operatiu, xarxa o altres serveis.
El resultat és un aïllament estret entre aplicacions no relacionades, que pot ser beneficiós per a la seva seguretat.
+ Nombre reduït d'usuaris
Atès que cada clúster conté només un conjunt limitat de càrregues de treball, es redueix el nombre d'usuaris que hi tenen accés.
Com menys persones tinguin accés al clúster, menor serà el risc que alguna cosa "es trenqui".
Vegem els contres.
− Ús ineficient dels recursos
Com s'ha esmentat anteriorment, cada clúster de Kubernetes requereix un conjunt específic de recursos de gestió: nodes mestres, components de la capa de control, solucions de monitorització i registre.
En el cas d'un gran nombre de petits clústers, una part més gran dels recursos s'ha de destinar a la gestió.
− Car
L'ús ineficient dels recursos comporta automàticament costos elevats.
Per exemple, mantenir 30 nodes mestres en lloc de tres amb la mateixa potència de càlcul afectarà necessàriament els costos.
− Dificultats en l'administració
Gestionar diversos clústers de Kubernetes és molt més difícil que gestionar-ne només un.
Per exemple, haureu de configurar l'autenticació i l'autorització per a cada clúster. La versió de Kubernetes també s'haurà d'actualitzar diverses vegades.
Probablement haureu d'utilitzar l'automatització per fer que totes aquestes tasques siguin més eficients.
Ara mirem escenaris menys extrems.
3. Un clúster per aplicació
En aquest enfocament, creeu un clúster independent per a totes les instàncies d'una aplicació concreta:
Clúster per aplicació
Aquest camí es pot considerar com una generalització del principi "clúster separat per equip”, ja que normalment un equip d'enginyers està desenvolupant una o més aplicacions.
Vegem els avantatges i els contres d'aquest enfocament.
+ El clúster es pot ajustar a l'aplicació
Si una aplicació té necessitats especials, es poden implementar en un clúster sense afectar altres clústers.
Aquestes necessitats poden incloure treballadors de la GPU, certs connectors CNI, una malla de servei o algun altre servei.
Cada clúster es pot adaptar a l'aplicació que s'hi executa de manera que només contingui el que es necessita.
− Diferents entorns en un mateix clúster
El desavantatge d'aquest enfocament és que les instàncies d'aplicació de diferents entorns coexisteixen en el mateix clúster.
Per exemple, la versió de producte de l'aplicació s'executa al mateix clúster que la versió de desenvolupament. Això també significa que els desenvolupadors operen en el mateix clúster en què s'opera la versió de producció de l'aplicació.
Si, a causa de les accions dels desenvolupadors o els errors a la versió de desenvolupament, es produeix un error al clúster, la versió de producte també podria patir, un gran inconvenient d'aquest enfocament.
I finalment, l'últim escenari de la nostra llista.
4. Un clúster per entorn
Aquest escenari implica l'assignació d'un clúster independent per a cada entorn:
Un clúster per entorn
Per exemple, podeu tenir clústers dev, prova и producció, en què executaràs totes les instàncies de l'aplicació dedicades a un entorn concret.
Aquests són els avantatges i els contres d'aquest enfocament.
+ Aïllament de l'entorn del producte
Dins d'aquest enfocament, tots els entorns estan aïllats els uns dels altres. Tanmateix, a la pràctica això és especialment important en un entorn de productes.
Les versions de producció de l'aplicació ara són independents del que està passant en altres clústers i entorns.
D'aquesta manera, si de sobte sorgeix un problema al clúster de desenvolupament, les versions prod de les aplicacions continuaran funcionant com si no hagués passat res.
+ El clúster es pot ajustar a l'entorn
Cada clúster es pot ajustar al seu entorn. Per exemple, podeu:
- instal·lar eines de desenvolupament i depuració al clúster de desenvolupament;
- instal·lar marcs i eines de prova al clúster prova;
- utilitzar maquinari i canals de xarxa més potents al clúster producció.
Això us permet augmentar l'eficiència tant del desenvolupament com de l'operació d'aplicacions.
+ Restringir l'accés al clúster de producció
La necessitat de treballar directament amb un clúster de productes poques vegades sorgeix, de manera que podeu limitar significativament el cercle de persones que hi tenen accés.
Podeu anar encara més enllà i negar a la gent l'accés a aquest clúster per complet i realitzar tots els desplegaments mitjançant una eina CI/CD automatitzada. Aquest enfocament minimitzarà el risc d'errors humans exactament allà on sigui més rellevant.
I ara unes paraules sobre els contres.
− Sense aïllament entre aplicacions
El principal desavantatge de l'enfocament és la manca d'aïllament de maquinari i recursos entre aplicacions.
Les aplicacions no relacionades comparteixen recursos del clúster: el nucli del sistema, el processador, la memòria i alguns altres serveis.
Com s'ha esmentat, això pot ser potencialment perillós.
− Incapacitat per localitzar les dependències de l'aplicació
Si una aplicació té requisits especials, s'han de complir en tots els clústers.
Per exemple, si una aplicació requereix una GPU, aleshores cada clúster ha de contenir almenys un treballador amb una GPU (encara que només l'utilitzi aquesta aplicació).
Com a resultat, correm el risc de costos més elevats i un ús ineficient dels recursos.
Conclusió
Si teniu un conjunt específic d'aplicacions, es poden col·locar en diversos grups grans o en molts petits.
L'article analitza els pros i els contres de diversos enfocaments, que van des d'un clúster global fins a diversos petits i altament especialitzats:
- un gran clúster general;
- molts petits clústers altament especialitzats;
- un clúster per aplicació;
- un clúster per entorn.
Llavors, quin enfocament hauríeu de prendre?
Com sempre, la resposta depèn del cas d'ús: cal sospesar els pros i els contres dels diferents enfocaments i triar l'opció més òptima.
Tanmateix, l'elecció no es limita als exemples anteriors: podeu utilitzar qualsevol combinació d'ells!
Per exemple, podeu organitzar un parell de clústers per a cada equip: un clúster de desenvolupament (en el qual hi haurà entorns dev и prova) i clúster per producció (on s'ubicarà l'entorn de producció).
A partir de la informació d'aquest article, podeu optimitzar els pros i els contres en conseqüència per a un escenari específic. Bona sort!
PS
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com