Deui dina 2016 kami di panyangga , sareng ayeuna sakitar 60 titik (dina AWS) sareng 1500 wadahna damel di k8s kluster kami anu dikelola ku . Najan kitu, urang dipindahkeun ka microservices ngaliwatan trial and error, komo sanggeus sababaraha taun gawé bareng k8s kami masih Nyanghareupan masalah anyar. Dina pos ieu urang bakal ngobrol ngeunaan watesan processor: naha urang pikir maranéhanana éta prakték alus tur naha maranéhna tungtungna teu jadi alus.
watesan processor na throttling
Sapertos seueur pangguna Kubernetes sanés, . Tanpa setting sapertos kitu, wadah dina hiji titik tiasa nyandak sadaya kakuatan prosesor, anu nyababkeun prosés penting Kubernetes (contona. kubelet) bakal eureun ngaréspon kana pamundut. Janten, netepkeun wates CPU mangrupikeun cara anu saé pikeun ngajagi titik anjeun.
Watesan prosésor nyetél wadahna kana waktos CPU maksimum anu tiasa dianggo pikeun période anu khusus (standar nyaéta 100ms), sareng wadahna moal pernah ngaleuwihan wates ieu. Dina Kubernetes pikeun throttling wadahna sarta nyegah ti ngaleuwihan wates, alat husus dipaké , tapi wates CPU jieunan ieu ngeureunkeun kinerja sareng ningkatkeun waktos réspon wadah anjeun.
Naon anu tiasa kajantenan upami urang henteu netepkeun wates prosesor?
Hanjakal, urang sorangan kapaksa nyanghareupan masalah ieu. Unggal titik gaduh prosés anu tanggung jawab pikeun ngatur wadah kubelet, sarta anjeunna dieureunkeun ngabales requests. Node, nalika ieu kajantenan, bakal lebet ka nagara NotReady, sareng wadahna bakal dialihkeun ka tempat anu sanés sareng nyiptakeun masalah anu sami dina titik énggal. Teu hiji skenario idéal, ngomong sahanteuna.
Manifestasi masalah throttling sareng réspon
Métrik konci pikeun tracking wadahna nyaéta trottling, Ieu nembongkeun sabaraha kali wadahna anjeun geus throttled. Kami perhatikeun kalayan minat ayana throttling dina sababaraha wadah, henteu paduli naha beban prosesor éta ekstrim atanapi henteu. Salaku conto, hayu urang tingali salah sahiji API utama urang:
Sakumaha anjeun tiasa tingali di handap, kami geus nyetel wates pikeun 800m (0.8 atanapi 80% inti), sareng nilai puncak dina jangkauan pangsaéna 200m (20% inti). Sigana mah sateuacan nga-throttling jasa kami masih gaduh seueur kakuatan prosesor, tapi ...
Anjeun panginten tiasa perhatikeun yén sanaos beban prosesor sahandapeun wates anu ditangtukeun - sacara signifikan di handap - throttling tetep kajantenan.
Nyanghareupan ieu, urang geura-giru manggihan sababaraha sumber (, , ) ngeunaan turunna kinerja sareng waktos réspon jasa kusabab throttling.
Naha urang ningali throttling dina beban CPU low? Versi pondokna nyaéta: "Aya bug dina kernel Linux anu nyababkeun throttling wadah anu teu perlu sareng wates prosésor anu ditangtukeun." Upami anjeun resep kana sifat masalah, anjeun tiasa maca presentasi ( и pilihan) ku Dave Chiluk.
Ngahapus larangan CPU (kalayan ati-ati pisan)
Saatos diskusi anu panjang, kami mutuskeun pikeun ngaleungitkeun larangan prosesor tina sadaya jasa anu langsung atanapi henteu langsung mangaruhan fungsi kritis pikeun pangguna kami.
Kaputusan éta henteu gampang sabab kami ngahargaan pisan kana stabilitas klaster urang. Baheula, kami parantos ékspérimén sareng instabilitas kluster kami, teras jasa éta nyéépkeun seueur teuing sumber daya sareng ngalambatkeun padamelan sadaya titikna. Ayeuna sadayana rada béda: urang gaduh pamahaman anu jelas ngeunaan naon anu dipiharep tina klaster urang, ogé strategi anu saé pikeun ngalaksanakeun parobihan anu direncanakeun.
Korespondensi bisnis dina masalah anu mendesak.
Kumaha ngajaga titik anjeun nalika larangan dicabut?
Isolasi jasa "teu kawatesanan":
Baheula, urang parantos ningali sababaraha titik asup kana kaayaan notReady, utamana alatan jasa nu dikonsumsi loba teuing sumberdaya.
Urang mutuskeun pikeun nempatkeun jasa sapertos dina titik misah ("dilabélan") ambéh maranéhanana henteu ngaganggu jasa "patali". Hasilna, ku nyirian sababaraha titik jeung nambahkeun parameter kasabaran kana jasa "teu patali", kami ngahontal kontrol gede leuwih kluster, sarta eta janten gampang pikeun ngaidentipikasi masalah sareng titik. Pikeun ngalaksanakeun prosés anu sami, anjeun tiasa familiarize diri .
Netepkeun prosésor sareng mémori anu leres:
Sieun pangbadagna kami nyaéta yén prosésna bakal meakeun seueur teuing sumber daya sareng titik bakal lirén ngaréspon kana pamundut. Kusabab ayeuna (hatur nuhun ka Datadog) kami jelas tiasa ngawas sadaya jasa dina kluster kami, kuring nganalisis sababaraha bulan operasi jalma anu kami rencanana ditunjuk salaku "teu aya hubunganana". Kuring saukur nyetel pamakean CPU maksimum kalawan margin 20%, sahingga spasi disadiakeun dina titik bisi k8s nyoba napelkeun jasa séjén pikeun titik.
Sakumaha anjeun tiasa tingali dina grafik, beban maksimum dina processor geus ngahontal 242m Inti CPU (inti prosesor 0.242). Pikeun pamundut processor, cukup nyandak hiji angka rada leuwih badag batan nilai ieu. Punten dicatet yén kusabab jasa éta dipuseurkeun ku pangguna, nilai beban puncak saluyu sareng lalu lintas.
Lakukeun sami sareng pamakean memori sareng patarosan, sareng voila - anjeun parantos siap! Pikeun kaamanan anu langkung ageung, anjeun tiasa nambihan skala otomatis pod horizontal. Ku kituna, unggal waktos beban sumberdaya tinggi, autoscaling bakal nyieun pods anyar, sarta kubernetes bakal ngadistribusikaeun kana titik kalawan spasi bébas. Bisi euweuh spasi ditinggalkeun dina klaster sorangan, anjeun tiasa nyetél diri waspada atawa ngonpigurasikeun tambahan titik anyar ngaliwatan autoscaling maranéhna.
Tina minuses, éta patut dicatet yén urang éléh dina "", nyaéta. Jumlah wadahna ngajalankeun dina hiji titik. Urang ogé bisa mibanda loba "rélaxations" dina kapadetan lalulintas low, sarta aya ogé kasempetan nu bakal ngahontal beban processor tinggi, tapi titik autoscaling kedah ngabantu jeung dimungkinkeun.
Hasil
Abdi resep nyebarkeun hasil anu saé ieu tina ékspérimén dina sababaraha minggu katukang; kami parantos ningali perbaikan anu signifikan pikeun ngaréspon dina sadaya jasa anu dirobih:
Kami ngahontal hasil anu pangsaéna dina halaman utama kami (), aya layanan gancangan di dua puluh dua kali!
Naha bug kernel Linux dibenerkeun?
Leres, distribusi versi 4.19 sareng anu langkung luhur.
Sanajan kitu, sanggeus maca pikeun kadua Séptémber 2020 kami masih mendakan nyebatkeun sababaraha proyék Linux anu gaduh bug anu sami. Kuring yakin yén sababaraha distribusi Linux masih gaduh bug ieu sareng nuju ngusahakeun ngalereskeunana.
Upami versi distribusi anjeun langkung handap tina 4.19, kuring bakal nyarankeun ngamutahirkeun ka anu pang anyarna, tapi dina sagala hal anjeun kedah nyobian ngahapus larangan prosésor sareng ningali upami throttling tetep. Di handap anjeun tiasa ningali daptar parsial jasa manajemén Kubernetes sareng distribusi Linux:
- Debian: fix terpadu kana versi panganyarna tina distribusi, , sareng katingalina rada seger (). Sababaraha vérsi saméméhna ogé tiasa dilereskeun.
- Ubuntu: fix terpadu kana versi panganyarna
- EKS geus meunang fix acan . Upami versi anjeun langkung handap tina ieu, anjeun kedah ngapdet AMI.
- kops: у
kops 1.18+Gambar host utama nyaéta Ubuntu 20.04. Upami versi kops anjeun langkung lami, anjeun kedah ngantosan perbaikan. Urang sorangan nungguan ayeuna. - GKE (Google Cloud): Fix terpadu , Tapi aya masalah sareng throttling .
Naon anu kudu dilakukeun upami perbaikan ngalereskeun masalah throttling?
Kaula teu yakin kana éta masalah sagemblengna ngumbar. Lamun urang meunang ka versi kernel jeung fix, Kuring baris nguji kluster jeung ngamutahirkeun pos. Upami aya anu parantos ngamutahirkeun, kuring bakal resep maca hasil anjeun.
kacindekan
- Upami anjeun damel sareng wadah Docker dina Linux (henteu masalah Kubernetes, Mesos, Swarm atanapi anu sanésna), wadah anjeun tiasa kaleungitan kinerja kusabab throttling;
- Coba ngamutahirkeun kana vérsi pangénggalna distribusi anjeun kalayan harepan bug éta parantos dibenerkeun;
- Nyoplokkeun wates prosésor bakal ngabéréskeun masalah, tapi ieu téh téknik bahaya nu kudu dipaké kalawan caution ekstrim (leuwih hade mun mimiti ngamutahirkeun kernel jeung ngabandingkeun hasilna);
- Upami anjeun parantos ngaleungitkeun wates CPU, pantau sacara saksama CPU sareng pamakean mémori anjeun sareng pastikeun sumberdaya CPU anjeun ngaleuwihan konsumsi anjeun;
- Hiji pilihan aman bakal autoscale pods pikeun nyieun pods anyar bisi beban hardware tinggi, ku kituna kubernetes napelkeun aranjeunna ka titik bébas.
Abdi ngarepkeun tulisan ieu ngabantosan anjeun ningkatkeun kinerja sistem wadah anjeun.
PS pangarang pakait jeung pamiarsa jeung komentator (dina basa Inggris).
sumber: www.habr.com