Sa pagsugod sa Kubernetes, kasagarang kalimtan ang bahin sa pag-set up sa mga kahinguhaan sa sudlanan. Niini nga punto, igo na aron masiguro nga ang imahe sa Docker molihok ug mahimong i-deploy sa cluster sa Kubernetes.
Apan sa ulahi ang aplikasyon kinahanglan nga i-deploy sa usa ka cluster sa produksiyon kauban ang ubang mga aplikasyon. Aron mahimo kini, kinahanglan nimo nga igahin ang mga kapanguhaan alang sa sulud ug siguroha nga adunay igo niini aron mapadayon ang aplikasyon ug nga ang uban nga nagdagan nga mga aplikasyon dili makasinati mga problema.
team naghubad ug artikulo bahin sa mga kahinguhaan sa sudlanan (CPU & MEM), mga hangyo ug mga limitasyon sa kahinguhaan. Mahibal-an nimo ang mga benepisyo sa kini nga mga setting ug kung unsa ang mahitabo kung dili nimo kini itakda.
Mga kapanguhaan sa pag-compute
Kita adunay duha ka matang sa mga kapanguhaan uban sa mosunod nga mga yunit:
- Central processing unit (CPU) - mga core;
- Memorya (MEM) - mga byte.
Ang mga kapanguhaan gitakda alang sa matag sudlanan. Sa mosunod nga Pod YAML file, imong makita ang usa ka resource section nga naglangkob sa gipangayo ug limitahan nga resources:
- Gipangayo nga Pod Resources = sum sa gipangayo nga mga kahinguhaan sa tanang sudlanan;
- Limitasyon sa Kapanguhaan sa Pod = Suma sa tanang Limitasyon sa Kapanguhaan sa 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: 1GiPananglitan sa Gipangayo ug Limitado nga mga Kapanguhaan
uma resources.requested gikan sa detalye Pod mao ang usa sa mga elemento nga gigamit sa pagpangita sa gitinguha nga node. Mahimo ka nang magplano sa pag-deploy sa Pod alang niini. Giunsa nimo pagpangita ang angay nga node?
Ang Kubernetes naglangkob sa daghang mga sangkap, lakip ang usa ka master node o master node (Kubernetes Control Plane). Ang master node adunay daghang mga proseso: kube-apiserver, kube-controller-manager ug kube-scheduler.
Ang proseso sa kube-scheduler maoy responsable sa pagrepaso sa bag-ong nabuhat nga mga pod ug pagpangita sa posibleng mga worker node nga mohaum sa tanang pod nga hangyo, lakip ang gidaghanon sa mga kahinguhaan nga gipangayo. Ang lista sa mga node nga nakit-an sa kube-scheduler giranggo. Ang pod naka-iskedyul sa node nga adunay pinakataas nga score.
Asa ibutang ang purpura nga Pod?
Sa hulagway makita nimo nga ang kube-scheduler kinahanglan nga mag-iskedyul og bag-ong purple Pod. Ang Kubernetes cluster adunay duha ka node: A ug B. Sama sa imong makita, ang kube-scheduler dili maka-iskedyul og Pod sa node A - ang anaa (wala gipangayo) nga mga kapanguhaan dili motakdo sa mga hangyo sa purpura nga Pod. Busa, ang 1 GB nga panumduman nga gipangayo sa purpura nga Pod dili mohaum sa node A, tungod kay ang anaa nga panumduman maoy 0,5 GB. Apan ang node B adunay igo nga mga kapanguhaan. Ingon usa ka sangputanan, ang kube-scheduler nakahukom nga ang destinasyon sa purpura nga Pod mao ang node B.
Karon nahibal-an na namon kung giunsa ang gihangyo nga mga kapanguhaan makaapekto sa pagpili sa node nga modagan sa Pod. Apan unsa ang epekto sa marginal resources?
Ang limitasyon sa kahinguhaan usa ka utlanan nga dili matabok sa CPU/MEM. Bisan pa, ang kapanguhaan sa CPU flexible, mao nga ang mga sudlanan nga makaabut sa ilang mga limitasyon sa CPU dili hinungdan sa paggawas sa Pod. Hinuon, magsugod ang pag-throttling sa CPU. Kung ang limitasyon sa paggamit sa MEM maabot, ang sudlanan ihunong tungod sa OOM-Killer ug i-restart kung gitugotan sa setting sa RestartPolicy.
Gihangyo ug maximum nga mga kapanguhaan sa detalye
Resource komunikasyon tali sa Docker ug Kubernetes
Ang labing maayo nga paagi sa pagpatin-aw kung giunsa ang mga hangyo sa kahinguhaan ug mga limitasyon sa kapanguhaan molihok mao ang pagpaila sa relasyon tali sa Kubernetes ug Docker. Sa imahe sa ibabaw imong makita kung giunsa ang mga natad sa Kubernetes ug mga bandila sa pagsugod sa Docker adunay kalabutan.
Memorya: hangyo ug limitasyon
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Sama sa gihisgutan sa ibabaw, ang memorya gisukod sa bytes. Base sa , mahimo natong ipiho ang memorya isip numero. Kasagaran kini usa ka integer, pananglitan 2678 - nga mao, 2678 bytes. Mahimo usab nimo gamiton ang mga suffix G и Gi, ang nag-unang butang mao ang paghinumdom nga sila dili katumbas. Ang una mao ang decimal ug ang ikaduha mao ang binary. Sama sa pananglitan nga gihisgutan sa k8s nga dokumentasyon: 128974848, 129e6, 129M, 123Mi - sila halos katumbas.
Opsyon sa Kubernetes limits.memory pareha sa bandera --memory gikan sa Docker. Sa kaso sa request.memory Wala’y pana alang sa Docker tungod kay wala gigamit ni Docker kini nga uma. Mahimong mangutana ka, kinahanglan pa ba kini? Oo kinahanglan. Sama sa akong giingon kaniadto, ang uma hinungdanon alang sa Kubernetes. Pinasukad sa kasayuran gikan niini, ang kube-scheduler nagdesisyon kung unsang node ang eskedyul sa Pod.
Unsa ang mahitabo kung magbutang ka og dili igo nga memorya alang sa usa ka hangyo?
Kung ang sudlanan nakaabot sa mga limitasyon sa gihangyo nga panumduman, nan ang Pod ibutang sa usa ka grupo sa mga Pod nga mohunong kung wala’y igo nga memorya sa node.
Unsa ang mahitabo kung imong gibutang ang limitasyon sa memorya nga ubos kaayo?
Kung ang sudlanan molapas sa limitasyon sa memorya, kini mahunong tungod sa OOM-Killed. Ug i-restart kung mahimo base sa RestartPolicy kung diin ang default nga kantidad Always.
Unsa ang mahitabo kung dili nimo ipiho ang gihangyo nga memorya?
Ang Kubernetes mokuha sa limit nga kantidad ug itakda kini isip default value.
Unsa ang mahitabo kung dili nimo itakda ang limitasyon sa memorya?
Ang sudlanan walay mga pagdili; kini makagamit sa daghang panumduman sumala sa gusto niini. Kung magsugod siya sa paggamit sa tanan nga magamit nga memorya sa node, dayon patyon siya sa OOM. Ang sudlanan i-restart kung mahimo base sa RestartPolicy.
Unsa ang mahitabo kung dili nimo itakda ang mga limitasyon sa memorya?
Kini ang pinakagrabe nga sitwasyon sa kaso: ang scheduler wala mahibalo kon pila ka mga kahinguhaan ang gikinahanglan sa sudlanan, ug kini mahimong hinungdan sa seryoso nga mga problema sa node. Sa kini nga kaso, maayo nga adunay mga default nga limitasyon sa namespace (gitakda sa LimitRange). Walay default nga mga limitasyon - ang Pod walay mga limitasyon, kini makagamit sa daghang memorya nga gusto niini.
Kung ang gihangyo nga memorya labaw pa sa matanyag sa node, ang Pod dili ma-iskedyul. Importante nga hinumdoman kana Requests.memory - dili ang minimum nga kantidad. Kini usa ka paghulagway sa gidaghanon sa panumduman nga igo aron magpadayon ang sudlanan nga padayon nga nagdagan.
Kasagaran girekomenda nga itakda ang parehas nga kantidad alang sa request.memory и limit.memory. Kini nagsiguro nga ang Kubernetes dili mag-iskedyul sa usa ka Pod sa usa ka node nga adunay igong memorya sa pagpadagan sa Pod apan dili igo sa pagpadagan niini. Hinumdumi: Ang pagplano sa Kubernetes Pod gikonsiderar lamang requests.memoryug limits.memory wala magtagad.
CPU: hangyo ug limitasyon
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Uban sa usa ka CPU ang tanan mas komplikado. Pagbalik sa hulagway sa relasyon tali sa Kubernetes ug Docker, imong makita kana request.cpu соответствует --cpu-shares, samtang limit.cpu pareha sa bandera cpus sa Docker.
Ang CPU nga gihangyo sa Kubernetes gipadaghan sa 1024, ang proporsyon sa mga siklo sa CPU. Kung gusto nimo mangayo og 1 ka bug-os nga kinauyokan, kinahanglan nimong idugang cpu: 1ingon sa gipakita sa ibabaw.
Ang pagpangayo og bug-os nga kernel (proporsyon = 1024) wala magpasabot nga ang imong sudlanan makadawat niini. Kung ang imong host machine adunay usa ra ka kinauyokan ug nagdagan ka labaw sa usa ka sudlanan, nan ang tanan nga mga sudlanan kinahanglan magpaambit sa magamit nga CPU taliwala nila. Sa unsang paagi kini mahitabo? Atong tan-awon ang hulagway.
Pangayo sa CPU - Usa ka Core nga Sistema
Hunahunaa nga ikaw adunay usa ka single-core host system nga nagdagan nga mga sudlanan. Nagluto si Nanay (Kubernetes) og pie (CPU) ug gusto niyang bahinon sa mga bata (container). Tulo ka bata gusto og tibuok pie (proporsyon = 1024), laing bata gusto og tunga sa pie (512). Gusto ni Mama nga patas ug mohimo ug simple nga kalkulasyon.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Base sa kalkulasyon, tulo ka bata ang makadawat sa 28% sa kinauyokan, ug dili sa tibuok kinauyokan. Ang ikaupat nga bata makadawat og 14% sa tibuok kernel, dili katunga. Apan lahi ang mga butang kung adunay ka multi-core nga sistema.
CPU Request - Multi-Core (4) nga Sistema
Sa hulagway sa ibabaw imong makita nga ang tulo ka bata gusto og tibuok nga pie, ug ang usa gusto ang katunga. Sanglit si mama nagluto ug upat ka pie, ang matag usa sa iyang mga anak makadawat ug daghan kutob sa ilang gusto. Sa usa ka multi-core nga sistema, ang mga kapanguhaan sa processor giapod-apod sa tanan nga magamit nga mga cores sa processor. Kon ang usa ka sudlanan limitado ngadto sa ubos sa usa ka bug-os nga CPU core, kini sa gihapon magamit kini sa 100%.
Ang mga kalkulasyon sa ibabaw gipasayon aron masabtan kung giunsa ang pag-apod-apod sa CPU sa mga sudlanan. Siyempre, gawas sa mga sudlanan mismo, adunay ubang mga proseso nga naggamit usab sa mga kapanguhaan sa CPU. Kung ang mga proseso sa usa ka sudlanan walay pulos, ang uban makagamit sa kapanguhaan niini. CPU: "200m" соответствует CPU: 0,2, nga nagpasabot sa gibana-bana nga 20% sa usa ka core.
Karon atong hisgotan limit.cpu. Ang CPU nga gilimitahan sa Kubernetes gipadaghan sa 100. Ang resulta mao ang gidaghanon sa oras nga magamit sa sudlanan matag 100 µs (cpu-period).
limit.cpu katumbas sa bandila sa Docker --cpus. Kini usa ka bag-ong kombinasyon sa daan --cpu-period и --cpu-quota. Pinaagi sa pag-set niini, among gipakita kung pila ang magamit nga mga kapanguhaan sa CPU nga mahimo’g magamit sa sulud sa wala pa magsugod ang throttling:
- cpus - kombinasyon
cpu-periodиcpu-quota. cpus = 1.5katumbas sa settingcpu-period = 100000иcpu-quota = 150000; - CPU-panahon - panahon , default 100 microseconds;
- cpu-quota - gidaghanon sa mga microsecond sa sulod
cpu-period, nga gigapos sa sudlanan.
Unsa ang mahitabo kung imong gi-install ang dili igo nga gihangyo nga CPU?
Kung ang sudlanan nanginahanglan labi pa sa na-install, kini mangawat sa CPU gikan sa ubang mga proseso.
Unsa ang mahitabo kung imong gibutang ang limitasyon sa CPU nga ubos kaayo?
Tungod kay ang kapanguhaan sa CPU mapaigoigo, ang throttling ma-on.
Unsa ang mahitabo kung dili nimo isulti ang usa ka hangyo sa CPU?
Sama sa memorya, ang kantidad sa hangyo parehas sa limitasyon.
Unsa ang mahitabo kung dili nimo itakda ang limitasyon sa CPU?
Ang sudlanan mogamit sa daghang CPU nga gikinahanglan niini. Kung ang usa ka default nga palisiya sa CPU (LimitRange) gihubit sa namespace, nan kini nga limitasyon gigamit usab alang sa sudlanan.
Unsa ang mahitabo kung dili nimo isulti ang usa ka hangyo o usa ka limitasyon sa CPU?
Sama sa panumduman, kini ang labing daotan nga senaryo. Wala mahibal-an sa scheduler kung pila ka mga kapanguhaan ang gikinahanglan sa imong sudlanan, ug mahimo kini nga hinungdan sa mga seryoso nga problema sa node. Aron malikayan kini, kinahanglan nimong itakda ang mga default nga limitasyon alang sa mga namespaces (LimitRange).
Hinumdomi: kung mangayo ka ug dugang nga CPU kay sa mahatag sa mga node, ang Pod dili ma-iskedyul. Requests.cpu - dili ang minimum nga kantidad, apan usa ka kantidad nga igo aron masugdan ang Pod ug magtrabaho nga wala’y mga kapakyasan. Kung ang aplikasyon wala maghimo komplikado nga mga kalkulasyon, ang labing kaayo nga kapilian mao ang pag-install request.cpu <= 1 ug ilunsad ang daghang mga replika kung gikinahanglan.
Maayo nga kantidad sa gipangayo nga mga kapanguhaan o limitasyon sa kapanguhaan
Nahibal-an namon ang bahin sa limitasyon sa mga kapanguhaan sa pag-compute. Karon na ang panahon sa pagtubag sa pangutana: "Pila ka mga kapanguhaan ang gikinahanglan sa akong Pod aron makadagan ang aplikasyon nga wala’y mga problema? Unsa ang ideal nga kantidad?
Ikasubo, walay klaro nga mga tubag niini nga mga pangutana. Kung wala ka nahibal-an kung giunsa ang paglihok sa imong aplikasyon o kung pila ang kinahanglan nga CPU o memorya, ang labing kaayo nga kapilian mao ang paghatag sa aplikasyon og daghang memorya ug CPU ug dayon pagdagan ang mga pagsulay sa pasundayag.
Dugang sa mga pagsulay sa pasundayag, bantayan ang pamatasan sa aplikasyon sa pag-monitor sulod sa usa ka semana. Kung ang mga graph nagpakita nga ang imong aplikasyon naggamit ug gamay nga mga kapanguhaan kaysa sa imong gihangyo, mahimo nimong pakunhuran ang kantidad sa gipangayo nga CPU o memorya.
Isip usa ka pananglitan tan-awa kini . Gipakita niini ang kalainan tali sa gihangyo nga mga kapanguhaan o limitasyon sa kapanguhaan ug ang karon nga paggamit sa kapanguhaan.
konklusyon
Ang paghangyo ug paglimite sa mga kapanguhaan makatabang nga magpabiling himsog ang imong Kubernetes cluster. Ang tukma nga pag-configure sa limitasyon makapamenos sa gasto ug magpadayon sa pagdagan sa mga aplikasyon sa tanang panahon.
Sa laktud, adunay pipila ka mga butang nga hinumduman:
- Ang gipangayo nga mga kahinguhaan kay usa ka configuration nga gikonsiderar sa oras sa pagsugod (kung ang Kubernetes nagplano nga i-host ang aplikasyon). Sa kasukwahi, ang paglimit sa mga kahinguhaan importante sa runtime—kon ang aplikasyon nagdagan na sa node.
- Kung itandi sa memorya, ang CPU usa ka regulated nga kapanguhaan. Kung walay igo nga CPU, ang imong Pod dili ma-shut down ug ang throttling mechanism mo-on.
- Ang gipangayo nga mga kapanguhaan ug limitasyon sa kahinguhaan dili minimum ug labing taas nga mga kantidad! Pinaagi sa pagtino sa mga kahinguhaan nga gipangayo, imong masiguro nga ang aplikasyon modagan nga walay mga problema.
- Ang usa ka maayong praktis mao ang pagbutang sa hangyo sa panumduman nga katumbas sa limitasyon sa panumduman.
- Ok instalar gihangyo
CPU <=1, kung ang aplikasyon wala maghimo komplikado nga mga kalkulasyon. - Kung mangayo ka ug dugang nga mga kapanguhaan kaysa magamit sa usa ka node, ang Pod dili gyud ma-iskedyul sa kana nga node.
- Aron mahibal-an ang husto nga gidaghanon sa gipangayo nga mga kahinguhaan / mga limitasyon sa kapanguhaan, gamita ang pagsulay sa pagkarga ug pagmonitor.
Nanghinaut ko nga kini nga artikulo makatabang kanimo nga masabtan ang sukaranan nga konsepto sa limitasyon sa kapanguhaan. Ug mahimo nimong magamit kini nga kahibalo sa imong trabaho.
Good luck!
Unsa pa ang basahon:
- .
- .
- .
Source: www.habr.com