Watesan CPU lan throttling agresif ing Kubernetes

Cathetan. nerjemahake.: Sejarah Omio sing mbukak mripat iki - aggregator perjalanan Eropa - njupuk pembaca saka teori dhasar menyang seluk-beluk praktis konfigurasi Kubernetes sing nggumunake. Keahlian karo kasus kaya ngono ora mung mbantu nggedhekake wawasan, nanging uga nyegah masalah sing ora pati penting.

Apa sampeyan wis nate aplikasi macet, mandheg nanggapi pemeriksaan kesehatan, lan ora ngerti sebabe? Siji panjelasan bisa uga ana hubungane karo watesan kuota sumber daya CPU. Iki sing bakal kita bahas ing artikel iki.

TL; DR:
Disaranake mateni watesan CPU ing Kubernetes (utawa mateni kuota CFS ing Kubelet) yen sampeyan nggunakake versi kernel Linux kanthi bug kuota CFS. Ing inti kasedhiya serius lan kondhang bug sing ndadékaké kanggo throttling gedhe banget lan telat.

Ing Omio kabeh infrastruktur dikelola dening Kubernetes. Kabeh beban kerja stateful lan stateless kita mlaku sacara eksklusif ing Kubernetes (kita nggunakake Google Kubernetes Engine). Ing nem sasi pungkasan, kita wiwit mirsani slowdowns acak. Aplikasi beku utawa mandheg nanggapi pemeriksaan kesehatan, kelangan sambungan menyang jaringan, lsp. Prilaku iki mbingungake kita nganti suwe, lan pungkasane kita mutusake kanggo njupuk masalah kasebut kanthi serius.

Ringkesan artikel:

• Sawetara tembung babagan wadhah lan Kubernetes;
• Carane panjalukan lan watesan CPU dileksanakake;
• Cara kerja watesan CPU ing lingkungan multi-inti;
• Carane trek throttling CPU;
• Solusi masalah lan nuansa.

Sawetara tembung babagan kontaner lan Kubernetes

Kubernetes minangka standar modern ing jagad infrastruktur. Tugas utamane yaiku orkestrasi wadah.

Wadhah

Ing jaman biyen, kita kudu nggawe artefak kaya Java JARs/WARs, Python Eggs, utawa executables kanggo mbukak ing server. Nanging, kanggo nggawe fungsi kasebut, karya tambahan kudu ditindakake: nginstal lingkungan runtime (Jawa/Python), nempatake file sing dibutuhake ing papan sing bener, njamin kompatibilitas karo versi sistem operasi tartamtu, lsp. Ing tembung liyane, perhatian sing ati-ati kudu dibayar kanggo manajemen konfigurasi (sing asring dadi sumber konflik antarane pangembang lan administrator sistem).

Kontainer ngganti kabeh. Saiki artefak kasebut minangka gambar wadhah. Bisa diwakili minangka jinis file eksekusi lengkap sing ora mung ngemot program, nanging uga lingkungan eksekusi lengkap (Java/Python/...), uga file/paket sing dibutuhake, wis diinstal lan siap digunakake. mlayu. Wadhah bisa disebarake lan mbukak ing server sing beda-beda tanpa langkah tambahan.

Kajaba iku, kontaner beroperasi ing lingkungan kothak wedhi dhewe. Dheweke duwe adaptor jaringan virtual dhewe, sistem file dhewe kanthi akses winates, hirarki pangolahan dhewe, watesan dhewe ing CPU lan memori, lan liya-liyane.

Kubernetes

Kaya sing wis dingerteni sadurunge, Kubernetes minangka orkestra kontainer. Kerjane kaya iki: sampeyan menehi blumbang mesin, lan banjur ngandika: "Hei, Kubernetes, ayo miwiti sepuluh kedadean saka kontaner karo 2 prosesor lan 3 GB memori saben, lan supaya padha mlaku!" Kubernetes bakal ngurus liyane. Bakal nemokake kapasitas gratis, miwiti wadhah lan miwiti maneh yen perlu, gulung nganyari nalika ngganti versi, lsp. Intine, Kubernetes ngidini sampeyan ngilangi komponen hardware lan nggawe macem-macem sistem sing cocog kanggo nyebarake lan mbukak aplikasi.

Kubernetes saka titik tampilan saka wong awam

Apa panjalukan lan watesan ing Kubernetes

Oke, kita wis nutupi wadhah lan Kubernetes. Kita uga ngerti manawa sawetara kontaner bisa manggon ing mesin sing padha.

Analogi bisa digambar karo apartemen komunal. Panggonan sing wiyar (mesin / unit) dijupuk lan disewakake menyang sawetara penyewa (kontainer). Kubernetes tumindak minangka makelar. Pitakonan muncul, kepiye carane nyewokake konflik karo saben liyane? Apa yen salah siji saka wong-wong mau, ngomong, arep nyilih jedhing kanggo setengah dina?

