Wann Dir mat Kubernetes ufänkt, ass et üblech fir Containerressourcen opzestellen. Zu dësem Zäitpunkt ass et genuch fir sécherzestellen datt den Docker-Bild funktionnéiert a kann an de Kubernetes-Cluster ofgesat ginn.
Awer méi spéit muss d'Applikatioun an engem Produktiounscluster zesumme mat aneren Uwendungen ofgebaut ginn. Fir dëst ze maachen, musst Dir Ressourcen fir de Container zouginn an sécherstellen datt et genuch ass fir d'Applikatioun opzemaachen an ze lafen, an datt aner lafend Uwendungen keng Probleemer erliewen.
Equipe en Artikel iwwer Containerressourcen (CPU & MEM), Ufroen a Ressourcebeschränkungen iwwersat. Dir léiert d'Virdeeler vun dësen Astellungen a wat geschitt wann Dir se net setzt.
Rechen Ressourcen
Mir hunn zwou Zorte vu Ressourcen mat de folgenden Unitéiten:
- Zentral Veraarbechtung Eenheet (CPU) - Kären;
- Erënnerung (MEM) - Bytes.
Ressourcen gi fir all Container uginn. An der folgender Pod YAML Datei gesitt Dir eng Ressource Sektioun déi déi ugefrote Ressourcen enthält:
- Requested Pod Ressourcen = Zomm vun ugefrote Ressourcen vun all Container;
- Pod Ressource Limit = Zomm vun all Pod Ressource Limite.
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: 1GiBeispill vun ugefrote a limitéiert Ressourcen
Beräich resources.requested aus der Spezifizéierung Pod ass ee vun den Elementer déi benotzt gëtt fir de gewënschten Node ze fannen. Dir kënnt scho Pod Deployment dofir plangen. Wéi fannt Dir e passenden Node?
Kubernetes besteet aus verschiddene Komponenten, dorënner e Master Node oder Master Node (Kubernetes Control Plane). De Master Node huet verschidde Prozesser: kube-apiserver, kube-controller-manager a kube-scheduler.
De Kube-Scheduler Prozess ass verantwortlech fir nei erstallt Pods ze iwwerpréiwen a méiglech Aarbechtsknäppchen ze fannen déi all Pod Ufroe passen, och d'Zuel vun de gefrote Ressourcen. D'Lëscht vun den Noden fonnt vum Kube-Scheduler ass klasséiert. De Pod ass um Node mat den héchste Partituren geplangt.
Wou gëtt de purpurroude Pod plazéiert?
Op der Foto kënnt Dir gesinn datt de Kube-Scheduler en neie purpurroude Pod plangt. De Kubernetes Cluster enthält zwee Wirbelen: A a B. Wéi Dir gesitt, kann de Kube-Scheduler net e Pod op Node A plangen - déi verfügbar (onerfrote) Ressourcen passen net mat den Ufroe vum purpurroude Pod. Also, den 1 GB vum Gedächtnis ugefrot vum purpurroude Pod passt net op Node A, well déi verfügbar Erënnerung 0,5 GB ass. Awer Node B huet genuch Ressourcen. Als Resultat entscheet de Kube-Scheduler datt d'Destinatioun vum purpurroude Pod Node B ass.
Elo wësse mer wéi déi ugefrote Ressourcen d'Wiel vum Node beaflossen fir de Pod ze lafen. Awer wat ass den Impakt vu marginale Ressourcen?
D'Ressourcelimit ass eng Grenz déi d'CPU / MEM net iwwerschreiden kann. Wéi och ëmmer, d'CPU Ressource ass flexibel, sou datt Container déi hir CPU Limiten erreechen wäerten de Pod net verursaachen. Amplaz fänkt d'CPU Drossel un. Wann d'MEM Benotzungslimit erreecht gëtt, gëtt de Container wéinst OOM-Killer gestoppt an nei gestart wann et erlaabt vun der RestartPolicy Astellung.
Ufroen a maximal Ressourcen am Detail
Ressource Kommunikatioun tëscht Docker a Kubernetes
De beschte Wee fir z'erklären wéi Ressourceufroen a Ressourcelimiten funktionnéieren ass d'Relatioun tëscht Kubernetes an Docker aféieren. Am Bild hei uewen kënnt Dir gesinn wéi d'Kubernetes Felder an Docker Startup Fändelen verbonne sinn.
Erënnerung: Ufro a Begrenzung
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Wéi uewen ernimmt, gëtt d'Erënnerung a Bytes gemooss. Baséiert op , Mir kënnen Erënnerung als Zuel uginn. Normalerweis ass et eng ganz Zuel, zum Beispill 2678 - dat ass 2678 Bytes. Dir kënnt och Suffixe benotzen G и Gi, Den Haapt Saach ass ze erënneren datt se net gläichwäerteg sinn. Déi éischt ass Dezimal an déi zweet ass binär. Wéi d'Beispill ernimmt an der k8s Dokumentatioun: 128974848, 129e6, 129M, 123Mi - si sinn praktesch gläichwäerteg.
Kubernetes Optioun limits.memory entsprécht dem Fändel --memory vum Docker. Am Fall vun request.memory Et gëtt kee Pfeil fir Docker well Docker dëst Feld net benotzt. Dir kënnt froen, ass dat iwwerhaapt néideg? Jo brauch. Wéi ech virdru gesot hunn, ass d'Feld wichteg fir Kubernetes. Baséierend op d'Informatioun dovun, entscheet de Kube-Scheduler op wéi engem Node de Pod plangt.
Wat geschitt wann Dir net genuch Erënnerung fir eng Ufro setzt?
Wann de Container d'Limite vum ugefrote Gedächtnis erreecht huet, da gëtt de Pod an eng Grupp vu Pods plazéiert, déi ophalen wann et net genuch Erënnerung am Node ass.
Wat geschitt wann Dir d'Erënnerung Limit ze niddreg setzt?
Wann de Container d'Erënnerungslimit iwwerschreift, gëtt et wéinst OOM-Killed ofgeschloss. A wäert nei starten wa méiglech baséiert op RestartPolicy wou de Standardwäert ass Always.
Wat geschitt wann Dir déi ugefrote Erënnerung net uginn?
Kubernetes wäert de Limitwäert huelen an en als Standardwäert setzen.
Wat kann geschéien wann Dir keng Erënnerung Limite uginn?
De Container huet keng Restriktiounen; et kann esou vill Erënnerung benotzen wéi et wëllt. Wann hien ufänkt all verfügbar Erënnerung vum Node ze benotzen, da wäert OOM him ëmbréngen. De Container gëtt dann nei gestart wa méiglech baséiert op RestartPolicy.
Wat geschitt wann Dir keng Erënnerung Grenzen uginn?
Dëst ass de schlëmmste Fall Szenario: de Scheduler weess net wéi vill Ressourcen de Container erfuerdert, an dëst kann sérieux Probleemer um Node verursaachen. An dësem Fall wier et schéin Standardlimiten op den Nummraum ze hunn (vun LimitRange festgeluecht). Et gi keng Standardgrenzen - de Pod huet keng Grenzen, et kann sou vill Erënnerung benotzen wéi et wëllt.
Wann dat ugefrote Gedächtnis méi ass wéi de Node ka bidden, gëtt de Pod net geplangt. Et ass wichteg dat ze erënneren Requests.memory - net de Minimum Wäert. Dëst ass eng Beschreiwung vun der Quantitéit un Erënnerung genuch fir de Container kontinuéierlech ze halen.
Et gëtt normalerweis recommandéiert fir dee selwechte Wäert ze setzen request.memory и limit.memory. Dëst garantéiert datt Kubernetes net e Pod op engem Node plangt deen genuch Erënnerung huet fir de Pod ze lafen awer net genuch fir se ze lafen. Denkt drun: Kubernetes Pod Planung berücksichtegt nëmmen requests.memoryan limits.memory hëlt net Rechnung.
CPU: Ufro an Limite
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Mat enger CPU ass alles e bësse méi komplizéiert. Zréck op d'Bild vun der Bezéiung tëscht Kubernetes an Docker, kënnt Dir dat gesinn request.cpu entsprécht --cpu-shares, wärend limit.cpu entsprécht dem Fändel cpus an Docker.
D'CPU déi Kubernetes freet gëtt mat 1024 multiplizéiert, den Undeel vun de CPU-Zyklen. Wann Dir wëllt 1 voll Kär ufroen, Dir musst derbäi cpu: 1wéi uewen gewisen.
E komplette Kernel ufroen (Proportioun = 1024) heescht net datt Äre Container et kritt. Wann Är Hostmaschinn nëmmen ee Kär huet an Dir méi wéi ee Container leeft, da mussen all Container déi verfügbar CPU tëscht hinnen deelen. Wéi geschitt dat? Loosst eis d'Bild kucken.
CPU Ufro - Single Kär System
Loosst eis virstellen datt Dir en Single-Core Host System hutt, deen Container leeft. Mamm (Kubernetes) huet e Patt (CPU) gebak a wëll et tëscht Kanner (Container) opdeelen. Dräi Kanner wëllen e ganze Kuch (Proportioun = 1024), en anert Kand wëll en halleft Kuch (512). Mamm wëll fair sinn a mécht eng einfach Berechnung.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%No der Berechnung kréien dräi Kanner 28% vum Kär, an net de ganzen Kär. Dat véiert Kand kritt 14% vum vollen Kär, net d'Halschent. Awer d'Saache wäerten anescht sinn wann Dir e Multi-Core System hutt.
CPU Ufro - Multi-Core (4) System
Am Bild hei uewen kënnt Dir gesinn datt dräi Kanner e ganze Patt wëllen, an een wëll d'Halschent. Well d'Mamm véier Kuchen gebak huet, kritt jidderee vun hire Kanner esou vill wéi se wëllen. An engem Multi-Core System gi Prozessorressourcen iwwer all verfügbare Prozessorkäre verdeelt. Wann e Container op manner wéi ee vollen CPU Kär limitéiert ass, kann et nach ëmmer op 100% benotzen.
Déi uewe genannte Berechnunge si vereinfacht fir ze verstoen wéi d'CPU tëscht Container verdeelt ass. Natierlech, nieft de Container selwer, ginn et aner Prozesser déi och CPU Ressourcen benotzen. Wann Prozesser an engem Container Idle sinn, kënnen anerer seng Ressource benotzen. CPU: "200m" entsprécht CPU: 0,2, dat heescht ongeféier 20% vun engem Kär.
Elo schwätze mer iwwer limit.cpu. D'CPU déi Kubernetes limitéiert gëtt multiplizéiert mat 100. D'Resultat ass d'Quantitéit vun Zäit de Container all 100 µs (cpu-period).
limit.cpu entsprécht dem Docker Fändel --cpus. Dëst ass eng nei Kombinatioun vun al --cpu-period и --cpu-quota. Andeems Dir et setzt, weisen mir wéivill verfügbar CPU Ressourcen de Container maximal ka benotzen ier d'Drossel ufänkt:
- cpu - Kombinatioun
cpu-periodиcpu-quota. cpus = 1.5gläichwäerteg zu Astellungcpu-period = 100000иcpu-quota = 150000; - CPU-Period - Period , Standard 100 Mikrosekonnen;
- cpu-Quote - Zuel vun microseconds bannen
cpu-period, déi vum Container begrenzt ass.
Wat geschitt wann Dir net genuch ugefrote CPU installéiert?
Wann de Container méi brauch wéi et installéiert ass, klaut se CPU vun anere Prozesser.
Wat geschitt wann Dir d'CPU Limit ze niddreg setzt?
Zënter datt d'CPU-Ressource justierbar ass, gëtt Drossel op.
Wat geschitt wann Dir keng CPU Ufro uginn?
Wéi mat Erënnerung ass den Ufrowäert gläich un der Limit.
Wat geschitt wann Dir keng CPU Limite uginn?
De Container benotzt sou vill CPU wéi et brauch. Wann eng Standard CPU Politik (LimitRange) am Nummraum definéiert ass, da gëtt dës Limit och fir de Container benotzt.
Wat geschitt wann Dir keng Ufro oder eng CPU Limite uginn?
Wéi mat Erënnerung, ass dëst de schlëmmste Fall Szenario. De Scheduler weess net wéivill Ressourcen Äre Container brauch, an dëst kann sérieux Problemer um Node verursaachen. Fir dëst ze vermeiden, musst Dir Standardlimite fir Nummraim setzen (LimitRange).
Denkt drun: wann Dir méi CPU ufrot wéi d'Node kënnen ubidden, gëtt de Pod net geplangt. Requests.cpu - net de Mindestwäert, awer e Wäert genuch fir de Pod unzefänken an ouni Feeler ze schaffen. Wann d'Applikatioun keng komplex Berechnunge mécht, ass déi bescht Optioun ze installéieren request.cpu <= 1 a lancéiert sou vill Repliken wéi néideg.
Ideal Betrag vun ugefrote Ressourcen oder Ressourcelimit
Mir hunn iwwer d'Begrenzung vu Rechenressourcen geléiert. Elo ass et Zäit d'Fro ze beäntweren: "Wéi vill Ressourcen brauch mäi Pod fir d'Applikatioun ouni Probleemer ze lafen? Wat ass den ideale Betrag?
Leider ginn et keng kloer Äntwerten op dës Froen. Wann Dir net wësst wéi Är Applikatioun funktionnéiert oder wéi vill CPU oder Erënnerung se brauch, ass déi bescht Optioun der Applikatioun vill Erënnerung an CPU ze ginn an dann Performance Tester auszeféieren.
Zousätzlech zu Leeschtungstester, iwwerwaacht d'Verhalen vun der Applikatioun bei der Iwwerwaachung fir eng Woch. Wann d'Grafiken uginn datt Är Applikatioun manner Ressourcen verbraucht wéi Dir gefrot hutt, kënnt Dir d'Quantitéit u CPU oder Erënnerung reduzéieren.
Als Beispill kuckt dëst . Et weist den Ënnerscheed tëscht de gefrote Ressourcen oder Ressourcelimit an der aktueller Ressourceverbrauch.
Konklusioun
Ressourcen ufroen a limitéieren hëlleft Äre Kubernetes Cluster gesond ze halen. Richteg Limitkonfiguratioun miniméiert d'Käschte an hält d'Applikatiounen zu all Moment lafen.
Kuerz gesot, et ginn e puer Saachen am Kapp ze halen:
- Gefuerdert Ressourcen sinn eng Konfiguratioun déi bei der Startzäit berücksichtegt gëtt (wann Kubernetes plangt d'Applikatioun ze hosten). Am Géigesaz, Ressourcen limitéieren ass wichteg beim Runtime - wann d'Applikatioun scho um Node leeft.
- Am Verglach mat Erënnerung ass d'CPU eng reglementéiert Ressource. Wann et net genuch CPU ass, gëtt Äre Pod net ausgeschalt an den Drosselmechanismus gëtt ageschalt.
- Ufro Ressourcen a Ressource Limite sinn net Minimum a maximal Wäerter! Andeems Dir déi ugefrote Ressourcen definéiert, garantéiert Dir datt d'Applikatioun ouni Probleemer leeft.
- Eng gutt Praxis ass d'Erënnerungsufro gläich wéi d'Erënnerungslimit ze setzen.
- Ok Installatioun gefrot
CPU <=1, wann d'Applikatioun keng komplex Berechnungen mécht. - Wann Dir méi Ressourcen freet wéi op engem Node verfügbar ass, gëtt de Pod ni op deen Node geplangt.
- Fir de richtege Betrag vun ugefrote Ressourcen / Ressourcelimiten ze bestëmmen, benotzt Lasttesten an Iwwerwaachung.
Ech hoffen dësen Artikel hëlleft Iech d'Basiskonzept vun der Ressourcebegrenzung ze verstoen. An Dir wäert fäeg sinn dëst Wëssen an Ärer Aarbecht ëmzesetzen.
Vill Gléck!
Wat soss ze liesen:
- .
- .
- .
Source: will.com