Mbalik ing 2016 kita ing Buffer , lan saiki udakara 60 simpul (ing AWS) lan 1500 kontainer nggarap kluster k8s sing dikelola dening . Nanging, kita pindhah menyang microservices liwat nyoba lan kesalahan, lan malah sawise sawetara taun nggarap k8s kita isih ngadhepi karo masalah anyar. Ing kirim iki kita bakal ngomong babagan watesan prosesor: kok kita panginten padha laku apik lan apa padha pungkasanipun ora dadi apik.
watesan prosesor lan throttling
Kaya akeh pangguna Kubernetes liyane, . Tanpa setelan kasebut, wadhah ing simpul bisa njupuk kabeh daya prosesor, sing nyebabake proses penting Kubernetes (contone kubelet) bakal mandheg nanggapi panjaluk. Dadi, nyetel watesan CPU minangka cara sing apik kanggo nglindhungi simpul sampeyan.
Watesan prosesor nyetel wadhah kanggo wektu CPU maksimum bisa digunakake kanggo periode tartamtu (standar punika 100ms), lan wadhah ora bakal ngluwihi watesan iki. Ing Kubernetes kanggo throttling wadhah lan nyegah saka ngluwihi watesan, alat khusus digunakake , nanging watesan CPU gawean iki bakal nyebabake kinerja lan nambah wektu nanggepi wadhah sampeyan.
Apa bisa kedadeyan yen kita ora nyetel watesan prosesor?
Sayange, awake dhewe kudu ngadhepi masalah iki. Saben simpul duwe proses sing tanggung jawab kanggo ngatur wadhah kubelet, lan dheweke mandheg nanggapi panjaluk. Node, nalika kedadeyan kasebut, bakal mlebu negara NotReady, lan kontaner bakal dialihake menyang papan liya lan nggawe masalah sing padha ing simpul anyar. Ora skenario becik, ngomong paling.
Manifestasi masalah throttling lan respon
Metrik kunci kanggo nelusuri wadhah yaiku trottling, nuduhake kaping pirang-pirang wadhah sampeyan wis dicemplungake. We ngeweruhi karo kapentingan ing ngarsane throttling ing sawetara kontaner, preduli saka apa mbukak prosesor nemen utawa ora. Minangka conto, ayo deleng salah sawijining API utama:
Nalika sampeyan bisa ndeleng ing ngisor iki, kita wis nyetel watesan kanggo 800m (0.8 utawa 80% inti), lan nilai puncak paling apik 200m (20% inti). Katon yen sadurunge nyepetake layanan, kita isih duwe daya prosesor, nanging ...
Sampeyan bisa uga wis ngelingi yen sanajan beban prosesor ing ngisor watesan sing ditemtokake - sacara signifikan ing ngisor iki - throttling isih ana.
Ngadhepi iki, kita langsung nemokake sawetara sumber daya (, , ) babagan penurunan kinerja lan wektu nanggepi layanan amarga throttling.
Napa kita ndeleng throttling ing beban CPU sing sithik? Versi cendhak yaiku: "ana bug ing kernel Linux sing nyebabake throttling sing ora perlu karo watesan prosesor sing ditemtokake." Yen sampeyan kasengsem ing sifat masalah, sampeyan bisa maca presentasi ( и opsi) dening Dave Chiluk.
Mbusak watesan CPU (kanthi ati-ati banget)
Sawise diskusi dawa, kita mutusake kanggo mbusak watesan prosesor saka kabeh layanan sing langsung utawa ora langsung mengaruhi fungsi kritis kanggo pangguna.
Kaputusan kasebut ora gampang amarga kita ngormati stabilitas kluster kita. Ing jaman biyen, kita wis nyoba ora stabil kluster kita, banjur layanan kasebut nggunakake sumber daya sing akeh banget lan nyuda karya kabeh simpul. Saiki kabeh wis rada beda: kita duwe pangerten sing jelas babagan apa sing dikarepake saka klompok, uga strategi sing apik kanggo ngetrapake owah-owahan sing direncanakake.
Korespondensi bisnis babagan masalah sing penting.
Kepiye cara nglindhungi simpul nalika watesan dicabut?
Isolasi layanan "ora diwatesi":
Ing jaman kepungkur, kita wis ndeleng sawetara simpul mlebu menyang negara notReady, utamane amarga layanan sing nggunakake akeh sumber daya.
Kita mutusake kanggo nyelehake layanan kasebut ing simpul sing kapisah ("label") supaya ora ngganggu layanan "gegandhengan". Akibaté, kanthi menehi tandha sawetara kelenjar lan nambah parameter toleransi kanggo layanan "ora ana hubungane", kita entuk kontrol luwih gedhe ing kluster, lan dadi luwih gampang kanggo ngenali masalah karo kelenjar. Kanggo nindakake proses sing padha dhewe, sampeyan bisa kenal dhewe .
Nemtokake panjalukan prosesor lan memori sing bener:
Wedi paling gedhe yaiku proses kasebut bakal nggunakake akeh sumber daya lan simpul bakal mandheg nanggapi panjaluk. Wiwit saiki (matur nuwun kanggo Datadog) kita bisa ngawasi kanthi jelas kabeh layanan ing kluster kita, aku nganalisa sawetara wulan operasi sing direncanakake minangka "ora ana hubungane". Aku mung nyetel panggunaan CPU maksimum karo wates 20%, lan kanthi mangkono diparengake papan ing simpul ing cilik k8s nyoba kanggo nemtokake layanan liyane kanggo simpul.
Nalika sampeyan bisa ndeleng ing grafik, beban maksimum ing prosesor wis tekan 242m Inti CPU (inti prosesor 0.242). Kanggo panjalukan prosesor, cukup kanggo njupuk nomer sing rada gedhe tinimbang nilai iki. Wigati dimangerteni manawa layanan kasebut fokus ing pangguna, nilai beban puncak cocog karo lalu lintas.
Tumindak sing padha karo panggunaan memori lan pitakon, lan voila - sampeyan wis siap! Kanggo keamanan luwih, sampeyan bisa nambah autoscaling pod horisontal. Mangkono, saben beban sumber daya dhuwur, autoscaling bakal nggawe polong anyar, lan kubernetes bakal disebarake menyang simpul kanthi ruang kosong. Yen ora ana papan sing isih ana ing kluster kasebut, sampeyan bisa nyetel tandha utawa ngatur tambahan kelenjar anyar liwat autoscaling.
Saka minus, perlu dicathet yen kita kalah ing "", i.e. nomer wadhah mlaku ing siji simpul. Kita uga bisa duwe akeh "relaxations" ing Kapadhetan lalu lintas kurang, lan ana uga kasempatan sing bakal tekan beban prosesor dhuwur, nanging autoscaling kelenjar kudu bantuan karo terakhir.
Результаты
Aku seneng nerbitake asil eksperimen sing apik iki sajrone sawetara minggu kepungkur; kita wis ndeleng perbaikan sing signifikan kanggo nanggepi kabeh layanan sing diowahi:
Kita entuk asil paling apik ing kaca ngarep (), ana layanan cepet ing kaping rong puluh!
Apa bug kernel Linux didandani?
Ya distribusi versi 4.19 lan luwih dhuwur.
Nanging, nalika maca kanggo kaping pindho ing September 2020 kita isih nemokake nyebutake sawetara proyek Linux kanthi bug sing padha. Aku percaya manawa sawetara distribusi Linux isih duwe bug iki lan mung bisa ndandani.
Yen versi distribusi luwih murah tinimbang 4.19, aku nyaranake nganyari paling anyar, nanging ing kasus apa wae, sampeyan kudu nyoba mbusak watesan prosesor lan ndeleng manawa throttling tetep. Ing ngisor iki sampeyan bisa ndeleng dhaptar parsial layanan manajemen Kubernetes lan distribusi Linux:
- Debian: ndandani terintegrasi menyang versi distribusi paling anyar, , lan katon cukup seger (). Sawetara versi sadurungé uga bisa didandani.
- Ubuntu: ndandani terintegrasi menyang versi paling anyar
- EKS wis entuk fix durung . Yen versi luwih murah tinimbang iki, sampeyan kudu nganyari AMI.
- kops: у
kops 1.18+Gambar host utama yaiku Ubuntu 20.04. Yen versi kops sampeyan luwih lawas, sampeyan bisa uga kudu ngenteni perbaikan. Awake dhewe ngenteni saiki. - GKE (Google Cloud): Ndandani terpadu , Nanging ana masalah karo throttling .
Apa sing kudu ditindakake yen ndandani masalah throttling?
Aku ora yakin masalah wis rampung ditanggulangi. Nalika kita njaluk versi kernel karo fix, Aku bakal nyoba kluster lan nganyari kirim. Yen ana sing wis nganyari, aku kepengin maca asil sampeyan.
kesimpulan
- Yen sampeyan nggarap kontaner Docker ing Linux (ora preduli Kubernetes, Mesos, Swarm utawa liyane), kontaner sampeyan bisa ilang kinerja amarga throttling;
- Coba nganyari menyang versi distribusi paling anyar kanthi pangarep-arep yen bug kasebut wis didandani;
- Mbusak watesan prosesor bakal ngatasi masalah kasebut, nanging iki minangka teknik mbebayani sing kudu digunakake kanthi ati-ati (luwih becik nganyari kernel dhisik lan mbandhingake asil);
- Yen sampeyan wis ngilangi watesan CPU, ngawasi panggunaan CPU lan memori kanthi ati-ati lan priksa manawa sumber daya CPU ngluwihi konsumsi sampeyan;
- Pilihan sing aman bakal dadi polong skala otomatis kanggo nggawe polong anyar ing kasus beban hardware sing dhuwur, supaya kubernetes menehi simpul gratis.
Muga-muga kiriman iki mbantu sampeyan nambah kinerja sistem wadah sampeyan.
PS penulis cocog karo maca lan komentator (ing Inggris).
Source: www.habr.com