Pikeun unggal sumber daya Kubernetes, anjeun tiasa ngonpigurasikeun dua jinis syarat - Paménta sareng Wates. Kahiji ngajelaskeun sarat minimum pikeun kasadiaan sumberdaya titik bébas perlu ngajalankeun wadahna atawa pod, kadua mastikeun watesan sumberdaya sadia pikeun wadahna.
Nalika Kubernetes ngajadwalkeun pods, penting pisan yén wadahna gaduh sumber daya anu cekap pikeun fungsina leres. Upami Anjeun keur perencanaan pikeun nyebarkeun hiji aplikasi badag dina titik sumberdaya-konstrain, éta mungkin yen eta moal jalan sabab node keur ngajalankeun low on memori atawa kaluar tina kakuatan CPU. Dina tulisan ieu, urang bakal ningali kumaha anjeun tiasa ngabéréskeun kakurangan daya komputasi nganggo paménta sumberdaya sareng wates.
Paménta sareng Watesan mangrupikeun mékanisme anu dianggo ku Kubernetes pikeun ngatur sumber daya sapertos CPU sareng mémori. Paménta mangrupikeun anu mastikeun wadahna nampi sumber daya anu dipénta. Upami wadahna nyuhunkeun sumber daya, Kubernetes ngan bakal ngajadwalkeunana dina titik anu tiasa nyayogikeunana. Watesan kontrol yén sumberdaya anu dipénta ku wadahna moal pernah ngaleuwihan nilai anu tangtu.
Hiji wadah ngan bisa ningkatkeun kakuatan komputasi na nepi ka wates nu tangtu, sanggeus éta bakal diwatesan. Hayu urang tingali kumaha gawéna. Janten, aya dua jinis sumber - prosesor sareng mémori. Penjadwal Kubernetes nganggo data ngeunaan sumber daya ieu pikeun terang dimana ngajalankeun pod anjeun. A spésifikasi sumberdaya has pikeun pod a Sigana mah ieu.
Unggal wadahna dina pod a tiasa nyetél queries sorangan sarta wates, éta sakabéh aditif. Sumberdaya prosésor diartikeun dina milicores. Lamun wadah Anjeun perlu dua cores pinuh ngajalankeun, Anjeun nyetel nilai ka 2000m. Upami wadahna ngan ukur peryogi kakuatan 1/4 inti, nilaina bakal 250m. Terus di pikiran nu lamun nangtukeun hiji nilai sumberdaya CPU leuwih gede ti jumlah cores tina titik panggedena, pod Anjeun moal dijadwalkeun pikeun ngamimitian pisan. Kaayaan anu sami bakal kajantenan upami anjeun gaduh Pod anu peryogi opat inti, sareng klaster Kubernetes diwangun ku ukur dua mesin virtual utama.
Iwal aplikasi Anjeun dirancang husus pikeun ngamangpaatkeun sababaraha cores (program kawas komputasi ilmiah kompléks jeung operasi database datang ka pikiran), lajeng prakték pangalusna nyaéta pikeun nyetel Requests CPU ka 1 atawa handap lajeng ngajalankeun leuwih réplika kana scalability. Solusi ieu bakal masihan sistem kalenturan sareng reliabilitas anu langkung ageung.
Lamun datang ka watesan CPU, hal jadi leuwih metot sabab dianggap sumberdaya compressible. Upami aplikasi anjeun mimiti ngadeukeutan wates kakuatan prosesor, Kubernetes bakal mimiti ngalambatkeun wadah anjeun nganggo CPU Throttling - ngirangan frékuénsi prosésor. Ieu ngandung harti yén CPU bakal artifisial throttled, mere aplikasi nu berpotensi kinerja goréng, tapi prosésna moal terminated atawa dicokot kaluar.
sumberdaya memori dihartikeun dina bait. Biasana nilai dina setélan diukur dina mebibytes Mib, tapi anjeun tiasa nyetél nilai naon waé, ti bait ka petabytes. Kaayaan anu sami berlaku di dieu sareng CPU - upami anjeun menta jumlah mémori anu langkung ageung tibatan jumlah mémori dina titik anjeun, éta pod moal dijadwalkeun pikeun ngaéksekusi. Tapi teu saperti sumberdaya CPU, memori teu dikomprés sabab teu aya jalan pikeun ngawatesan pamakéan na. Ku alatan éta, palaksanaan wadahna bakal dieureunkeun pas eta mana saluareun memori disadiakeun pikeun eta.
Penting pikeun émut yén anjeun moal tiasa ngonpigurasikeun pamundut anu ngaleuwihan sumber daya anu tiasa disayogikeun ku node anjeun. spésifikasi sumberdaya dibagikeun pikeun mesin virtual GKE bisa kapanggih dina Tumbu handap video ieu.
Dina dunya anu idéal, setélan standar wadahna bakal cekap pikeun ngajaga alur kerja lancar. Tapi dunya nyata teu kawas éta, jalma bisa kalayan gampang poho pikeun ngonpigurasikeun pamakéan sumberdaya, atawa hacker bakal nangtukeun requests sarta larangan nu ngaleuwihan kamampuhan nyata infrastruktur. Pikeun nyegah skenario sapertos kitu, anjeun tiasa ngonpigurasikeun ResourceQuota sareng kuota sumberdaya LimitRange.
Sakali ngaranspasi geus dijieun, éta bisa diblokir maké kuota. Salaku conto, upami anjeun gaduh rohangan ngaran prod sareng dev, polana henteu aya kuota produksi sareng kuota pangembangan anu ketat pisan. Hal ieu ngamungkinkeun prod, dina acara hiji surge seukeut dina lalulintas, nyandak alih sakabéh sumberdaya sadia, sagemblengna blocking dev.
Kuota sumberdaya tiasa sapertos kieu. Dina conto ieu aya 4 bagian - ieu 4 garis handap kode.
Hayu urang nempo unggal sahijina. Requests.cpu nyaeta jumlah maksimum requests CPU digabungkeun nu bisa datangna tina sagala peti dina namespace nu. Dina conto ieu, anjeun bisa boga 50 peti jeung requests 10m, lima peti jeung requests 100m, atawa ngan hiji wadah kalawan requests 500m. Salami jumlah total requests.cpu of a namespace dibikeun nyaeta kirang ti 500m, sagalana bakal rupa.
Memori dipénta requests.memory nyaeta jumlah maksimum requests memori digabungkeun nu sagala wadah dina namespace tiasa gaduh. Saperti dina kasus saméméhna, anjeun tiasa gaduh 50 2 wadahna mib, lima 20 wadahna mib, atawa 100 wadahna mib tunggal salami jumlah total memori dipénta dina ngaranspasi kirang ti 100 mebibyte.
Limits.cpu mangrupikeun jumlah gabungan maksimum kakuatan CPU anu tiasa dianggo ku sadaya wadah dina rohangan ngaran. Urang tiasa nganggap ieu mangrupikeun wates paménta kakuatan prosesor.
Tungtungna, limits.memory jumlah maksimum dibagikeun memori nu sagala wadah dina namespasi tiasa make. Ieu wates dina total requests memori.
Janten, sacara standar, wadah dina klaster Kubernetes dijalankeun kalayan sumber komputasi anu henteu terbatas. Kalayan kuota sumberdaya, pangurus klaster tiasa ngawates konsumsi sumberdaya sareng nyiptakeun sumberdaya dumasar kana namespace. Dina namespace, pod atawa wadah bisa meakeun saloba kakuatan CPU jeung memori sakumaha ditangtukeun ku kuota sumberdaya namespace. Tapi, aya kahariwang yén hiji pod atanapi wadah tiasa ngamonopoli sadaya sumber daya anu aya. Pikeun nyegah kaayaan ieu, rentang wates dipaké - kawijakan pikeun ngawatesan alokasi sumberdaya (pikeun pods atawa peti) dina namespace.
Kisaran wates nyayogikeun larangan anu tiasa:
- Mastikeun pamakéan minimum jeung maksimum sumberdaya komputasi pikeun tiap modul atawa wadah dina namespace;
- ngalaksanakeun minimum jeung maksimum Starage Request gudang requests pikeun tiap PersistentVolumeClaim dina namespace nu;
- ngalaksanakeun hubungan antara Request jeung Wates pikeun sumberdaya di namespace;
- Nyetél Paménta / Watesan standar pikeun ngitung sumber daya dina rohangan ngaran sareng sacara otomatis nyuntikkeun kana wadah nalika waktosna.
Ku cara ieu Anjeun bisa nyieun rentang wates dina namespace Anjeun. Teu kawas kuota, nu manglaku ka sakabéh spasi ngaran, Wates Range dipaké pikeun wadah individu. Ieu tiasa nyegah pangguna nyiptakeun wadah anu alit pisan atanapi, sabalikna, wadah ageung dina rohangan ngaran. The Limit Range bisa kasampak kawas kieu.
Sapertos dina kasus saméméhna, 4 bagian tiasa dibédakeun di dieu. Hayu urang tingali masing-masing.
Bagian standar netepkeun wates standar pikeun wadahna dina pod. Upami anjeun netepkeun nilai-nilai ieu kana kisaran ekstrim, maka wadah anu mana nilai-nilai ieu teu acan diatur sacara eksplisit bakal nuturkeun nilai standar.
Bagian pamundut standar defaultRequest ngonpigurasikeun pamundut standar pikeun wadahna dina pod. Sakali deui, upami anjeun netepkeun nilai-nilai ieu kana kisaran ekstrim, maka wadah naon waé anu henteu sacara eksplisit nyetél pilihan ieu bakal ditunakeun kana nilai-nilai ieu.
Bagian max nangtukeun wates maksimum nu bisa diatur pikeun wadahna di pod nu. Nilai dina bagian standar sareng wates wadahna teu tiasa disetél di luhur wates ieu. Penting pikeun dicatet yén upami nilaina disetel ka max sareng teu aya bagian standar, maka nilai maksimal janten nilai standar.
Bagian mnt nangtukeun requests minimum nu bisa diatur pikeun wadahna di pod a. Nanging, nilai-nilai dina bagian standar sareng patarosan pikeun wadahna teu tiasa disetél di handap wates ieu.
Sakali deui, penting pikeun dicatet yén upami nilai ieu disetel, standar henteu, maka nilai minimum janten ajakan standar.
Paménta sumber daya ieu pamustunganana dianggo ku panjadwal Kubernetes pikeun ngaéksekusi beban kerja anjeun. Supados anjeun tiasa ngonpigurasikeun wadah anjeun leres, penting pisan pikeun ngartos kumaha jalanna. Anggap anjeun hoyong ngajalankeun sababaraha pods dina kluster anjeun. Anggap spésifikasi pod sah, jadwal Kubernetes bakal ngagunakeun round robin balancing pikeun milih titik pikeun ngajalankeun beban kerja.
Kubernetes bakal pariksa naha Node 1 gaduh sumber anu cekap pikeun nyumponan paménta ti wadah pod, sareng upami henteu, éta bakal ngalih ka node salajengna. Upami teu aya titik dina sistem anu tiasa nyugemakeun pamundut, polong bakal lebet kana kaayaan Pending. Nganggo fitur mesin Google Kubernetes sapertos skala otomatis titik, GKE tiasa otomatis ngadeteksi kaayaan ngantosan sareng nyiptakeun sababaraha titik tambahan.
Upami anjeun teras-terasan kaluar tina kapasitas node, autoscaling bakal ngirangan jumlah node pikeun ngahémat artos anjeun. Ieu sababna Kubernetes ngajadwalkeun pods dumasar kana pamundut. Sanajan kitu, watesna bisa jadi leuwih luhur ti requests, sarta dina sababaraha kasus titik bisa sabenerna kehabisan sumberdaya. Urang nelepon kaayaan overcommitment kaayaan ieu.
Salaku Cenah mah, lamun datang ka CPU, Kubernetes bakal ngamimitian ngawatesan pods. Unggal pod bakal nampi saloba anu dipénta, tapi upami henteu dugi ka watesna, throttling bakal mimiti diterapkeun.
Lamun datang ka sumber memori, Kubernetes kapaksa nyieun kaputusan ngeunaan nu pods dihapus sarta mana nu kudu tetep nepi ka anjeun ngosongkeun sumberdaya sistem atawa sakabéh sistem bakal ngadat.
Hayu urang bayangkeun skenario dimana anjeun gaduh mesin anu kaluar tina mémori - kumaha Kubernetes bakal nanganan éta?
Kubernetes bakal milarian pods anu ngagunakeun langkung seueur sumber tibatan anu dipénta. Janten upami wadahna anjeun henteu ngagaduhan Paménta, éta hartosna aranjeunna henteu nganggo langkung seueur tibatan anu dipénta, ngan kusabab aranjeunna henteu naroskeun nanaon! Wadah sapertos kitu janten calon perdana pikeun ditutup. Calon anu salajengna nyaéta wadah anu parantos nyugemakeun sadaya pamenta na tapi masih di handapeun wates maksimal.
Ku kituna lamun Kubernetes manggihan sababaraha pods nu geus ngaleuwihan parameter pamundut maranéhanana, éta bakal nyortir aranjeunna dumasar prioritas lajeng miceun pods prioritas panghandapna. Upami sadaya pod ngagaduhan prioritas anu sami, maka Kubernetes bakal ngeureunkeun pods anu parantos langkung seueur pamundutna tibatan pods anu sanés.
Dina kasus anu jarang pisan, Kubernetes tiasa ngabatalkeun pod anu masih aya dina lingkup pamundutana. Ieu tiasa kajantenan nalika komponén sistem kritis sapertos agén Kubelet atanapi Docker ngawitan nganggo langkung seueur sumber daya tibatan anu ditangtayungan pikeun aranjeunna.
Janten, dina tahap awal perusahaan-perusahaan alit, klaster Kubernetes tiasa jalanna saé tanpa netepkeun paménta sumber daya sareng larangan, tapi nalika tim sareng proyék anjeun mimiti ningkat ukuranana, anjeun résiko ngalaman masalah di daérah ieu. Nambahkeun queries sarta konstrain kana modul anjeun sarta namespaces merlukeun pisan saeutik usaha tambahan sarta bisa ngahemat loba repot.
Sababaraha iklan 🙂
Hatur nuhun pikeun tetep sareng kami. Naha anjeun resep artikel kami? Hoyong ningali eusi anu langkung narik? Dukung kami ku cara nempatkeun pesenan atanapi nyarankeun ka babaturan, , analog unik tina server tingkat éntri, anu diciptakeun ku kami pikeun anjeun: (sadia kalawan RAID1 na RAID10, nepi ka 24 cores sarta nepi ka 40GB DDR4).
Dell R730xd 2 kali langkung mirah dina puseur data Equinix nagara golongan IV di Amsterdam? Ngan di dieu di Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ti $99! Baca ngeunaan
sumber: www.habr.com