Iki ngendi panjalukan lan watesan teka menyang muter. CPU request dibutuhake mung kanggo tujuan perencanaan. Iki kaya "dhaftar kepinginan" wadhah, lan digunakake kanggo milih simpul sing paling cocok. Ing wektu sing padha CPU limit bisa dibandhingake karo persetujuan rental - sanalika kita pilih unit kanggo wadhah, ing ora bisa ngluwihi wates sing wis ditemtokake. Lan ing kene masalah muncul ...

Carane panjalukan lan watesan dileksanakake ing Kubernetes

Kubernetes nggunakake mekanisme throttling (siklus jam skipping) dibangun ing kernel kanggo ngleksanakake watesan CPU. Yen aplikasi ngluwihi watesan, throttling diaktifake (yaiku nampa siklus CPU luwih sithik). Panjaluk lan watesan kanggo memori diatur kanthi cara sing beda, supaya luwih gampang dideteksi. Kanggo nindakake iki, mung mriksa status restart pungkasan pod: apa iku "OOMKilled". CPU throttling ora supaya prasaja, wiwit K8s mung nggawe metrik kasedhiya dening panggunaan, ora dening cgroups.

Panjaluk CPU

Carane request CPU dipun ginakaken

Kanggo gamblang, ayo kang katon ing proses nggunakake mesin karo CPU 4-inti minangka conto.

