Per a cada recurs de Kubernetes, podeu configurar dos tipus de requisits: sol·licituds i límits. El primer descriu els requisits mínims per a la disponibilitat de recursos de node gratuïts necessaris per executar un contenidor o pod, el segon limita estrictament els recursos disponibles per al contenidor.
Quan Kubernetes programa pods, és molt important que els contenidors tinguin prou recursos per funcionar correctament. Si teniu previst desplegar una aplicació gran en un node amb recursos limitats, és possible que no s'executi perquè el node s'està quedant sense memòria o s'està quedant sense energia de la CPU. En aquest article, veurem com podeu resoldre l'escassetat de potència informàtica mitjançant les sol·licituds i els límits de recursos.
Les sol·licituds i els límits són mecanismes que Kubernetes utilitza per gestionar recursos com ara la CPU i la memòria. Les sol·licituds són les que garanteixen que el contenidor rebi el recurs sol·licitat. Si un contenidor sol·licita un recurs, Kubernetes només el programarà en un node que el pugui proporcionar. Els límits controlen que els recursos sol·licitats pel contenidor no superaran mai un valor determinat.
Un contenidor només pot augmentar la seva potència de càlcul fins a un cert límit, després del qual es limitarà. Vegem com funciona. Per tant, hi ha dos tipus de recursos: processador i memòria. El programador de Kubernetes utilitza dades sobre aquests recursos per esbrinar on executar els vostres pods. Una especificació de recurs típica per a un pod té aquest aspecte.
Cada contenidor d'un pod pot establir les seves pròpies consultes i límits, tot és additiu. Els recursos del processador es defineixen en mil·licores. Si el vostre contenidor necessita dos nuclis complets per funcionar, establiu el valor a 2000 m. Si el contenidor només necessita la potència d'1/4 del nucli, el valor serà de 250 m. Tingueu en compte que si assigneu un valor de recurs de CPU superior al nombre de nuclis del node més gran, el vostre pod no estarà programat per iniciar-se. Una situació similar es produirà si teniu un pod que necessita quatre nuclis i el clúster de Kubernetes només consta de dues màquines virtuals principals.
Llevat que la vostra aplicació estigui dissenyada específicament per aprofitar diversos nuclis (se'n pensen programes com la informàtica científica complexa i les operacions de bases de dades), la millor pràctica és establir les sol·licituds de CPU a 1 o inferior i, a continuació, executar més rèpliques a escalabilitat. Aquesta solució donarà al sistema una major flexibilitat i fiabilitat.
Quan es tracta de limitacions de la CPU, les coses es tornen més interessants, ja que es considera un recurs compressible. Si la vostra aplicació comença a acostar-se al límit de potència del processador, Kubernetes començarà a alentir el vostre contenidor mitjançant l'acceleració de la CPU, reduint la freqüència del processador. Això vol dir que la CPU s'accelerarà artificialment, donant a l'aplicació un rendiment potencialment pitjor, però el procés no s'acabarà ni s'eliminarà.
Els recursos de memòria es defineixen en bytes. Normalment, el valor de la configuració es mesura en mebibytes Mib, però podeu establir qualsevol valor, des de bytes fins a petabytes. La mateixa situació s'aplica aquí que amb la CPU: si sol·liciteu una quantitat de memòria superior a la quantitat de memòria dels vostres nodes, aquest pod no estarà programat per executar-se. Però a diferència dels recursos de la CPU, la memòria no està comprimida perquè no hi ha manera de limitar-ne l'ús. Per tant, l'execució del contenidor s'aturarà tan bon punt superi la memòria que se li assigna.
És important recordar que no podeu configurar sol·licituds que superin els recursos que poden proporcionar els vostres nodes. Les especificacions dels recursos compartits per a les màquines virtuals de GKE es poden trobar als enllaços que hi ha a sota d'aquest vídeo.
En un món ideal, la configuració predeterminada del contenidor seria suficient per mantenir els fluxos de treball sense problemes. Però el món real no és així, la gent es pot oblidar fàcilment de configurar l'ús dels recursos, o els pirates informàtics establiran peticions i restriccions que superin les capacitats reals de la infraestructura. Per evitar que es produeixin aquests escenaris, podeu configurar les quotes de recursos ResourceQuota i LimitRange.
Un cop creat un espai de noms, es pot bloquejar mitjançant quotes. Per exemple, si teniu els espais de noms prod i dev, el patró és que no hi ha quotes de producció i quotes de desenvolupament molt estrictes. Això permet que el producte, en cas d'un fort augment del trànsit, es faci càrrec de tot el recurs disponible, bloquejant completament el desenvolupament.
La quota de recursos pot semblar així. En aquest exemple hi ha 4 seccions: aquestes són les 4 línies inferiors del codi.
Vegem-ne cadascun d'ells. Requests.cpu és el nombre màxim de sol·licituds de CPU combinades que poden provenir de tots els contenidors de l'espai de noms. En aquest exemple, podríeu tenir 50 contenidors amb sol·licituds de 10 m, cinc contenidors amb sol·licituds de 100 m o només un contenidor amb sol·licituds de 500 m. Mentre el nombre total de requests.cpu d'un espai de noms determinat sigui inferior a 500 m, tot anirà bé.
Memòria sol·licitada requests.memory és la quantitat màxima de sol·licituds de memòria combinades que poden tenir tots els contenidors de l'espai de noms. Com en el cas anterior, podeu tenir 50 contenidors de 2 mib, cinc contenidors de 20 mib o un únic contenidor de 100 mib sempre que la quantitat total de memòria sol·licitada a l'espai de noms sigui inferior a 100 mebibytes.
Limits.cpu és la quantitat màxima combinada de potència de CPU que poden utilitzar tots els contenidors de l'espai de noms. Podem considerar que aquest és el límit de les peticions de potència del processador.
Finalment, limits.memory és la quantitat màxima de memòria compartida que poden utilitzar tots els contenidors de l'espai de noms. Aquest és un límit de sol·licituds de memòria totals.
Així, per defecte, els contenidors d'un clúster de Kubernetes s'executen amb recursos informàtics il·limitats. Amb les quotes de recursos, els administradors de clúster poden limitar el consum de recursos i la creació de recursos en funció de l'espai de noms. En un espai de noms, un pod o contenidor pot consumir tanta potència de CPU i memòria com determina la quota de recursos de l'espai de noms. Tanmateix, hi ha la preocupació que una beina o contenidor pugui monopolitzar tots els recursos disponibles. Per evitar aquesta situació, s'utilitza un rang límit: una política per limitar l'assignació de recursos (per a pods o contenidors) a l'espai de noms.
L'interval límit proporciona restriccions que poden:
- Garantir l'ús mínim i màxim dels recursos informàtics per a cada mòdul o contenidor de l'espai de noms;
- aplicar les sol·licituds d'emmagatzematge mínimes i màximes de Starage Request per a cada PersistentVolumeClaim a l'espai de noms;
- imposar una relació entre una sol·licitud i un límit per a un recurs en un espai de noms;
- establiu les sol·licituds/límits per defecte per als recursos informàtics a l'espai de noms i injecteu-los automàticament als contenidors en temps d'execució.
D'aquesta manera podeu crear un rang de límit al vostre espai de noms. A diferència d'una quota, que s'aplica a tot l'espai de noms, Limit Range s'utilitza per a contenidors individuals. Això pot evitar que els usuaris creïn contenidors molt petits o, per contra, gegants dins de l'espai de noms. L'interval límit podria semblar així.
Com en el cas anterior, aquí es poden distingir 4 apartats. Vegem-ne cadascun.
La secció predeterminada estableix els límits predeterminats per al contenidor del pod. Si establiu aquests valors a l'interval extrem, qualsevol contenidor per als quals no s'hagin establert explícitament aquests valors seguiran els valors predeterminats.
La secció de sol·licitud per defecte defaultRequest configura les sol·licituds per defecte per al contenidor del pod. De nou, si establiu aquests valors a l'interval extrem, els contenidors que no estableixin aquestes opcions explícitament tindran aquests valors per defecte.
La secció màxima especifica els límits màxims que es poden establir per a un contenidor del pod. Els valors de la secció predeterminada i els límits del contenidor no es poden establir per sobre d'aquest límit. És important tenir en compte que si el valor s'estableix com a màxim i no hi ha cap secció per defecte, el valor màxim es converteix en el valor per defecte.
La secció min especifica les sol·licituds mínimes que es poden establir per a un contenidor en un pod. Tanmateix, els valors de la secció predeterminada i les consultes per al contenidor no es poden establir per sota d'aquest límit.
De nou, és important tenir en compte que si s'estableix aquest valor, el valor predeterminat no ho és, aleshores el valor mínim es converteix en l'indicador predeterminat.
Aquestes sol·licituds de recursos les utilitza finalment el programador de Kubernetes per executar les vostres càrregues de treball. Per poder configurar correctament els contenidors, és molt important entendre com funciona. Suposem que voleu executar diversos pods al vostre clúster. Suposant que les especificacions del pod són vàlides, la programació de Kubernetes utilitzarà l'equilibri round robin per seleccionar un node per executar la càrrega de treball.
Kubernetes comprovarà si el node 1 té prou recursos per satisfer les sol·licituds dels contenidors de pods i, si no, passarà al següent node. Si cap dels nodes del sistema és capaç de satisfer les sol·licituds, els pods passaran a l'estat Pendent. Utilitzant les funcions del motor de Google Kubernetes, com ara l'escala automàtica de nodes, GKE pot detectar automàticament l'estat d'espera i crear diversos nodes addicionals.
Si posteriorment us quedeu sense capacitat de nodes, l'escala automàtica reduirà el nombre de nodes per estalviar-vos diners. És per això que Kubernetes programa pods en funció de les sol·licituds. Tanmateix, el límit pot ser superior a les sol·licituds i, en alguns casos, el node pot quedar-se sense recursos. A aquest estat l'anomenem estat de sobrecompromís.
Com he dit, quan es tracta de CPU, Kubernetes començarà a limitar els pods. Cada pod rebrà tant com ha sol·licitat, però si no arriba al límit, començarà a aplicar-se l'acceleració.
Quan es tracta de recursos de memòria, Kubernetes es veu obligat a prendre decisions sobre quins pods suprimir i quins conservar fins que allibereu els recursos del sistema o el sistema sencer es bloquejarà.
Imaginem un escenari en què tingueu una màquina sense memòria: com ho faria Kubernetes?
Kubernetes buscarà pods que facin servir més recursos dels que demanaven. Per tant, si els vostres contenidors no tenen cap sol·licitud, vol dir que estan utilitzant per defecte més del que van demanar, simplement perquè no van demanar res! Aquests contenidors esdevenen candidats principals per a l'aturada. Els següents candidats són contenidors que han satisfet totes les seves peticions però encara estan per sota del límit màxim.
Per tant, si Kubernetes troba diversos pods que han superat els seus paràmetres de sol·licitud, els ordenarà per prioritat i després eliminarà els pods de menor prioritat. Si tots els pods tenen la mateixa prioritat, Kubernetes cancel·larà aquells pods que hagin superat les seves sol·licituds més que altres pods.
En casos molt rars, Kubernetes pot avortar pods que encara es troben dins de l'abast de les seves sol·licituds. Això pot passar quan els components crítics del sistema, com ara l'agent Kubelet o Docker, comencen a consumir més recursos dels que els hi havia reservat.
Per tant, en les primeres etapes de les petites empreses, un clúster de Kubernetes pot funcionar bé sense establir sol·licituds i restriccions de recursos, però a mesura que els vostres equips i projectes comencen a créixer, correu el risc de trobar problemes en aquesta àrea. Afegir consultes i restriccions als vostres mòduls i espais de noms requereix molt poc esforç addicional i pot estalviar moltes molèsties.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com