Quan comenceu amb Kubernetes, és habitual oblidar-vos de configurar els recursos del contenidor. En aquest punt, n'hi ha prou per assegurar-se que la imatge de Docker funciona i es pot desplegar al clúster de Kubernetes.
Però més tard l'aplicació s'ha de desplegar en un clúster de producció juntament amb altres aplicacions. Per fer-ho, heu d'assignar recursos per al contenidor i assegurar-vos que n'hi ha prou per posar l'aplicació en funcionament i que altres aplicacions en execució no tindran problemes.
Equip va traduir un article sobre recursos de contenidors (CPU i MEM), sol·licituds i limitacions de recursos. Aprendràs els avantatges d'aquesta configuració i què passa si no les configures.
Recursos informàtics
Disposem de dos tipus de recursos amb les unitats següents:
- Unitat central de processament (CPU) - nuclis;
- Memòria (MEM) - bytes.
S'especifiquen els recursos per a cada contenidor. Al fitxer Pod YAML següent, veureu una secció de recursos que conté els recursos sol·licitats i limitats:
- Recursos de pod sol·licitats = suma de recursos sol·licitats de tots els contenidors;
- Límit de recursos de pod = Suma de tots els límits de recursos de pod.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiExemple de recursos sol·licitats i limitats
Camp resources.requested de l'especificació Pod és un dels elements que s'utilitzen per trobar el node desitjat. Ja podeu planificar el desplegament de Pod per a això. Com trobeu un node adequat?
Kubernetes consta de diversos components, inclòs un node mestre o node mestre (Pla de control de Kubernetes). El node mestre té diversos processos: kube-apiserver, kube-controller-manager i kube-scheduler.
El procés kube-scheduler s'encarrega de revisar els pods acabats de crear i de trobar possibles nodes de treball que coincideixin amb totes les sol·licituds de pods, inclòs el nombre de recursos sol·licitats. La llista de nodes trobats per kube-scheduler està classificada. El pod està programat al node amb les puntuacions més altes.
On es col·locarà el pod morat?
A la imatge podeu veure que kube-scheduler hauria de programar un nou pod morat. El clúster de Kubernetes conté dos nodes: A i B. Com podeu veure, kube-scheduler no pot programar un pod al node A: els recursos disponibles (no sol·licitats) no coincideixen amb les sol·licituds del pod morat. Per tant, els 1 GB de memòria sol·licitats pel Pod morat no s'adaptaran al node A, ja que la memòria disponible és de 0,5 GB. Però el node B té prou recursos. Com a resultat, kube-scheduler decideix que la destinació del pod morat és el node B.
Ara sabem com els recursos sol·licitats afecten l'elecció del node per executar el Pod. Però quin és l'impacte dels recursos marginals?
El límit de recursos és un límit que la CPU/MEM no pot creuar. Tanmateix, el recurs de la CPU és flexible, de manera que els contenidors que arriben als seus límits de CPU no faran que el Pod surti. En canvi, s'iniciarà l'acceleració de la CPU. Si s'arriba al límit d'ús de MEM, el contenidor s'aturarà a causa d'OOM-Killer i es reiniciarà si ho permet la configuració de RestartPolicy.
Recursos sol·licitats i màxims en detall
Comunicació de recursos entre Docker i Kubernetes
La millor manera d'explicar com funcionen les sol·licituds de recursos i els límits de recursos és introduir la relació entre Kubernetes i Docker. A la imatge de dalt podeu veure com es relacionen els camps de Kubernetes i els indicadors d'inici de Docker.
Memòria: petició i limitació
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Com s'ha esmentat anteriorment, la memòria es mesura en bytes. Basat en , podem especificar la memòria com a nombre. Normalment és un nombre enter, per exemple 2678, és a dir, 2678 bytes. També podeu utilitzar sufixos G и Gi, el més important és recordar que no són equivalents. El primer és decimal i el segon és binari. Com l'exemple esmentat a la documentació de k8s: 128974848, 129e6, 129M, 123Mi - són pràcticament equivalents.
Opció Kubernetes limits.memory coincideix amb la bandera --memory de Docker. En cas de request.memory No hi ha cap fletxa per a Docker perquè Docker no utilitza aquest camp. Podeu preguntar-vos, fins i tot això és necessari? Sí necessitat. Com he dit abans, el camp és important per a Kubernetes. Basant-se en la informació d'aquest, kube-scheduler decideix quin node programa el Pod.
Què passa si no configureu memòria suficient per a una sol·licitud?
Si el contenidor ha arribat als límits de la memòria sol·licitada, llavors el Pod es col·loca en un grup de Pods que s'aturen quan no hi ha prou memòria al node.
Què passa si establiu el límit de memòria massa baix?
Si el contenidor supera el límit de memòria, s'acabarà a causa d'OOM-Killed. I es reiniciarà si és possible en funció de RestartPolicy on es troba el valor predeterminat Always.
Què passa si no especifiqueu la memòria sol·licitada?
Kubernetes agafarà el valor límit i l'establirà com a valor predeterminat.
Què pot passar si no especifiqueu un límit de memòria?
El contenidor no té restriccions; pot utilitzar tanta memòria com vulgui. Si comença a utilitzar tota la memòria disponible del node, aleshores OOM el matarà. Aleshores, el contenidor es reiniciarà si és possible segons RestartPolicy.
Què passa si no especifiqueu límits de memòria?
Aquest és el pitjor dels casos: el planificador no sap quants recursos necessita el contenidor, i això pot causar problemes greus al node. En aquest cas, seria bo tenir límits predeterminats a l'espai de noms (establerts per LimitRange). No hi ha límits predeterminats: el pod no té límits, pot utilitzar tanta memòria com vulgui.
Si la memòria sol·licitada és superior a la que el node pot oferir, el Pod no es programarà. És important recordar-ho Requests.memory - no el valor mínim. Aquesta és una descripció de la quantitat de memòria suficient per mantenir el contenidor funcionant contínuament.
Normalment es recomana establir el mateix valor per request.memory и limit.memory. Això garanteix que Kubernetes no programarà un Pod en un node que tingui prou memòria per executar el Pod però no suficient per executar-lo. Tingueu en compte: la planificació de Kubernetes Pod només té en compte requests.memoryI limits.memory no té en compte.
CPU: petició i límit
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Amb una CPU tot és una mica més complicat. Tornant a la imatge de la relació entre Kubernetes i Docker, ho podeu veure request.cpu correspon --cpu-shares, mentre que limit.cpu coincideix amb la bandera cpus a Docker.
La CPU que demana Kubernetes es multiplica per 1024, la proporció de cicles de CPU. Si voleu sol·licitar 1 nucli complet, heu d'afegir cpu: 1com es mostra més amunt.
Sol·licitar un nucli complet (proporció = 1024) no vol dir que el vostre contenidor el rebrà. Si la vostra màquina amfitrió només té un nucli i esteu executant més d'un contenidor, tots els contenidors han de compartir la CPU disponible entre ells. Com passa això? Mirem la imatge.
Sol·licitud de CPU: sistema de nucli únic
Imaginem que teniu un sistema host d'un sol nucli que executa contenidors. La mare (Kubernetes) ha fet un pastís (CPU) i el vol dividir entre nens (envasos). Tres nens volen un pastís sencer (proporció = 1024), un altre nen vol mig pastís (512). La mare vol ser justa i fa un càlcul senzill.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Segons el càlcul, tres nens rebran el 28% del nucli, i no el nucli sencer. El quart fill obtindrà el 14% del nucli complet, no la meitat. Però les coses seran diferents si teniu un sistema multinucli.
Sol·licitud de CPU: sistema multinúcli (4).
A la imatge de dalt podeu veure que tres nens volen un pastís sencer, i un vol la meitat. Com que la mare va coure quatre pastissos, cada un dels seus fills en tindrà tants com vulgui. En un sistema multinucli, els recursos del processador es distribueixen entre tots els nuclis de processador disponibles. Si un contenidor està limitat a menys d'un nucli complet de la CPU, encara pot utilitzar-lo al 100%.
Els càlculs anteriors es simplifiquen per entendre com es distribueix la CPU entre els contenidors. Per descomptat, a més dels propis contenidors, hi ha altres processos que també utilitzen recursos de CPU. Quan els processos d'un contenidor estan inactius, altres poden utilitzar el seu recurs. CPU: "200m" correspon CPU: 0,2, que significa aproximadament el 20% d'un nucli.
Ara parlem-ne limit.cpu. La CPU que limita Kubernetes es multiplica per 100. El resultat és la quantitat de temps que el contenidor pot utilitzar cada 100 µs (cpu-period).
limit.cpu coincideix amb la bandera de Docker --cpus. Aquesta és una nova combinació d'antics --cpu-period и --cpu-quota. En configurar-lo, indiquem quants recursos de CPU disponibles pot utilitzar el contenidor al màxim abans que comenci l'acceleració:
- CPU - combinació
cpu-periodиcpu-quota. cpus = 1.5equivalent a la configuraciócpu-period = 100000иcpu-quota = 150000; - Període de la CPU - període , per defecte 100 microsegons;
- CPU-quota - nombre de microsegons dins
cpu-period, que està delimitada pel contenidor.
Què passa si instal·leu una CPU sol·licitada insuficient?
Si el contenidor necessita més del que ha instal·lat, robarà la CPU d'altres processos.
Què passa si configureu el límit de CPU massa baix?
Com que el recurs de la CPU és ajustable, s'activarà l'acceleració.
Què passa si no especifiqueu una sol·licitud de CPU?
Igual que amb la memòria, el valor de la sol·licitud és igual al límit.
Què passa si no especifiqueu un límit de CPU?
El contenidor utilitzarà tanta CPU com necessiti. Si es defineix una política de CPU predeterminada (LimitRange) a l'espai de noms, aquest límit també s'utilitza per al contenidor.
Què passa si no especifiqueu ni una sol·licitud ni un límit de CPU?
Igual que amb la memòria, aquest és el pitjor dels casos. El planificador no sap quants recursos necessita el vostre contenidor i això pot causar problemes greus al node. Per evitar-ho, heu d'establir límits predeterminats per als espais de noms (LimitRange).
Recordeu: si demaneu més CPU de la que poden proporcionar els nodes, el Pod no es programarà. Requests.cpu - No és el valor mínim, sinó un valor suficient per iniciar el Pod i funcionar sense errors. Si l'aplicació no realitza càlculs complexos, la millor opció és instal·lar-la request.cpu <= 1 i llançar tantes rèpliques com sigui necessari.
Quantitat ideal de recursos sol·licitats o límit de recursos
Vam aprendre sobre la limitació dels recursos informàtics. Ara és el moment de respondre a la pregunta: "Quants recursos necessita el meu Pod per executar l'aplicació sense cap problema? Quina és la quantitat ideal?
Malauradament, no hi ha respostes clares a aquestes preguntes. Si no sabeu com funciona la vostra aplicació o quanta CPU o memòria necessita, la millor opció és donar-li molta memòria i CPU a l'aplicació i després fer proves de rendiment.
A més de les proves de rendiment, controleu el comportament de l'aplicació durant una setmana. Si els gràfics indiquen que la vostra aplicació consumeix menys recursos dels que heu sol·licitat, podeu reduir la quantitat de CPU o memòria sol·licitada.
Com a exemple vegeu això . Mostra la diferència entre els recursos sol·licitats o el límit de recursos i l'ús actual dels recursos.
Conclusió
Sol·licitar i limitar recursos ajuda a mantenir el vostre clúster de Kubernetes en bon estat. La configuració adequada del límit minimitza els costos i manté les aplicacions en funcionament en tot moment.
En resum, cal tenir en compte algunes coses:
- Els recursos sol·licitats són una configuració que es té en compte en el moment de l'inici (quan Kubernetes té previst allotjar l'aplicació). En canvi, limitar els recursos és important en temps d'execució, quan l'aplicació ja s'està executant al node.
- En comparació amb la memòria, la CPU és un recurs regulat. Si no hi ha prou CPU, el pod no s'apagarà i el mecanisme d'acceleració s'activarà.
- Els recursos sol·licitats i el límit de recursos no són valors mínims i màxims! En definir els recursos sol·licitats, us assegureu que l'aplicació s'executarà sense problemes.
- Una bona pràctica és establir la sol·licitud de memòria igual al límit de memòria.
- D'acord, s'ha sol·licitat la instal·lació
CPU <=1, si l'aplicació no realitza càlculs complexos. - Si sol·liciteu més recursos dels disponibles en un node, el Pod no es programarà mai en aquest node.
- Per determinar la quantitat correcta de recursos/límits de recursos sol·licitats, feu servir proves de càrrega i supervisió.
Espero que aquest article us ajudi a entendre el concepte bàsic de limitació de recursos. I podràs aplicar aquests coneixements al teu treball.
Bona sort!
Què més cal llegir:
- .
- .
- .
Font: www.habr.com