K8s nggunakake mekanisme klompok kontrol (cgroups) kanggo kontrol alokasi sumber daya (memori lan prosesor). Model hirarkis kasedhiya kanggo: bocah kasebut entuk watesan saka klompok induk. Rincian distribusi disimpen ing sistem file virtual (/sys/fs/cgroup). Ing kasus prosesor iki /sys/fs/cgroup/cpu,cpuacct/*.

K8s nggunakake file cpu.share kanggo nyedhiyakake sumber daya prosesor. Ing kasus kita, cgroup ROOT entuk 4096 saham sumber daya CPU - 100% saka daya prosesor sing kasedhiya (1 inti = 1024; iki minangka nilai tetep). Klompok oyot nyebarake sumber daya kanthi proporsional gumantung saka saham keturunan sing didaftar cpu.share, lan padha, ing siji, padha nindakake karo turunane, etc. Ing simpul Kubernetes sing khas, cgroup root duwe telung anak: system.slice, user.slice и kubepods. Rong subgrup pisanan digunakake kanggo nyebarake sumber daya ing antarane beban sistem kritis lan program pangguna ing njaba K8. Pungkasan - kubepods - digawe dening Kubernetes kanggo nyebarake sumber daya antarane pods.

Diagram ing ndhuwur nuduhake yen subgrup pisanan lan kaloro nampa saben 1024 saham, karo subgrup kuberpod dialokasikan 4096 enggo bareng Kepiye carane bisa: sawise kabeh, grup root mung duwe akses 4096 saham, lan jumlah saham saka turunane dheweke ngluwihi jumlah kasebut (6144)? Intine yaiku nilai kasebut nggawe akal logis, mula panjadwal Linux (CFS) digunakake kanggo ngalokasi sumber daya CPU kanthi proporsional. Ing kasus kita, rong klompok pisanan nampa 680 Enggo bareng nyata (16,6% saka 4096), lan kubepod nampa isih 2736 enggo bareng Ing kasus downtime, rong klompok pisanan ora bakal nggunakake sumber daya sing diparengake.

Untunge, panjadwal duwe mekanisme supaya ora mbuwang sumber daya CPU sing ora digunakake. Nransfer kapasitas "meneng" menyang blumbang global, saka kang mbagekke kanggo kelompok sing perlu daya prosesor tambahan (transfer ana ing kumpulan supaya losses babak). Cara sing padha ditrapake kanggo kabeh turunane.

Mekanisme iki njamin distribusi daya prosesor sing adil lan njamin ora ana sing ngolah "nyolong" sumber daya saka wong liya.

Limit CPU

Senadyan kasunyatan manawa konfigurasi watesan lan panjalukan ing K8 katon padha, implementasine beda banget: iki paling mblusukake lan bagean sing paling ora didokumentasikake.

K8s melu mekanisme kuota CFS kanggo ngleksanakake watesan. Setelan kasebut ditemtokake ing file cfs_period_us и cfs_quota_us ing direktori cgroup (file kasebut uga ana ing kana cpu.share).

Boten kados cpu.share, kuota adhedhasar jangka wektu, lan ora ing daya prosesor kasedhiya. cfs_period_us nemtokake durasi periode (jaman) - iku tansah 100000 μs (100 ms). Ana pilihan kanggo ngganti nilai iki ing K8s, nanging mung kasedhiya ing alpha kanggo saiki. Penjadwal nggunakake jaman kanggo miwiti maneh kuota sing digunakake. Berkas kapindho cfs_quota_us, nemtokake wektu kasedhiya (kuota) ing saben jaman. Elinga yen uga kasebut ing microseconds. Kuota bisa ngluwihi dawa jaman; ing tembung liyane, iku uga luwih saka 100 ms.

Ayo ndeleng rong skenario ing mesin 16-inti (jinis komputer sing paling umum ing Omio):

Skenario 1: 2 utas lan watesan 200 ms. Ora ana throttling

Skenario 2: 10 utas lan watesan 200 ms. Throttling diwiwiti sawise 20 ms, akses menyang sumber daya prosesor diterusake sawise 80 ms liyane

Ayo dadi ngomong sampeyan nyetel watesan CPU kanggo 2 kernels; Kubernetes bakal nerjemahake nilai iki dadi 200 ms. Iki tegese wadhah bisa nggunakake maksimal 200ms wektu CPU tanpa throttling.

Lan iki ngendi fun wiwit. Kaya kasebut ing ndhuwur, kuota sing kasedhiya yaiku 200 ms. Yen sampeyan nggarap paralel sepuluh Utas ing mesin 12-inti (ndeleng ilustrasi kanggo skenario 2), nalika kabeh pod liyane ora aktif, kuota bakal kesel mung 20 ms (wiwit 10 * 20 ms = 200 ms), lan kabeh utas pod iki bakal macet. » (katup) kanggo 80 ms sabanjuré. Sing wis kasebut bug panjadwal, amarga throttling gedhe banget lan wadhah kasebut ora bisa ngrampungake kuota sing ana.

Kepiye cara ngevaluasi throttling ing pods?

Cukup mlebu menyang pod lan eksekusi cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - jumlah total wektu panjadwal;
• nr_throttled - jumlah wektu throttled ing komposisi nr_periods;
• throttled_time - wektu throttled kumulatif ing nanodetik.

Ana apa tenan?

Akibaté, kita entuk throttling dhuwur ing kabeh aplikasi. Kadhangkala dheweke mlebu siji lan setengah kaping kuwat saka diwilang!

Iki nyebabake macem-macem kesalahan - gagal mriksa kesiapan, kontainer beku, sambungan jaringan putus, wektu entek ing telpon layanan. Iki pungkasane nyebabake tambah latensi lan tingkat kesalahan sing luwih dhuwur.

Keputusan lan akibat

Kabeh iku prasaja ing kene. Kita nilar watesan CPU lan miwiti nganyari kernel OS ing kluster menyang versi paling anyar, ing ngendi bug kasebut didandani. Jumlah kesalahan (HTTP 5xx) ing layanan kita langsung mudhun banget:

kesalahan HTTP 5xx

Kesalahan HTTP 5xx kanggo siji layanan kritis

Wektu nanggepi p95

Latensi panjalukan layanan kritis, persentil kaping 95

Biaya operasi

Jumlah jam Kayata ngginakaken

Apa sing diarani?

Kaya sing kasebut ing wiwitan artikel:

Analogi bisa digambar karo apartemen komunal ... Kubernetes tumindak minangka makelar. Nanging kepiye carane njaga penyewa saka konflik karo saben liyane? Apa yen salah siji saka wong-wong mau, ngomong, arep nyilih jedhing kanggo setengah dina?

Punika nyekel. Siji wadhah ceroboh bisa mangan kabeh sumber daya CPU sing kasedhiya ing mesin. Yen sampeyan duwe tumpukan aplikasi sing cerdas (contone, JVM, Go, Node VM wis dikonfigurasi kanthi bener), mula iki ora dadi masalah: sampeyan bisa kerja ing kahanan kaya ngono kanggo wektu sing suwe. Nanging yen aplikasi kurang dioptimalake utawa ora dioptimalake kabeh (FROM java:latest), kahanan bisa metu saka kontrol. Ing Omio, kita duwe Dockerfiles basis otomatis kanthi setelan gawan sing nyukupi kanggo tumpukan basa utama, mula masalah iki ora ana.

Disaranake ngawasi metrik Panganggone (panggunaan, jenuh lan kesalahan), telat API lan tingkat kesalahan. Priksa manawa asil cocog karo pangarepan.

referensi

Iki crita kita. Materi ing ngisor iki mbantu banget kanggo ngerti apa sing kedadeyan:

• kernel.org → Penjadwal CFS;
• kernel.org → Kontrol Bandwidth CFS;
• Ngerteni Linux Container Scheduling;
• Kabeh Sampeyan Perlu Ngerti babagan Kontainer Linux, Part I: Grup Kontrol Linux lan Isolasi Proses;
• Kisah Gagal Kubernetes - goleki "cpu throttling".

Laporan bug Kubernetes:

• # 51135: Aja nyetel watesan CPU kanggo Dijamin pods;
• #67577: Kuota CFS bisa nyebabake throttling sing ora perlu;
• CFS sing agresif banget.

Apa sampeyan nemoni masalah sing padha ing praktik sampeyan utawa duwe pengalaman sing ana gandhengane karo throttling ing lingkungan produksi kontainer? Nuduhake crita sampeyan ing komentar!

PS saka penerjemah

Waca uga ing blog kita:

• «Autoscaling lan manajemen sumber daya ing Kubernetes (review lan laporan video)";
• «Carane CPU Manager dianggo ing Kubernetes";
• «Apa sing kedadeyan ing Kubernetes nalika sampeyan mbukak kubectl run? Bagean 2".

Source: www.habr.com