Nalika ngamimitian sareng Kubernetes, biasa hilap ngeunaan nyetél sumber wadahna. Dina titik ieu, cukup pikeun mastikeun yén gambar Docker tiasa dianggo sareng tiasa disebarkeun kana klaster Kubernetes.
Tapi engké aplikasina kedah disebarkeun dina klaster produksi sareng aplikasi anu sanés. Jang ngalampahkeun ieu, anjeun kudu allocate sumberdaya pikeun wadahna sarta pastikeun yén aya cukup di antarana pikeun meunangkeun aplikasi nepi na ngajalankeun, sarta yén aplikasi ngajalankeun séjén moal ngalaman masalah.
regu narjamahkeun artikel ngeunaan sumberdaya wadahna (CPU & MEM), requests sarta watesan sumberdaya. Anjeun bakal diajar mangpaat setelan ieu sareng naon anu bakal kajadian upami anjeun henteu nyetélana.
sumberdaya komputasi
Kami ngagaduhan dua jinis sumber daya sareng unit ieu:
- Unit processing sentral (CPU) - cores;
- Mémori (MEM) - bait.
Sumberdaya dieusian pikeun tiap wadahna. Dina file Pod YAML di handap ieu, anjeun bakal ningali bagian sumberdaya anu ngandung sumber anu dipénta sareng ngawatesan:
- Dipénta Pod Sumberdaya = jumlah sumberdaya dipénta sadaya wadahna;
- Wates Sumber Daya Pod = Jumlah sadaya Wates Sumber Daya 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: 1GiConto Dipénta jeung Sumberdaya kawates
médan resources.requested ti spésifikasi Pod mangrupa salah sahiji elemen anu dipaké pikeun manggihan titik nu dipikahoyong. Anjeun parantos tiasa ngarencanakeun panyebaran Pod pikeun éta. Kumaha anjeun mendakan titik anu cocog?
Kubernetes diwangun ku sababaraha komponén, kaasup master node atawa master node (Kubernetes Control Plane). Master node ngagaduhan sababaraha prosés: kube-apiserver, kube-controller-manager sareng kube-scheduler.
Prosés kube-scheduler tanggung jawab pikeun marios pods anu nembé diciptakeun sareng milarian titik-titik padamel anu cocog sareng sadaya pamundut pod, kalebet jumlah sumber anu dipénta. Daptar titik nu kapanggih ku kube-scheduler ieu rengking. Pod dijadwalkeun dina titik kalayan skor pangluhurna.
Dimana Pod ungu bakal disimpen?
Dina gambar anjeun tiasa ningali yén kube-scheduler kedah ngajadwalkeun Pod ungu anyar. Kluster Kubernetes ngandung dua titik: A jeung B. Salaku bisa ningali, kube-scheduler teu tiasa ngajadwalkeun Pod on titik A - sumberdaya sadia (unrequested) teu cocog requests Pod ungu. Janten, mémori 1 GB anu dipénta ku Pod ungu moal pas dina titik A, sabab mémori anu sayogi nyaéta 0,5 GB. Tapi titik B boga cukup sumberdaya. Hasilna, kube-scheduler mutuskeun yén tujuan Pod ungu nyaéta titik B.
Ayeuna urang terang kumaha sumber anu dipénta mangaruhan pilihan titik pikeun ngajalankeun Pod. Tapi naon dampak sumberdaya marginal?
Wates sumberdaya mangrupakeun wates nu CPU / MEM teu bisa meuntas. Nanging, sumber daya CPU fleksibel, janten wadah anu ngahontal wates CPUna moal nyababkeun Pod kaluar. Gantina, CPU throttling bakal ngamimitian. Lamun wates pamakéan MEM ngahontal, wadahna bakal dieureunkeun alatan OOM-Killer sarta restarted lamun diwenangkeun ku setelan RestartPolicy.
Dipénta jeung sumberdaya maksimum di jéntré
Komunikasi sumberdaya antara Docker sareng Kubernetes
Cara anu pangsaéna pikeun ngajelaskeun kumaha pamenta sumber daya sareng wates sumberdaya jalan nyaéta ngenalkeun hubungan antara Kubernetes sareng Docker. Dina gambar di luhur anjeun tiasa ningali kumaha widang Kubernetes sareng bandéra ngamimitian Docker aya hubunganana.
Memori: pamundut jeung watesan
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Sakumaha didadarkeun di luhur, mémori diukur dina bait. Dumasarkeun kana , urang bisa nangtukeun memori salaku angka. Biasana mangrupa integer, contona 2678 - nyaeta, 2678 bait. Anjeun ogé tiasa nganggo sufiks G и Gi, Hal utama anu inget yen aranjeunna henteu sarua. Anu kahiji nyaéta decimal sareng anu kadua binér. Sapertos conto anu disebatkeun dina dokuméntasi k8s: 128974848, 129e6, 129M, 123Mi - aranjeunna praktis sarimbag.
pilihan Kubernetes limits.memory cocog bandéra --memory ti Docker. Dina hal request.memory Henteu aya panah pikeun Docker sabab Docker henteu nganggo widang ieu. Anjeun tiasa naroskeun, naha ieu diperyogikeun? Sumuhun peryogi. Sakumaha anu kuring nyarios sateuacanna, lapangan penting pikeun Kubernetes. Dumasar kana inpormasi ti éta, kube-scheduler mutuskeun titik mana pikeun ngajadwalkeun Pod.
Naon kajadian lamun nyetel memori cukup pikeun pamundut a?
Upami wadahna parantos dugi ka wates mémori anu dipénta, teras Pod disimpen dina grup Pods anu eureun nalika teu aya mémori anu cukup dina node.
Naon anu lumangsung lamun anjeun nyetel wates memori low teuing?
Lamun wadahna ngaleuwihan wates memori, eta bakal terminated alatan OOM-dibunuh. Sareng bakal balikan deui upami mungkin dumasar kana RestartPolicy dimana nilai standarna Always.
Naon anu bakal kajadian upami anjeun henteu netepkeun mémori anu dipénta?
Kubernetes bakal nyandak nilai wates sareng nyetél éta salaku nilai standar.
Naon anu tiasa kajantenan upami anjeun henteu netepkeun wates mémori?
Wadahna henteu aya larangan; éta tiasa nganggo saloba mémori anu dipikahoyong. Upami anjeunna mimiti nganggo sadaya mémori anu aya dina node, maka OOM bakal maéhan anjeunna. Wadahna teras bakal dibalikan deui upami mungkin dumasar kana RestartPolicy.
Naon kajadian lamun teu nangtukeun wates memori?
Ieu mangrupikeun skenario anu paling parah: penjadwal henteu terang sabaraha sumber anu diperyogikeun wadahna, sareng ieu tiasa nyababkeun masalah anu serius dina node. Dina hal ieu, éta bakal hade mun boga wates standar dina spasi ngaran (disetel ku LimitRange). Henteu aya wates standar - Pod henteu aya watesna, éta tiasa nganggo mémori anu dipikahoyong.
Upami mémori anu dipénta langkung seueur tibatan titik anu tiasa ditawarkeun, Pod moal dijadwalkeun. Kadé émut éta Requests.memory - teu nilai minimum. Ieu pedaran jumlah mémori cukup pikeun ngajaga wadahna jalan terus.
Ieu biasana dianjurkeun pikeun ngeset nilai sarua pikeun request.memory и limit.memory. Ieu mastikeun yén Kubernetes moal ngajadwalkeun Pod dina titik anu gaduh mémori anu cukup pikeun ngajalankeun Pod tapi henteu cekap pikeun ngajalankeun éta. Émut: Perencanaan Kubernetes Pod ngan ukur dipertimbangkeun requests.memoryjeung limits.memory teu tumut kana akun.
CPU: pamundut jeung wates
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Kalawan CPU a sagalana nyaéta saeutik leuwih pajeulit. Balik deui ka gambar hubungan antara Kubernetes sareng Docker, anjeun tiasa ningali éta request.cpu соответствует --cpu-shares, padahal limit.cpu cocog bandéra cpus di Docker.
CPU anu dipénta ku Kubernetes dikalikeun ku 1024, proporsi siklus CPU. Upami anjeun hoyong menta 1 inti pinuh, anjeun kudu nambahan cpu: 1sakumaha ditémbongkeun di luhur.
Nyuhunkeun kernel pinuh (proporsi = 1024) henteu hartosna wadah anjeun bakal nampi éta. Upami mesin host anjeun ngan ukur gaduh hiji inti sareng anjeun ngajalankeun langkung ti hiji wadah, maka sadaya wadah kedah ngabagi CPU anu sayogi diantara aranjeunna. Kumaha ieu kajadian? Hayu urang nempo gambar.
CPU Request - Single Core System
Hayu urang ngabayangkeun yén anjeun gaduh sistem host single-core ngajalankeun wadahna. Ibu (Kubernetes) dipanggang pai (CPU) jeung hayang ngabagi antara barudak (wadah). Tilu murangkalih hoyong pai sadayana (proporsi = 1024), murangkalih deui hoyong satengah pai (512). Ibu hayang adil jeung nyieun itungan basajan.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Dumasar kana itungan, tilu murangkalih bakal nampi 28% tina inti, sanés sadayana inti. Anak kaopat bakal meunang 14% tina kernel pinuh, teu satengah. Tapi hal bakal béda lamun boga sistem multi-inti.
CPU Request - Multi-Core (4) Sistim
Dina gambar di luhur anjeun bisa nempo yén tilu barudak hayang sakabeh pai, sarta hiji hayang satengah. Kusabab mom dipanggang opat pai, unggal anakna bakal meunang saloba aranjeunna hoyong. Dina sistem multi-inti, sumber daya prosésor disebarkeun ka sadaya inti prosésor anu aya. Upami wadahna dugi ka kirang ti hiji inti CPU pinuh, éta masih tiasa dianggo dina 100%.
Itungan di luhur disederhanakeun pikeun ngartos kumaha CPU disebarkeun diantara wadah. Tangtosna, salian wadahna sorangan, aya prosés sanés anu ogé ngagunakeun sumber CPU. Nalika prosés dina hiji wadah dianggurkeun, batur tiasa nganggo sumberna. CPU: "200m" соответствует CPU: 0,2, nu hartina kurang leuwih 20% tina hiji inti.
Ayeuna hayu urang ngobrol ngeunaan limit.cpu. CPU anu diwatesan ku Kubernetes dikali 100. Hasilna nyaéta jumlah waktos wadahna tiasa dianggo unggal 100 µs (cpu-period).
limit.cpu cocog jeung bandéra Docker --cpus. Ieu kombinasi anyar heubeul --cpu-period и --cpu-quota. Ku netepkeunana, kami nunjukkeun sabaraha sumber daya CPU anu sayogi wadahna tiasa dianggo maksimal sateuacan throttling dimimitian:
- bosus - kombinasi
cpu-periodиcpu-quota. cpus = 1.5sarua jeung settingcpu-period = 100000иcpu-quota = 150000; - CPU-jaman - jaman , standar 100 microseconds;
- cpu-kuota - Jumlah microseconds jero
cpu-period, nu diwatesan ku wadahna.
Naon anu lumangsung upami anjeun masang CPU anu dipénta henteu cekap?
Upami wadahna peryogi langkung ti anu dipasang, éta bakal maok CPU tina prosés anu sanés.
Naon anu lumangsung lamun anjeun nyetel wates CPU low teuing?
Kusabab sumber daya CPU tiasa disaluyukeun, throttling bakal hurung.
Naon anu lumangsung upami anjeun henteu netepkeun pamundut CPU?
Salaku kalawan memori, nilai pamundut sarua jeung wates.
Naon anu lumangsung upami anjeun henteu netepkeun wates CPU?
Wadahna bakal nganggo saloba CPU anu diperyogikeun. Lamun kawijakan CPU standar (LimitRange) dihartikeun dina spasi ngaran, lajeng wates ieu ogé dipaké pikeun wadahna.
Naon anu lumangsung upami anjeun henteu netepkeun pamundut atanapi wates CPU?
Sapertos mémori, ieu mangrupikeun skenario anu paling parah. Penjadwal henteu terang sabaraha sumber anu diperyogikeun wadahna, sareng ieu tiasa nyababkeun masalah anu serius dina node. Pikeun ngahindarkeun ieu, anjeun kedah nyetél wates standar pikeun rohangan ngaran (LimitRange).
Inget: lamun menta CPU leuwih ti titik bisa nyadiakeun, Pod moal dijadwalkeun. Requests.cpu - teu nilai minimum, tapi hiji nilai cukup pikeun ngamimitian Pod jeung karya tanpa gagal. Upami aplikasi henteu ngalakukeun itungan anu rumit, pilihan pangsaéna nyaéta masang request.cpu <= 1 tur ngajalankeun saloba réplika sakumaha diperlukeun.
Jumlah idéal sumberdaya dipénta atawa wates sumberdaya
Urang diajar ngeunaan watesan sumberdaya komputasi. Ayeuna waktuna pikeun ngajawab patarosan: "Sabaraha sumber Pod abdi peryogi pikeun ngajalankeun aplikasi tanpa masalah? Naon jumlah idéal?
Hanjakalna, teu aya jawaban anu jelas pikeun patarosan ieu. Upami anjeun henteu terang kumaha aplikasi anjeun tiasa dianggo atanapi sabaraha CPU atanapi mémori anu diperyogikeun, pilihan pangsaéna nyaéta masihan aplikasi seueur mémori sareng CPU teras ngajalankeun tés kinerja.
Salian tés kinerja, mantau paripolah aplikasi dina ngawaskeun salila saminggu. Lamun grafik nunjukkeun yén aplikasi Anjeun consuming sumberdaya pangsaeutikna ti anjeun dipénta, Anjeun bisa ngurangan jumlah CPU atawa memori dipénta.
Salaku conto tingali ieu . Ieu mintonkeun bédana antara sumberdaya dipénta atawa wates sumberdaya jeung pamakéan sumberdaya ayeuna.
kacindekan
Nyuhunkeun sareng ngawatesan sumberdaya ngabantosan kluster Kubernetes anjeun tetep séhat. Konfigurasi wates anu leres ngaminimalkeun biaya sareng ngajaga aplikasi dijalankeun unggal waktos.
Pondokna, aya sababaraha hal anu kudu diperhatikeun:
- Sumber daya anu dipénta nyaéta konfigurasi anu dipertimbangkeun dina waktos ngamimitian (nalika Kubernetes ngarencanakeun pikeun nga-host aplikasi). Kontras, ngawatesan sumberdaya penting dina runtime-nalika aplikasi geus ngajalankeun on node.
- Dibandingkeun mémori, CPU mangrupikeun sumber anu diatur. Upami teu cekap CPU, Pod anjeun moal pareum sareng mékanisme throttling bakal hurung.
- Sumberdaya anu dipénta sareng wates sumberdaya sanés nilai minimum sareng maksimal! Ku nangtukeun sumberdaya dipénta, anjeun mastikeun yén aplikasi bakal ngajalankeun tanpa masalah.
- Prakték anu saé nyaéta nyetél pamundut mémori anu sami sareng wates mémori.
- Ok dipasang dipénta
CPU <=1, lamun aplikasi teu ngalakukeun itungan kompléks. - Upami anjeun nyuhunkeun sumber daya langkung seueur tibatan anu sayogi dina node, Pod moal pernah dijadwalkeun kana node éta.
- Pikeun nangtukeun jumlah bener sumberdaya dipénta / wates sumberdaya, ngagunakeun nguji beban sarta ngawaskeun.
Kuring miharep artikel ieu mantuan anjeun ngartos konsép dasar watesan sumberdaya. Sareng anjeun bakal tiasa nerapkeun pangaweruh ieu dina padamelan anjeun.
Ayaan!
Naon deui anu dibaca:
- .
- .
- .
sumber: www.habr.com