Når du starter med Kubernetes, er det almindeligt at glemme alt om at konfigurere containerressourcer. På dette tidspunkt er det nok at sikre, at Docker-billedet fungerer og kan implementeres til Kubernetes-klyngen.
Men senere skal applikationen implementeres i en produktionsklynge sammen med andre applikationer. For at gøre dette skal du allokere ressourcer til containeren og sikre dig, at der er nok af dem til at få applikationen op at køre, og at andre kørende applikationer ikke vil opleve problemer.
Team oversat en artikel om containerressourcer (CPU & MEM), anmodninger og ressourcebegrænsninger. Du lærer fordelene ved disse indstillinger, og hvad der sker, hvis du ikke indstiller dem.
Computerressourcer
Vi har to typer ressourcer med følgende enheder:
- Central behandlingsenhed (CPU) - kerner;
- Hukommelse (MEM) - bytes.
Ressourcer er specificeret for hver container. I den følgende Pod YAML-fil vil du se en ressourcesektion, der indeholder de anmodede og begrænsede ressourcer:
- Requested Pod Resources = summen af anmodede ressourcer for alle containere;
- Pod-ressourcegrænse = Summen af alle pod-ressourcegrænser.
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: 1GiEksempel på anmodede og begrænsede ressourcer
Field resources.requested fra specifikationen Pod er et af de elementer, der bruges til at finde den ønskede node. Du kan allerede planlægge Pod-implementering til det. Hvordan finder man en passende node?
Kubernetes består af flere komponenter, herunder en masterknude eller masterknude (Kubernetes Control Plane). Masternoden har flere processer: kube-apiserver, kube-controller-manager og kube-scheduler.
Kube-planlægningsprocessen er ansvarlig for at gennemgå nyoprettede pods og finde mulige arbejdernoder, der matcher alle pod-anmodninger, inklusive antallet af anmodede ressourcer. Listen over noder fundet af kube-scheduler er rangeret. Poden er planlagt på noden med de højeste scores.
Hvor skal den lilla Pod placeres?
På billedet kan du se, at kube-scheduler skal planlægge en ny lilla Pod. Kubernetes-klyngen indeholder to noder: A og B. Som du kan se, kan kube-scheduler ikke planlægge en Pod på node A - de tilgængelige (uanmodede) ressourcer matcher ikke anmodningerne fra den lilla Pod. Så den 1 GB hukommelse, der anmodes om af den lilla Pod, vil ikke passe på node A, da den tilgængelige hukommelse er 0,5 GB. Men node B har nok ressourcer. Som et resultat beslutter kube-scheduler, at destinationen for den lilla Pod er node B.
Nu ved vi, hvordan de anmodede ressourcer påvirker valget af node til at køre Pod'en. Men hvad er virkningen af marginale ressourcer?
Ressourcegrænsen er en grænse, som CPU/MEM ikke kan krydse. CPU-ressourcen er imidlertid fleksibel, så beholdere, der når deres CPU-grænser, vil ikke få Pod'en til at afslutte. I stedet vil CPU drosling starte. Hvis MEM-brugsgrænsen nås, stoppes containeren på grund af OOM-Killer og genstartes, hvis det er tilladt af RestartPolicy-indstillingen.
Anmodede og maksimale ressourcer i detaljer
Ressourcekommunikation mellem Docker og Kubernetes
Den bedste måde at forklare, hvordan ressourceanmodninger og ressourcebegrænsninger fungerer, er at introducere forholdet mellem Kubernetes og Docker. På billedet ovenfor kan du se, hvordan Kubernetes-felterne og Docker-startflag er relateret.
Hukommelse: anmodning og begrænsning
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Som nævnt ovenfor måles hukommelse i bytes. Baseret på , kan vi angive hukommelse som et tal. Normalt er det et heltal, for eksempel 2678 - altså 2678 bytes. Du kan også bruge suffikser G и Gi, det vigtigste er at huske, at de ikke er ækvivalente. Den første er decimal og den anden er binær. Som eksemplet nævnt i k8s-dokumentationen: 128974848, 129e6, 129M, 123Mi - de er praktisk talt ækvivalente.
Mulighed for Kubernetes limits.memory matcher flaget --memory fra Docker. I tilfælde af request.memory Der er ingen pil til Docker, fordi Docker ikke bruger dette felt. Du kan spørge, er dette overhovedet nødvendigt? Ja har brug for. Som jeg sagde før, betyder feltet noget for Kubernetes. Baseret på informationen fra den beslutter kube-scheduler, hvilken node der skal planlægges Pod'en.
Hvad sker der, hvis du indstiller utilstrækkelig hukommelse til en anmodning?
Hvis containeren har nået grænserne for den anmodede hukommelse, placeres Pod'en i en gruppe af Pods, der stopper, når der ikke er nok hukommelse i noden.
Hvad sker der, hvis du indstiller hukommelsesgrænsen for lav?
Hvis beholderen overskrider hukommelsesgrænsen, vil den blive afsluttet på grund af OOM-Killed. Og vil om muligt genstarte baseret på RestartPolicy, hvor standardværdien er Always.
Hvad sker der, hvis du ikke angiver den ønskede hukommelse?
Kubernetes tager grænseværdien og indstiller den som standardværdi.
Hvad kan der ske, hvis du ikke angiver en hukommelsesgrænse?
Beholderen har ingen begrænsninger; den kan bruge så meget hukommelse, den vil. Hvis han begynder at bruge al den tilgængelige hukommelse i noden, vil OOM dræbe ham. Containeren vil derefter blive genstartet, hvis det er muligt baseret på RestartPolicy.
Hvad sker der, hvis du ikke angiver hukommelsesgrænser?
Dette er det værste tilfælde: Planlæggeren ved ikke, hvor mange ressourcer containeren kræver, og dette kan forårsage alvorlige problemer på noden. I dette tilfælde ville det være rart at have standardgrænser for navneområdet (indstillet af LimitRange). Der er ingen standardgrænser - Pod'en har ingen grænser, den kan bruge så meget hukommelse som den vil.
Hvis den anmodede hukommelse er mere end noden kan tilbyde, vil Pod'en ikke blive planlagt. Det er vigtigt at huske det Requests.memory - ikke minimumsværdien. Dette er en beskrivelse af den mængde hukommelse, der er tilstrækkelig til at holde beholderen kørende kontinuerligt.
Det anbefales normalt at indstille den samme værdi for request.memory и limit.memory. Dette sikrer, at Kubernetes ikke planlægger en Pod på en node, der har nok hukommelse til at køre Pod'en, men ikke nok til at køre den. Husk: Kubernetes Pod-planlægning tager kun højde for requests.memoryOg limits.memory tager ikke hensyn til.
CPU: anmodning og begrænsning
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Med en CPU er alt lidt mere kompliceret. Vender du tilbage til billedet af forholdet mellem Kubernetes og Docker, kan du se det request.cpu svarer til --cpu-shares, hvorimod limit.cpu matcher flaget cpus i Docker.
CPU'en, som Kubernetes anmoder om, ganges med 1024, andelen af CPU-cyklusser. Hvis du vil anmode om 1 fuld kerne, skal du tilføje cpu: 1som vist ovenfor.
At anmode om en fuld kerne (proportion = 1024) betyder ikke, at din container modtager den. Hvis din værtsmaskine kun har én kerne, og du kører mere end én container, skal alle containere dele den tilgængelige CPU mellem sig. Hvordan sker dette? Lad os se på billedet.
CPU-anmodning - Single Core System
Lad os forestille os, at du har et single-core værtssystem, der kører containere. Mor (Kubernetes) bagte en tærte (CPU) og vil dele den mellem børn (beholdere). Tre børn vil have en hel tærte (andel = 1024), et andet barn vil have en halv tærte (512). Mor vil være retfærdig og laver en simpel beregning.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Ud fra beregningen får tre børn 28 % af kernen, og ikke hele kernen. Det fjerde barn får 14 % af den fulde kerne, ikke halvdelen. Men tingene vil være anderledes, hvis du har et multi-core system.
CPU-anmodning - Multi-Core (4) System
På billedet ovenfor kan du se, at tre børn vil have en hel tærte, og en vil have halvdelen. Siden mor bagte fire tærter, får hvert af hendes børn lige så mange, som de vil. I et multi-core system er processorressourcer fordelt på tværs af alle tilgængelige processorkerner. Hvis en beholder er begrænset til mindre end én fuld CPU-kerne, kan den stadig bruge den på 100 %.
Ovenstående beregninger er forenklet for at forstå, hvordan CPU er fordelt mellem containere. Udover selve containerne er der naturligvis andre processer, der også bruger CPU-ressourcer. Når processer i en container er inaktive, kan andre bruge dens ressource. CPU: "200m" svarer til CPU: 0,2, hvilket betyder cirka 20 % af én kerne.
Lad os nu tale om limit.cpu. CPU'en, som Kubernetes begrænser, ganges med 100. Resultatet er den tid, beholderen kan bruge hver 100 µs (cpu-period).
limit.cpu matcher Docker-flaget --cpus. Dette er en ny kombination af gammelt --cpu-period и --cpu-quota. Ved at indstille det angiver vi, hvor mange tilgængelige CPU-ressourcer containeren maksimalt kan bruge, før drosling begynder:
- cPU'er - kombination
cpu-periodиcpu-quota. cpus = 1.5svarende til indstillingcpu-period = 100000иcpu-quota = 150000; - CPU-periode - periode , standard 100 mikrosekunder;
- cpu-kvote - antal mikrosekunder indeni
cpu-period, som er afgrænset af beholderen.
Hvad sker der, hvis du installerer utilstrækkelig anmodet CPU?
Hvis containeren har brug for mere, end den har installeret, vil den stjæle CPU fra andre processer.
Hvad sker der, hvis du sætter CPU-grænsen for lavt?
Da CPU-ressourcen er justerbar, aktiveres drosling.
Hvad sker der, hvis du ikke angiver en CPU-anmodning?
Som med hukommelse er anmodningsværdien lig med grænsen.
Hvad sker der, hvis du ikke angiver en CPU-grænse?
Beholderen vil bruge så meget CPU, som den har brug for. Hvis en standard CPU-politik (LimitRange) er defineret i navneområdet, bruges denne grænse også for containeren.
Hvad sker der, hvis du hverken angiver en anmodning eller en CPU-grænse?
Som med hukommelsen er dette det værste tilfælde. Planlæggeren ved ikke, hvor mange ressourcer din container har brug for, og dette kan forårsage alvorlige problemer på noden. For at undgå dette skal du indstille standardgrænser for navneområder (LimitRange).
Husk: Hvis du anmoder om mere CPU, end noderne kan levere, vil Pod'en ikke blive planlagt. Requests.cpu - ikke minimumsværdien, men en værdi, der er tilstrækkelig til at starte Pod'en og arbejde uden fejl. Hvis applikationen ikke udfører komplekse beregninger, er den bedste mulighed at installere request.cpu <= 1 og start så mange replikaer som nødvendigt.
Ideel mængde af anmodede ressourcer eller ressourcegrænse
Vi lærte om begrænsningen af computerressourcer. Nu er det tid til at besvare spørgsmålet: "Hvor mange ressourcer kræver min Pod for at køre applikationen uden problemer? Hvad er den ideelle mængde?
Desværre er der ingen klare svar på disse spørgsmål. Hvis du ikke ved, hvordan din applikation fungerer, eller hvor meget CPU eller hukommelse den har brug for, er den bedste mulighed at give applikationen en masse hukommelse og CPU og derefter køre ydeevnetest.
Ud over ydeevnetest skal du overvåge applikationens adfærd i overvågning i en uge. Hvis graferne indikerer, at din applikation bruger færre ressourcer, end du anmodede om, kan du reducere mængden af CPU eller hukommelse, der anmodes om.
Se som eksempel dette . Den viser forskellen mellem de anmodede ressourcer eller ressourcegrænsen og det aktuelle ressourceforbrug.
Konklusion
Anmodning om og begrænsning af ressourcer hjælper med at holde din Kubernetes-klynge sund. Korrekt grænsekonfiguration minimerer omkostningerne og holder applikationer kørende til enhver tid.
Kort sagt er der et par ting at huske på:
- Anmodede ressourcer er en konfiguration, der tages i betragtning ved opstartstidspunktet (når Kubernetes planlægger at være vært for applikationen). I modsætning hertil er begrænsning af ressourcer vigtigt under kørsel – når applikationen allerede kører på noden.
- Sammenlignet med hukommelse er CPU'en en reguleret ressource. Hvis der ikke er nok CPU, vil din Pod ikke lukke ned, og gasspjældet vil tænde.
- Anmodede ressourcer og ressourcegrænse er ikke minimum- og maksimumværdier! Ved at definere de ønskede ressourcer sikrer du, at applikationen kører uden problemer.
- En god praksis er at indstille hukommelsesanmodningen lig med hukommelsesgrænsen.
- Ok installation anmodet
CPU <=1, hvis applikationen ikke udfører komplekse beregninger. - Hvis du anmoder om flere ressourcer, end der er tilgængelige på en node, vil Pod'en aldrig blive planlagt til den node.
- For at bestemme den korrekte mængde af anmodede ressourcer/ressourcegrænser skal du bruge belastningstest og overvågning.
Jeg håber, at denne artikel hjælper dig med at forstå det grundlæggende koncept for ressourcebegrænsning. Og du vil være i stand til at anvende denne viden i dit arbejde.
Held og lykke!
Hvad skal man ellers læse:
- .
- .
- .
Kilde: www.habr.com