Noong 2016 kami sa Buffer , at ngayon ay humigit-kumulang 60 node (sa AWS) at 1500 container ang gumagana sa aming k8s cluster na pinamamahalaan ng . Gayunpaman, lumipat kami sa mga microservice sa pamamagitan ng pagsubok at error, at kahit na pagkatapos ng ilang taon ng pakikipagtulungan sa mga k8 ay nahaharap pa rin kami sa mga bagong problema. Sa post na ito ay pag-uusapan natin mga limitasyon ng processor: kung bakit naisip namin na sila ay mahusay na pagsasanay at kung bakit sila ay hindi naging napakahusay.
Mga limitasyon ng processor at throttling
Tulad ng maraming iba pang gumagamit ng Kubernetes, . Kung walang ganoong setting, maaaring kunin ng mga container sa isang node ang lahat ng lakas ng processor, na nagiging sanhi ng mahahalagang proseso ng Kubernetes (halimbawa kubelet) ay hihinto sa pagtugon sa mga kahilingan. Kaya, ang pagtatakda ng mga limitasyon ng CPU ay isang magandang paraan upang maprotektahan ang iyong mga node.
Ang mga limitasyon ng processor ay nagtatakda ng isang container sa maximum na oras ng CPU na magagamit nito para sa isang partikular na panahon (default ay 100ms), at ang container ay hindi kailanman lalampas sa limitasyong ito. Sa Kubernetes para sa throttling lalagyan at pigilan itong lumampas sa limitasyon, ginagamit ang isang espesyal na tool , ngunit ang mga artipisyal na limitasyon ng CPU na ito ay nauuwi sa pagkasira ng performance at pagpapataas ng oras ng pagtugon ng iyong mga container.
Ano ang maaaring mangyari kung hindi kami magtatakda ng mga limitasyon ng processor?
Sa kasamaang palad, kami mismo ang kailangang harapin ang problemang ito. Ang bawat node ay may prosesong responsable para sa pamamahala ng mga lalagyan kubelet, at huminto siya sa pagtugon sa mga kahilingan. Ang node, kapag nangyari ito, ay mapupunta sa estado NotReady, at ang mga lalagyan mula dito ay ire-redirect sa ibang lugar at lilikha ng parehong mga problema sa mga bagong node. Hindi isang mainam na senaryo, upang sabihin ang hindi bababa sa.
Pagpapakita ng problema ng throttling at pagtugon
Ang pangunahing sukatan para sa pagsubaybay sa container ay trottling, ipinapakita nito kung ilang beses na-throttle ang iyong container. Napansin namin nang may interes ang pagkakaroon ng throttling sa ilang mga container, hindi alintana kung ang pag-load ng processor ay sukdulan o hindi. Bilang halimbawa, tingnan natin ang isa sa aming mga pangunahing API:
Gaya ng nakikita mo sa ibaba, itinakda namin ang limitasyon sa 800m (0.8 o 80% core), at mga pinakamataas na halaga sa pinakamahusay na maabot 200m (20% core). Mukhang bago i-throttling ang serbisyo ay mayroon pa kaming maraming lakas ng processor, gayunpaman...
Maaaring napansin mo na kahit na ang pag-load ng processor ay mas mababa sa tinukoy na mga limitasyon - makabuluhang mas mababa - nangyayari pa rin ang throttling.
Sa harap nito, natuklasan namin sa lalong madaling panahon ang ilang mga mapagkukunan (, , ) tungkol sa pagbaba ng performance at oras ng pagtugon ng mga serbisyo dahil sa throttling.
Bakit nakikita natin ang throttling sa mababang pag-load ng CPU? Ang maikling bersyon ay: "may isang bug sa Linux kernel na nagdudulot ng hindi kinakailangang throttling ng mga lalagyan na may tinukoy na mga limitasyon ng processor." Kung interesado ka sa likas na katangian ng problema, maaari mong basahin ang presentasyon ( ΠΈ mga pagpipilian) ni Dave Chiluk.
Pag-alis ng mga paghihigpit sa CPU (na may matinding pag-iingat)
Pagkatapos ng mahabang talakayan, nagpasya kaming alisin ang mga paghihigpit sa processor sa lahat ng serbisyo na direkta o hindi direktang nakaapekto sa kritikal na pagpapagana para sa aming mga user.
Hindi naging madali ang desisyon dahil lubos naming pinahahalagahan ang katatagan ng aming kumpol. Noong nakaraan, nag-eksperimento na kami sa kawalang-tatag ng aming cluster, at pagkatapos ay ang mga serbisyo ay kumonsumo ng masyadong maraming mapagkukunan at pinabagal ang gawain ng kanilang buong node. Ngayon ang lahat ay medyo naiiba: mayroon kaming malinaw na pag-unawa sa kung ano ang inaasahan namin mula sa aming mga kumpol, pati na rin ang isang mahusay na diskarte para sa pagpapatupad ng mga nakaplanong pagbabago.
Pagsusulatan sa negosyo sa isang mahalagang isyu.
Paano protektahan ang iyong mga node kapag inalis ang mga paghihigpit?
Pagbubukod ng "hindi pinaghihigpitan" na mga serbisyo:
Noong nakaraan, nakita na natin ang ilang mga node na pumasok sa isang estado notReady, pangunahin dahil sa mga serbisyong gumagamit ng masyadong maraming mapagkukunan.
Napagpasyahan naming ilagay ang mga naturang serbisyo sa magkahiwalay na node ("may label") upang hindi makagambala ang mga ito sa mga serbisyong "kaugnay". Bilang resulta, sa pamamagitan ng pagmamarka ng ilang node at pagdaragdag ng parameter ng tolerance sa mga serbisyong "hindi nauugnay", nakamit namin ang higit na kontrol sa cluster, at naging mas madali para sa amin na tumukoy ng mga problema sa mga node. Upang maisagawa ang mga katulad na proseso sa iyong sarili, maaari mong gawing pamilyar ang iyong sarili .
Pagtatalaga ng tamang processor at kahilingan sa memorya:
Ang aming pinakamalaking takot ay ang proseso ay kumonsumo ng masyadong maraming mapagkukunan at ang node ay titigil sa pagtugon sa mga kahilingan. Dahil ngayon (salamat sa Datadog) malinaw naming masusubaybayan ang lahat ng mga serbisyo sa aming cluster, sinuri ko ang ilang buwan ng operasyon ng mga binalak naming italaga bilang "walang kaugnayan". Itinakda ko lang ang maximum na paggamit ng CPU na may margin na 20%, at sa gayon ay naglalaan ng espasyo sa node kung sakaling subukan ng k8s na magtalaga ng iba pang mga serbisyo sa node.
Gaya ng makikita mo sa graph, naabot na ang maximum load sa processor 242m Mga core ng CPU (0.242 na mga core ng processor). Para sa isang kahilingan sa processor, sapat na na kumuha ng numero na bahagyang mas malaki kaysa sa halagang ito. Pakitandaan na dahil ang mga serbisyo ay nakasentro sa gumagamit, ang mga peak load value ay kasabay ng trapiko.
Gawin ang parehong sa paggamit ng memorya at mga query, at voila - naka-set up ka na! Para sa higit na seguridad, maaari kang magdagdag ng horizontal pod autoscaling. Kaya, sa tuwing mataas ang resource load, ang autoscaling ay lilikha ng mga bagong pod, at ipapamahagi ng mga kubernete ang mga ito sa mga node na may libreng espasyo. Kung sakaling wala nang espasyo sa mismong cluster, maaari mong itakda ang iyong sarili ng alerto o i-configure ang pagdaragdag ng mga bagong node sa pamamagitan ng kanilang autoscaling.
Sa mga minus, nararapat na tandaan na natalo tayo sa "", ibig sabihin. bilang ng mga lalagyan na tumatakbo sa isang node. Maaari din kaming magkaroon ng maraming "relaxation" sa mababang densidad ng trapiko, at mayroon ding pagkakataon na maabot mo ang mataas na load ng processor, ngunit dapat makatulong ang mga autoscaling node sa huli.
Natuklasan
Ikinalulugod kong i-publish ang mahuhusay na resultang ito mula sa mga eksperimento sa nakalipas na ilang linggo; nakakita na kami ng mga makabuluhang pagpapabuti bilang tugon sa lahat ng binagong serbisyo:
Nakamit namin ang pinakamahusay na mga resulta sa aming home page (), doon ay bumilis ang serbisyo dalawampu't dalawang beses!
Naayos na ba ang Linux kernel bug?
Oo, mga pamamahagi bersyon 4.19 at mas mataas.
Gayunpaman, sa pagbabasa para sa ikalawa ng Setyembre 2020 nakatagpo pa rin kami ng mga pagbanggit ng ilang proyekto sa Linux na may katulad na bug. Naniniwala ako na ang ilang mga pamamahagi ng Linux ay mayroon pa ring bug na ito at nagsusumikap lamang sa pag-aayos nito.
Kung ang iyong bersyon ng pamamahagi ay mas mababa sa 4.19, inirerekumenda ko ang pag-update sa pinakabago, ngunit sa anumang kaso dapat mong subukang alisin ang mga paghihigpit sa processor at tingnan kung magpapatuloy ang throttling. Sa ibaba ay makikita mo ang isang bahagyang listahan ng mga serbisyo sa pamamahala ng Kubernetes at mga pamamahagi ng Linux:
- Debian: ayusin ang isinama sa pinakabagong bersyon ng pamamahagi, , at mukhang sariwa (). Ang ilang mga nakaraang bersyon ay maaari ding ayusin.
- Ubuntu: ayusin ang isinama sa pinakabagong bersyon
- May inaayos pa ang EKS . Kung ang iyong bersyon ay mas mababa kaysa dito, dapat mong i-update ang AMI.
- kops: Ρ
kops 1.18+Ang pangunahing imahe ng host ay magiging Ubuntu 20.04. Kung mas luma ang iyong bersyon ng kops, maaaring kailanganin mong maghintay para sa pag-aayos. Kami mismo ay naghihintay ngayon. - GKE (Google Cloud): Fix integrated , gayunpaman may mga problema sa throttling .
Ano ang gagawin kung naayos ng pag-aayos ang problema sa throttling?
Hindi ako sigurado na ang problema ay ganap na nalutas. Kapag nakarating na tayo sa bersyon ng kernel na may pag-aayos, susubukan ko ang kumpol at i-update ang post. Kung may nakapag-update na, interesado akong basahin ang iyong mga resulta.
Konklusyon
- Kung nagtatrabaho ka sa mga container ng Docker sa ilalim ng Linux (kahit na Kubernetes, Mesos, Swarm o iba pa), maaaring mawalan ng performance ang iyong mga container dahil sa throttling;
- Subukang mag-update sa pinakabagong bersyon ng iyong pamamahagi sa pag-asang naayos na ang bug;
- Ang pag-alis ng mga paghihigpit sa processor ay malulutas ang problema, ngunit ito ay isang mapanganib na pamamaraan na dapat gamitin nang may matinding pag-iingat (mas mahusay na i-update muna ang kernel at ihambing ang mga resulta);
- Kung inalis mo ang mga limitasyon ng CPU, maingat na subaybayan ang iyong paggamit ng CPU at memorya at tiyaking lampas sa iyong pagkonsumo ang iyong mga mapagkukunan ng CPU;
- Ang isang ligtas na opsyon ay ang pag-autoscale ng mga pod upang lumikha ng mga bagong pod sa kaso ng mataas na pag-load ng hardware, upang ang mga kubernetes ay italaga ang mga ito sa mga libreng node.
Sana ay matulungan ka ng post na ito na mapabuti ang pagganap ng iyong mga container system.
PS ang may-akda ay tumutugma sa mga mambabasa at komentarista (sa Ingles).
Pinagmulan: www.habr.com