Catetan. narjamahkeun.: Ieu sajarah muka panon Omio-a agrégator perjalanan Éropa-nyokot pamiarsa ti téori dasar nepi ka intricacies praktis matak tina konfigurasi Kubernetes. Familiarity jeung kasus sapertos mantuan teu ukur ngalegaan horizons anjeun, tapi ogé nyegah masalah non-trivial.
Naha anjeun kantos ngagaduhan aplikasi macét, lirén ngaréspon kana pamariksaan kaséhatan, sareng henteu tiasa terang kunaon? Hiji katerangan mungkin patali jeung wates kuota sumberdaya CPU. Ieu naon urang bakal ngobrol ngeunaan dina artikel ieu.
TL; DR:
Kami nyarankeun pisan nganonaktipkeun wates CPU di Kubernetes (atanapi nganonaktipkeun kuota CFS di Kubelet) upami anjeun nganggo versi kernel Linux anu gaduh bug kuota CFS. Dina inti serius jeung bug anu ngakibatkeun throttling kaleuleuwihan sarta reureuh.
Di Omio sakabéh infrastruktur dikokolakeun ku Kubernetes. Sadaya beban kerja stateful sareng stateless kami dijalankeun sacara éksklusif dina Kubernetes (kami nganggo Google Kubernetes Engine). Dina genep bulan panungtungan, urang mimiti niténan slowdowns acak. Aplikasi ngabekukeun atanapi ngeureunkeun ngaréspon kana pamariksaan kaséhatan, kaleungitan sambungan kana jaringan, jsb. Paripolah ieu ngabingungkeun kami kanggo waktos anu lami, sareng tungtungna urang mutuskeun pikeun nyandak masalahna sacara serius.
Ringkesan tulisan:
- Sababaraha kecap ngeunaan peti jeung Kubernetes;
- Kumaha CPU requests sarta wates anu dilaksanakeun;
- Kumaha wates CPU dianggo dina lingkungan multi-inti;
- Kumaha ngalacak CPU throttling;
- Solusi masalah sareng nuansa.
Sababaraha kecap ngeunaan peti jeung Kubernetes
Kubernetes dasarna mangrupikeun standar modéren dina dunya infrastruktur. Tugas utami nyaéta orkestrasi wadah.
Wadahna
Baheula, urang kedah nyiptakeun artefak sapertos Java JARs/WARs, Python Eggs, atanapi executables pikeun dijalankeun dina server. Nanging, pikeun ngajantenkeun fungsina, padamelan tambahan kedah dilakukeun: masang lingkungan runtime (Java/Python), nempatkeun file anu diperyogikeun dina tempat anu leres, mastikeun kasaluyuan sareng versi sistem operasi khusus, jsb. Dina basa sejen, perhatian ati kudu dibayar ka manajemén konfigurasi (anu mindeng sumber contention antara pamekar jeung administrator sistem).
Wadah robah sagalana. Ayeuna artefak mangrupa gambar wadahna. Éta tiasa diwakilan salaku jinis file éksekusi anu diperpanjang anu ngandung henteu ngan ukur program, tapi ogé lingkungan palaksanaan anu lengkep (Java/Python/...), kitu ogé file/pakét anu diperyogikeun, tos dipasang sareng siap dianggo. lumpat. Wadahna tiasa disebarkeun sareng dijalankeun dina server anu béda tanpa aya léngkah tambahan.
Sajaba ti éta, peti beroperasi di lingkungan sandbox sorangan. Aranjeunna mibanda adaptor jaringan maya sorangan, sistem file sorangan kalawan aksés kawates, hirarki sorangan prosés, watesan sorangan dina CPU jeung memori, jsb Sadaya ieu dilaksanakeun berkat subsistem husus tina kernel Linux Ubuntu - namespaces.
Kubernetes
Sakumaha anu dinyatakeun sateuacana, Kubernetes mangrupikeun orkestra wadah. Gawéna sapertos kieu: anjeun masihan éta kolam renang mesin, teras nyarios: "Héy, Kubernetes, hayu urang ngaluncurkeun sapuluh conto wadah kuring kalayan 2 prosesor sareng 3 memori GB masing-masing, sareng tetep ngajalankeun!" Kubernetes bakal ngurus sésana. Éta bakal mendakan kapasitas gratis, ngaluncurkeun wadah sareng balikan deui upami diperyogikeun, gulungkeun pembaruan nalika ngarobih versi, jsb. Intina, Kubernetes ngamungkinkeun anjeun ngaleungitkeun komponén hardware sareng ngadamel rupa-rupa sistem anu cocog pikeun nyebarkeun sareng ngajalankeun aplikasi.
Kubernetes tina sudut pandang awam
Naon requests sarta wates dina Kubernetes
Oke, kami parantos nutupan wadah sareng Kubernetes. Urang ogé terang yén sababaraha peti tiasa cicing dina mesin anu sami.
Analogi tiasa digambar sareng apartemen komunal. Tempat anu lega (mesin/unit) dicandak sareng disewakeun ka sababaraha panyewa (wadah). Kubernetes tindakan minangka realtor a. Timbul patarosan, kumaha carana ngajaga panyewa tina konflik saling? Kumaha upami salah sahijina, sebutkeun, mutuskeun nginjeum kamar mandi satengah dinten?
Ieu dimana requests sarta wates datangna kana antrian. CPU nyuhunkeun diperlukeun solely pikeun tujuan perencanaan. Ieu mangrupikeun "daftar hajat" wadahna, sareng dianggo pikeun milih titik anu paling cocog. Dina waktu nu sarua CPU wates bisa dibandingkeun jeung perjangjian rental - pas urang milih Unit pikeun wadahna, éta teu tiasa balik saluareun wates ngadegkeun. Sareng ieu dimana masalahna timbul ...
Kumaha pamundut sareng wates dilaksanakeun dina Kubernetes
Kubernetes ngagunakeun mékanisme throttling (skipping clock cycles) diwangun kana kernel pikeun nerapkeun wates CPU. Upami aplikasi ngaleuwihan wates, throttling diaktipkeun (nyaéta nampi langkung sakedik siklus CPU). Requests sarta wates pikeun memori diatur béda, ngarah leuwih gampang pikeun ngadeteksi. Jang ngalampahkeun ieu, ngan pariksa status balikan deui panungtungan tina pod: naha éta téh "OOMKilled". CPU throttling teu jadi basajan, saprak K8s ukur ngajadikeun metrics sadia ku pamakéan, teu ku cgroups.
CPU Request
Kumaha pamundut CPU dilaksanakeun
Pikeun kesederhanaan, hayu urang tingali prosés ngagunakeun mesin kalayan CPU 4-inti sabagé conto.
K8s ngagunakeun mékanisme grup kontrol (cgroups) pikeun ngadalikeun alokasi sumberdaya (memori jeung processor). Aya model hirarkis pikeun eta: anak inherits wates grup indungna. Rincian distribusi disimpen dina sistem file virtual (/sys/fs/cgroup). Dina kasus prosesor ieu /sys/fs/cgroup/cpu,cpuacct/*.
K8s ngagunakeun file cpu.share pikeun allocate sumberdaya processor. Dina kasus urang, cgroup akar meunang 4096 biasa sumberdaya CPU - 100% tina kakuatan processor sadia (1 inti = 1024; ieu mangrupa nilai tetep). Grup akar ngadistribusikaeun sumberdaya sacara proporsional gumantung kana pangsa turunan anu kadaptar cpu.share, sarta aranjeunna, kahareupna ngalakukeun hal nu sarua jeung turunan maranéhanana, jsb. Dina titik Kubernetes has, cgroup akar boga tilu anak: system.slice, user.slice и kubepods. Dua subgrup munggaran dianggo pikeun ngadistribusikaeun sumber daya antara beban sistem kritis sareng program pangguna di luar K8. Panungtung - kubepods - dijieun ku Kubernetes pikeun ngadistribusikaeun sumberdaya antara pods.
Diagram di luhur nunjukkeun yén subgrup kahiji sareng kadua nampi masing-masing 1024 saham, sareng subgrup kuberpod dialokasikeun 4096 dibagikeun Kumaha ieu mungkin: sanggeus kabeh, grup root boga aksés ka wungkul 4096 saham, sareng jumlah saham turunanna sacara signifikan ngaleuwihan jumlah ieu (6144)? Intina nyaéta nilaina asup akal logis, ku kituna penjadwal Linux (CFS) ngagunakeunana pikeun alokasi sumber daya CPU sacara proporsional. Dina kasus urang, dua grup munggaran nampi 680 biasa nyata (16,6% ti 4096), sarta kubepod narima sésana 2736 dibagikeun Dina hal downtime, dua grup kahiji moal ngagunakeun sumberdaya disadiakeun.
Untungna, scheduler ngabogaan mékanisme pikeun nyegah wasting sumberdaya CPU henteu kapake. Mindahkeun kapasitas "dianggurkeun" ka kolam renang global, ti mana eta disebarkeun ka grup nu peryogi kakuatan processor tambahan (mindahkeun lumangsung dina bets ulah rounding karugian). Métode anu sami diterapkeun ka sadaya turunan turunan.
Mékanisme ieu ngajamin distribusi kakuatan prosésor anu adil sareng mastikeun yén teu aya anu ngolah "nyolong" sumberdaya ti batur.
wates CPU
Najan kanyataan yén konfigurasi tina wates jeung requests dina K8s kasampak sarupa, palaksanaan maranéhanana sacara radikal béda: ieu paling nyasabkeun jeung bagian sahenteuna documented.
K8s engages pikeun nerapkeun wates. Setélan maranéhanana dieusian dina file cfs_period_us и cfs_quota_us dina diréktori cgroup (filena ogé aya di dinya cpu.share).
Teu kawas cpu.share, kuota dumasar kana periode waktu, sarta henteu dina kakuatan processor sadia. cfs_period_us nangtukeun lilana periode (epoch) - éta salawasna 100000 μs (100 mdet). Aya pilihan pikeun ngarobah nilai ieu dina K8s, tapi ngan sadia dina alfa pikeun ayeuna. Penjadwal ngagunakeun epoch pikeun ngabalikan deui kuota anu dianggo. Berkas kadua cfs_quota_us, nangtukeun waktu sadia (kuota) dina unggal epoch. Catet yén éta ogé dieusian dina microseconds. Kuota bisa ngaleuwihan panjang epoch; dina basa sejen, bisa jadi leuwih gede ti 100 mdet.
Hayu urang tingali dua skénario dina mesin 16-inti (tipe komputer anu paling umum di Omio):
Skenario 1: 2 benang sareng wates 200 mdet. Taya throttling
Skenario 2: 10 benang sareng wates 200 mdet. Throttling dimimitian saatos 20 mdet, aksés ka sumber daya prosesor diteruskeun saatos 80 mdet
Hayu urang nyebutkeun anjeun nyetel wates CPU ka 2 kernels; Kubernetes bakal narjamahkeun nilai ieu ka 200 mdet. Ieu ngandung harti yén wadahna tiasa nganggo maksimal 200ms waktos CPU tanpa throttling.
Sareng ieu dimana kasenangan dimimitian. Sakumaha didadarkeun di luhur, kuota anu sayogi nyaéta 200 ms. Upami anjeun damel paralel sapuluh benang dina mesin 12-inti (tingali ilustrasi pikeun skenario 2), bari sakabeh pods séjén dianggurkeun, kuota bakal béak dina ngan 20 ms (saprak 10 * 20 ms = 200 ms), sarta sakabeh thread pod ieu bakal ngagantung. » (throttle) pikeun 80 ms salajengna. Nu geus disebutkeun , alatan throttling kaleuleuwihan lumangsung sarta wadahna malah teu bisa minuhan kuota aya.
Kumaha meunteun throttling dina pods?
Ngan login ka pod jeung laksana cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- jumlah total période scheduler; -
nr_throttled- Jumlah période throttled dina komposisinr_periods; -
throttled_time- waktos throttled kumulatif dina nanoseconds.
Aya naon sih?
Hasilna, urang nampi throttling tinggi dina sadaya aplikasi. Sakapeung manéhna asup hiji satengah kali kuat ti diitung!
Ieu ngakibatkeun rupa-rupa kasalahan - gagal pariksa kesiapan, freezes wadahna, sambungan jaringan putus, timeouts dina panggero jasa. Ieu pamustunganana nyababkeun paningkatan latency sareng tingkat kasalahan anu langkung luhur.
Kaputusan sareng akibat
Sagalana basajan di dieu. Kami ngantunkeun wates CPU sareng ngamimitian ngamutahirkeun kernel OS dina klaster kana vérsi pangénggalna, dimana bug na dibenerkeun. Jumlah kasalahan (HTTP 5xx) dina jasa kami langsung turun sacara signifikan:
Kasalahan HTTP 5xx
Kasalahan HTTP 5xx pikeun hiji layanan kritis
waktos respon p95
Latensi paménta jasa kritis, persentil ka-95
waragad operasi
Jumlah instance jam spent
Naon ari nyekel?
Sakumaha anu dinyatakeun dina awal tulisan:
Analogi tiasa digambar sareng apartemen komunal ... Kubernetes tindakan minangka realtor. Tapi kumaha carana ngajaga panyewa tina konflik saling? Kumaha upami salah sahijina, sebutkeun, mutuskeun nginjeum kamar mandi satengah dinten?
Di dieu nu nyekel. Hiji wadah teu ati-ati tiasa ngahakan sadaya sumber daya CPU anu aya dina mesin. Upami anjeun gaduh tumpukan aplikasi pinter (contona, JVM, Go, Node VM dikonpigurasi leres), maka ieu sanés masalah: anjeun tiasa damel dina kaayaan sapertos kitu kanggo waktos anu lami. Tapi upami aplikasi kirang dioptimalkeun atanapi henteu dioptimalkeun pisan (FROM java:latest), kaayaan bisa jadi kaluar kontrol. Di Omio kami gaduh Dockerfiles dasar otomatis sareng setélan standar anu nyukupan pikeun tumpukan basa utama, janten masalah ieu henteu aya.
Kami nyarankeun ngawaskeun métrik (pamakéan, jenuh jeung kasalahan), API reureuh jeung ongkos kasalahan. Pastikeun yén hasil minuhan ekspektasi.
rujukan
Ieu carita urang. Bahan-bahan di handap ieu parantos ngabantosan ngartos naon anu lumangsung:
- ;
- ;
- ;
- ;
- - milarian "cpu throttling".
Laporan bug Kubernetes:
- ;
- ;
- .
Naha anjeun ngalaman masalah anu sami dina prakték anjeun atanapi gaduh pangalaman anu aya hubunganana sareng throttling dina lingkungan produksi wadahna? Bagikeun carita anjeun dina koméntar!
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «".
sumber: www.habr.com