In 2016 waren wij bij Buffer , en nu werken ongeveer 60 knooppunten (op AWS) en 1500 containers aan ons k8s-cluster beheerd door . We zijn echter met vallen en opstaan overgestapt op microservices, en zelfs na een aantal jaren met k8s te hebben gewerkt, worden we nog steeds met nieuwe problemen geconfronteerd. In dit bericht zullen we erover praten processorbeperkingen: waarom we dachten dat ze een goede praktijk waren en waarom ze uiteindelijk niet zo goed waren.
Processorbeperkingen en throttling
Net als veel andere Kubernetes-gebruikers, . Zonder een dergelijke instelling kunnen containers in een node al het processorvermogen in beslag nemen, wat weer zorgt voor belangrijke Kubernetes-processen (bijvoorbeeld kubelet) reageert niet meer op verzoeken. Het instellen van CPU-limieten is dus een goede manier om uw knooppunten te beschermen.
Processorlimieten stellen een container in op de maximale CPU-tijd die deze gedurende een specifieke periode kan gebruiken (standaard is 100 ms), en de container zal deze limiet nooit overschrijden. In Kubernetes voor smoren container en om te voorkomen dat deze de limiet overschrijdt, wordt een speciaal gereedschap gebruikt , maar deze kunstmatige CPU-limieten hebben uiteindelijk een negatieve invloed op de prestaties en verhogen de responstijd van uw containers.
Wat kan er gebeuren als we geen processorlimieten instellen?
Helaas hebben wij zelf met dit probleem te maken gehad. Elk knooppunt heeft een proces dat verantwoordelijk is voor het beheer van containers kubelet, en hij reageerde niet meer op verzoeken. Wanneer dit gebeurt, gaat het knooppunt naar de status NotReady, en containers ervan zullen ergens anders worden omgeleid en dezelfde problemen veroorzaken op nieuwe knooppunten. Op zijn zachtst gezegd geen ideaal scenario.
Manifestatie van het probleem van throttling en respons
De belangrijkste maatstaf voor het volgen van containers is trottling, het laat zien hoe vaak uw container is gesmoord. Met belangstelling hebben we de aanwezigheid van throttling in sommige containers opgemerkt, ongeacht of de processorbelasting extreem was of niet. Laten we als voorbeeld eens kijken naar een van onze belangrijkste API's:
Zoals je hieronder kunt zien, hebben we de limiet ingesteld op 800m (0.8 of 80% kern), en piekwaarden op zijn best bereiken 200m (20% kern). Het lijkt erop dat voordat we de service beperken, we nog steeds voldoende processorkracht hebben, maar...
Het is u misschien opgevallen dat zelfs als de processorbelasting onder de opgegeven limieten ligt (ruim daaronder), er nog steeds throttling optreedt.
Geconfronteerd hiermee ontdekten we al snel verschillende bronnen (, , ) over de daling van de prestaties en responstijd van services als gevolg van throttling.
Waarom zien we throttling bij een lage CPU-belasting? De korte versie luidt: “er zit een bug in de Linux-kernel die onnodige throttling van containers met gespecificeerde processorlimieten veroorzaakt.” Als u geïnteresseerd bent in de aard van het probleem, kunt u de presentatie lezen ( и opties) door Dave Chiluk.
CPU-beperkingen verwijderen (met uiterste voorzichtigheid)
Na langdurige discussies hebben we besloten de processorbeperkingen op te heffen van alle services die direct of indirect van invloed zijn op de kritieke functionaliteit voor onze gebruikers.
De beslissing was niet eenvoudig omdat we de stabiliteit van ons cluster hoog in het vaandel hebben staan. In het verleden hebben we al geëxperimenteerd met de instabiliteit van ons cluster, maar toen verbruikten de services te veel bronnen en vertraagden ze het werk van hun hele knooppunt. Nu was alles enigszins anders: we hadden een duidelijk beeld van wat we van onze clusters verwachtten en een goede strategie om de geplande veranderingen door te voeren.
Zakelijke correspondentie over een dringend onderwerp.
Hoe beschermt u uw knooppunten wanneer de beperkingen worden opgeheven?
Isolatie van “onbeperkte” diensten:
In het verleden hebben we al gezien dat sommige knooppunten in een toestand terechtkwamen notReady, voornamelijk als gevolg van diensten die te veel bronnen verbruikten.
We hebben besloten dergelijke services in afzonderlijke (“gelabelde”) knooppunten te plaatsen, zodat ze de “gerelateerde” services niet verstoren. Als gevolg hiervan kregen we, door enkele knooppunten te markeren en de tolerantieparameter toe te voegen aan ‘niet-gerelateerde’ services, meer controle over het cluster en werd het gemakkelijker voor ons om problemen met knooppunten te identificeren. Om soortgelijke processen zelf uit te voeren, kunt u vertrouwd raken met .
Een correct processor- en geheugenverzoek toewijzen:
Onze grootste angst was dat het proces te veel bronnen zou verbruiken en dat het knooppunt niet meer zou reageren op verzoeken. Omdat we nu (dankzij Datadog) alle services op ons cluster duidelijk konden monitoren, heb ik een aantal maanden van werking geanalyseerd van de services die we als ‘niet-gerelateerd’ wilden bestempelen. Ik heb eenvoudigweg het maximale CPU-gebruik ingesteld met een marge van 20%, en zo ruimte in het knooppunt toegewezen voor het geval k8s andere services aan het knooppunt probeert toe te wijzen.
Zoals u in de grafiek kunt zien, is de maximale belasting van de processor bereikt 242m CPU-kernen (0.242 processorkernen). Voor een processorverzoek is het voldoende om een getal te nemen dat iets groter is dan deze waarde. Houd er rekening mee dat, aangezien de services op de gebruiker gericht zijn, de piekbelastingswaarden samenvallen met het verkeer.
Doe hetzelfde met geheugengebruik en queries, en voila: je bent helemaal klaar! Voor meer veiligheid kunt u automatisch schalen van horizontale pods toevoegen. Dus elke keer dat de resourcebelasting hoog is, zal automatisch schalen nieuwe pods creëren, en kubernetes zal deze distribueren naar knooppunten met vrije ruimte. Als er geen ruimte meer is in het cluster zelf, kunt u een waarschuwing instellen of de toevoeging van nieuwe knooppunten configureren via hun automatische schaling.
Van de minnen is het vermeldenswaard dat we verloren hebben in “", d.w.z. aantal containers dat op één knooppunt draait. Ook kunnen we bij een lage verkeersdichtheid veel “versoepelingen” hebben, en is er ook een kans dat je een hoge processorbelasting bereikt, maar bij dat laatste zouden autoscaling-nodes moeten helpen.
Bevindingen
Met genoegen publiceer ik deze uitstekende resultaten van experimenten van de afgelopen weken; we hebben al aanzienlijke verbeteringen gezien in de respons op alle aangepaste services:
We behaalden de beste resultaten op onze startpagina (), daar versnelde de service tweeëntwintig keer!
Is de Linux-kernelbug opgelost?
Ja, distributies versie 4.19 en hoger.
Echter bij het lezen voor 2020 september XNUMX we komen nog steeds vermeldingen tegen van enkele Linux-projecten met een soortgelijke bug. Ik geloof dat sommige Linux-distributies deze bug nog steeds hebben en werken eraan om deze op te lossen.
Als uw distributieversie lager is dan 4.19, raad ik u aan te updaten naar de nieuwste versie, maar u moet in ieder geval proberen de processorbeperkingen te verwijderen en kijken of de beperking aanhoudt. Hieronder ziet u een gedeeltelijke lijst met Kubernetes-beheerservices en Linux-distributies:
- Debian: fix geïntegreerd in de nieuwste versie van de distributie, , en ziet er vrij fris uit (). Sommige eerdere versies zijn mogelijk ook gerepareerd.
- Ubuntu: fix geïntegreerd in de nieuwste versie
- EKS heeft nog een oplossing . Als uw versie lager is dan dit, moet u de AMI bijwerken.
- kop: у
kops 1.18+De hoofdhostimage is Ubuntu 20.04. Als uw versie van kops ouder is, moet u mogelijk wachten op een oplossing. Wijzelf wachten nu af. - GKE (Google Cloud): Fix geïntegreerd Er zijn echter problemen met de beperking .
Wat moet ik doen als de oplossing het beperkingsprobleem heeft opgelost?
Ik ben er niet zeker van dat het probleem volledig is opgelost. Wanneer we met de oplossing bij de kernelversie komen, zal ik het cluster testen en het bericht bijwerken. Als iemand al een update heeft uitgevoerd, zou ik graag uw resultaten willen lezen.
Conclusie
- Als u met Docker-containers onder Linux werkt (ongeacht Kubernetes, Mesos, Swarm of anderen), kunnen uw containers prestaties verliezen als gevolg van throttling;
- Probeer bij te werken naar de nieuwste versie van uw distributie in de hoop dat de bug al is verholpen;
- Het verwijderen van processorlimieten zal het probleem oplossen, maar dit is een gevaarlijke techniek die met uiterste voorzichtigheid moet worden gebruikt (het is beter om eerst de kernel bij te werken en de resultaten te vergelijken);
- Als u de CPU-limieten heeft verwijderd, controleer dan zorgvuldig uw CPU- en geheugengebruik en zorg ervoor dat uw CPU-bronnen uw verbruik overschrijden;
- Een veilige optie zou zijn om peulen automatisch te schalen om nieuwe peulen te maken in geval van hoge hardwarebelasting, zodat kubernetes ze aan vrije knooppunten toewijst.
Ik hoop dat dit bericht je helpt de prestaties van je containersystemen te verbeteren.
PS de auteur correspondeert met lezers en commentatoren (in het Engels).
Bron: www.habr.com