🥇CPU-limiete en aggressiewe versnelling in Kubernetes

Let wel. vertaal.: Hierdie waarskuwende verhaal van Omio, die Europese reisversamelaar, neem lesers van basiese teorie na die fassinerende praktiese verwikkeldheid van Kubernetes-konfigurasie. Kennismaking met sulke gevalle help nie net om 'n mens se horison te verbreed nie, maar ook om nie-onbelangrike probleme te voorkom.

Het jy al ooit die feit teëgekom dat die toepassing "vasgehaak" het, opgehou het om op versoeke vir gesondheidsondersoeke te reageer en jy kon nie die rede vir hierdie gedrag verstaan nie? Een moontlike verduideliking hou verband met die kwotalimiet op SVE-hulpbronne. Dit sal in hierdie artikel bespreek word.

TL; DR:
Ons beveel sterk aan dat u SVE-limiete in Kubernetes deaktiveer (of CFS-kwotas in Kubelet deaktiveer) as u 'n weergawe van die Linux-kern met 'n CFS-kwota-fout gebruik. By die kern daar is ernstig en welbekend 'n fout wat lei tot oormatige versnelling en vertragings.

In Omio die hele infrastruktuur word deur Kubernetes bestuur. Al ons statige en staatlose werkladings loop uitsluitlik op Kubernetes (ons gebruik die Google Kubernetes Engine). In die afgelope ses maande het ons willekeurige verlangsamings begin waarneem. Toepassings vries of hou op reageer op gesondheidsondersoeke, verloor netwerkverbinding, ens. Sulke gedrag het ons lank verstom, en uiteindelik het ons besluit om die probleem ernstig te hanteer.

Samevatting van die artikel:

'n Paar woorde oor houers en Kubernetes;
Hoe SVE-versoeke en -limiete geïmplementeer word;
Hoe CPU limiet werk in multi-kern omgewings;
Hoe om SVE-versnelling op te spoor;
Probleemoplossing en besonderhede.

'n Paar woorde oor houers en Kubernetes

Kubernetes is in wese die moderne standaard in die wêreld van infrastruktuur. Sy hooftaak is houerorkestrasie.

Houers

In die verlede moes ons artefakte soos Java JAR's/WAR's, Python Eggs of uitvoerbare items bou om op bedieners te loop. Om hulle egter te laat werk, moes jy ekstra werk doen: installeer die runtime (Java/Python), plaas die nodige lêers op die regte plekke, verseker versoenbaarheid met 'n bepaalde weergawe van die bedryfstelsel, ensovoorts. Met ander woorde, jy moes baie aandag gee aan konfigurasiebestuur (wat dikwels twis tussen ontwikkelaars en stelseladministrateurs veroorsaak het).

Houers het alles verander. Nou is die houerbeeld die artefak. Dit kan voorgestel word as 'n soort uitgebreide uitvoerbare lêer wat nie net die program bevat nie, maar ook 'n volledige runtime-omgewing (Java / Python / ...), sowel as die nodige lêers / pakkette, vooraf geïnstalleer en gereed om te hardloop. Houers kan ontplooi en op verskillende bedieners uitgevoer word sonder enige bykomende stappe.

Daarbenewens loop houers in hul eie sandbox-omgewing. Hulle het hul eie virtuele netwerkadapter, hul eie lêerstelsel met beperkte toegang, hul eie proseshiërargie, hul eie beperkings op SVE en geheue, ens. Dit alles word geïmplementeer danksy 'n spesiale substelsel van die Linux-kern - naamruimtes (naamruimtes).

Kubernetes

Soos vroeër genoem, is Kubernetes 'n houer-orkeseerder. Dit werk so: jy voorsien dit van 'n poel masjiene, en dan sê jy: "Haai Kubernetes, laat tien gevalle van my houer hardloop met 2 verwerkers en 3 GB geheue elk, en hou hulle aan die gang!". Kubernetes sal vir die res sorg. Dit sal gratis kapasiteit vind, houers begin en herbegin indien nodig, 'n opdatering uitrol wanneer weergawes verander word, ens. In wese abstraheer Kubernetes die hardeware weg en maak 'n verskeidenheid stelsels bruikbaar om toepassings te ontplooi en uit te voer.

Kubernetes uit die oogpunt van 'n eenvoudige leek

Wat is versoeke en limiete in Kubernetes

Goed, ons het houers en Kubernetes uitgepluis. Ons weet ook dat verskeie houers op dieselfde masjien kan wees.

U kan 'n analogie met 'n gemeenskaplike woonstel trek. 'n Ruim kamer (motors/samestellings) word geneem en aan verskeie huurders (houers) verhuur. Kubernetes tree op as 'n makelaar. Die vraag ontstaan, hoe om huurders van konflik met mekaar te hou? Wat as een van hulle, sê, besluit om die badkamer vir 'n halwe dag te neem?

Dit is waar versoeke en limiete ter sprake kom. SVE Vra slegs vir beplanningsdoeleindes nodig. Dit is soort van soos 'n "wenslys" van die houer, en word gebruik om die mees geskikte nodus te kies. Terselfdertyd, die SVE Beperk kan vergelyk word met 'n huurooreenkoms - sodra ons 'n nodus vir die houer kies, dat kan nie gaan oor die perke. En hier kom die probleem...

Hoe versoeke en limiete in Kubernetes geïmplementeer word

Kubernetes gebruik die smoormeganisme (klokoorslaan) wat in die kern ingebou is om SVE-limiete te implementeer. As die toepassing die limiet oorskry, word versnelling geaktiveer (d.w.s. dit ontvang minder SVE-siklusse). Geheueversoeke en -limiete is anders georganiseer sodat dit makliker is om dit raak te sien. Om dit te doen, is dit genoeg om die laaste herbeginstatus van die peul na te gaan: is dit "OOMKilled". SVE-versnelling is nie so maklik nie, aangesien K8s slegs metrieke beskikbaar stel deur gebruik, nie deur cgroups nie.

SVE-versoek

Hoe CPU-versoek geïmplementeer word

Ter wille van eenvoud, kom ons kyk na die proses deur die voorbeeld van 'n masjien met 'n 4-kern SVE te gebruik.

K8s gebruik die cgroups-meganisme om hulpbrontoewysing (geheue en SVE) te bestuur. ’n Hiërargiese model is daarvoor beskikbaar: die kind erf die grense van die ouergroep. Die verspreidingbesonderhede word in die virtuele lêerstelsel gestoor (/sys/fs/cgroup). In die geval van 'n verwerker, hierdie /sys/fs/cgroup/cpu,cpuacct/*.

K8s gebruik lêer cpu.share verwerkerhulpbronne toe te ken. In ons geval ontvang die wortel-cgroup 4096 aandele van SVE-hulpbronne - 100% van die beskikbare verwerkerkrag (1 kern = 1024; dit is 'n vaste waarde). Die wortelgroep versprei hulpbronne proporsioneel na gelang van die aandele van afstammelinge gespesifiseer in cpu.share, en dié doen op hul beurt dieselfde met hul nageslag, ensovoorts. In 'n tipiese Kubernetes-gasheer het die wortel-cgroep drie kinders: system.slice, user.slice и kubepods. Die eerste twee subgroepe word gebruik om hulpbronne toe te wys tussen kritieke stelselladings en gebruikersprogramme buite K8's. Laaste - kubepods - geskep deur Kubernetes om hulpbronne tussen peule te versprei.

Die diagram hierbo toon dat die eerste en tweede subgroepe ontvang het 1024 aandele, terwyl die kuberpod-subgroep toegewys word 4096 aandele. Hoe is dit moontlik: die wortelgroep het immers slegs toegang tot 4096 aandele, en die som van die aandele van haar afstammelinge oorskry hierdie getal aansienlik (6144)? Die punt is dat die waarde 'n logiese betekenis het, so die Linux-skeduleerder (CFS) gebruik dit om SVE-hulpbronne proporsioneel toe te wys. In ons geval ontvang die eerste twee groepe 680 reële aandele (16,6% van 4096) en kubepod kry die res 2736 aandele. In die geval van stilstand, sal die eerste twee groepe nie die toegekende hulpbronne gebruik nie.

Gelukkig het die skeduleerder 'n meganisme om te verhoed dat ongebruikte SVE-hulpbronne vermors word. Dit dra "ledige" kapasiteit oor na die globale poel, vanwaar dit versprei word na groepe wat bykomende verwerkerkrag benodig (die oordrag vind plaas in bondels om afrondingsverliese te vermy). Dieselfde metode geld vir alle afstammelinge van afstammelinge.

Hierdie meganisme verseker ’n regverdige verspreiding van verwerkerkrag en verseker dat geen proses hulpbronne van ander “steel” nie.

SVE limiet

Alhoewel die limiet- en versoekkonfigurasies in K8's soortgelyk lyk, is die implementering daarvan fundamenteel anders: mees misleidend en die minste gedokumenteerde deel.

K8s siklusse CFS kwota meganisme om perke af te dwing. Hul instellings word in die lêers gespesifiseer cfs_period_us и cfs_quota_us in die cgroup-gids (daar is ook 'n lêer cpu.share).

In teenstelling met cpu.share, is die kwota gebaseer op periode van tyd, en nie op die beskikbare verwerkerkrag nie. cfs_period_us spesifiseer die duur van die tydperk (epog) - dit is altyd 100000 µs (100 ms). Daar is 'n opsie in K8s om hierdie waarde te verander, maar dit is vir eers net in alfa beskikbaar. Die skeduleerder gebruik die epog om gebruikte kwotas weer te begin. tweede lêer, cfs_quota_us, spesifiseer die beskikbare tyd (kwota) in elke epog. Let daarop dat dit ook in mikrosekondes gespesifiseer word. Die kwota kan die lengte van 'n epog oorskry; met ander woorde, dit kan groter as 100 ms wees.

Kom ons kyk na twee scenario's op 16-kern masjiene (die mees algemene tipe masjien wat ons by Omio het):

Scenario 1: 2 drade en 200 ms limiet. Geen versmoring nie

Scenario 2: 10 drade en 200ms limiet. Versnelling begin na 20ms, toegang tot SVE-hulpbronne hervat na nog 80ms

Kom ons sê jy stel die CPU-limiet op 2 pitte; Kubernetes sal hierdie waarde in 200ms vertaal. Dit beteken dat die houer 'n maksimum van 200ms se SVE-tyd kan gebruik sonder om te smoor.

En hier begin die pret. Soos hierbo genoem, is die beskikbare kwota 200ms. As jy parallelle werk het tien drade op 'n 12-kern masjien (sien illustrasie vir scenario 2), terwyl alle ander peule ledig is, sal die kwota binne net 20ms uitgeput wees (omdat 10 * 20ms = 200ms), en alle drade in hierdie peul sal hang » (smoor) vir die volgende 80 ms. Die situasie word vererger deur die reeds genoemde skeduleerder fout, waardeur oormatige versmoring plaasvind en die houer nie eers die bestaande kwota kan uitwerk nie.

Hoe om versnelling in peule te evalueer?

Meld net aan by die pod en doen cat /sys/fs/cgroup/cpu/cpu.stat.

nr_periods is die totale aantal skeduleerderperiodes;
nr_throttled — die aantal verswakte periodes in die samestelling nr_periods;
throttled_time is die kumulatiewe verswakte tyd in nanosekondes.

Wat gebeur nou eintlik?

As gevolg hiervan kry ons hoë versnelling in alle toepassings. Soms is hy in een en 'n half keer sterker as wat verwag is!

Dit lei tot verskeie foute - mislukkings van gereedheidskontroles, houerbevriesing, netwerkverbindingonderbrekings, time-outs binne diensoproepe. Uiteindelik vertaal dit in verhoogde latensie en verhoogde foutkoerse.

Besluit en gevolge

Alles is eenvoudig hier. Ons het SVE-limiete laat vaar en die OS-kern in groepe begin opdateer na die nuutste weergawe, waarin die fout reggestel is. Die aantal foute (HTTP 5xx) in ons dienste het onmiddellik aansienlik gedaal:

HTTP 5xx foute

HTTP 5xx-foute vir een kritieke diens

p95 reaksie tyd

Latency vir kritieke diensversoek, 95ste persentiel

Bedryfskoste

Aantal instansie-ure spandeer

Wat is die vangs?

Soos aan die begin van die artikel gesê:

Jy kan 'n analogie met 'n gemeenskaplike woonstel trek ... Kubernetes tree op as 'n makelaar. Maar hoe om huurders van konflik met mekaar te hou? Wat as een van hulle, sê, besluit om die badkamer vir 'n halwe dag te neem?

Hier is die vangs. Een onverskillige houer kan al die beskikbare SVE-hulpbronne op die masjien verbruik. As jy 'n slim toepassingstapel het (bv. JVM, Go, Node VM behoorlik gekonfigureer), dan is dit nie 'n probleem nie: jy kan lank in sulke toestande werk. Maar as toepassings swak geoptimaliseer is of glad nie geoptimaliseer is nie (FROM java:latest), kan die situasie buite beheer raak. By Omio het ons outomatiese basis Docker-lêers met voldoende verstekke vir die kerntaalstapel, so hierdie probleem het nie bestaan nie.

Ons beveel aan dat u die maatstawwe monitor GEBRUIK (gebruik, versadiging en foute), API-vertragings en foutkoerse. Maak seker dat die resultate ooreenstem met jou verwagtinge.

verwysings

Dit is ons geskiedenis. Die volgende materiaal het baie gehelp om te verstaan wat aan die gebeur is:

kernel.org → CFS-skeduleerder;
kernel.org → CFS-bandwydtebeheer;
Verstaan Linux-houerskedulering;
Alles wat jy moet weet oor Linux-houers, Deel I: Linux-beheergroepe en prosesisolasie;
Kubernetes-mislukkingsverhale - kyk vir "cpu throttling".

Kubernetes fout verslae:

Het jy soortgelyke probleme in jou praktyk teëgekom of het jy ondervinding wat verband hou met versnelling in produksie-omgewings met houers? Deel jou storie in die kommentaar!

SVE-beperkings en aggressiewe versnelling in Kubernetes