Nederlands

Optimaliseren van Cloud Schaalbaarheid: Implementatie van Horizontal Pod Autoscalers met Kubernetes

Maurits Beudeker Cloud consultant
Publicatiedatum: 16 mei 2024

In de recente samenwerking tussen CloudNation en een van haar klanten, stond een belangrijk vraagstuk centraal: hoe kan de klant beter omgaan met schaalbaarheid in hun cloudomgeving? In deze blog deelt Maurits Beudeker, Cloud Consultant bij CloudNation, hoe hij te hulp schoot om deze uitdaging aan te pakken en welke lessen hij uit deze ervaring heeft geleerd.

 

De uitdaging

De klant wilde specifieke hulp bij een probleem: zij kregen af en toe een grote hoeveelheid berichten in een keer binnen, die niet allemaal in een keer verwerkt konden worden. Dit zorgde voor een vertraging binnen de applicatie. Om dit te voorkomen wilden ze gebruikmaken van Horizontal Pod Autoscalers in hun Kubernetes cluster, hiermee kun je het aantal werkers dynamisch laten opschalen bij een hoog aantal verzoeken.

Waarom Horizontal Pod Autoscalers? Een Analogie:

Stel je voor dat je een supermarktmanager bent en je moet om je magazijn vol te houden, elke dag 100 vrachtwagens uitladen, je weet alleen niet precies wanneer de vrachtwagens komen, en je hebt maar 3 parkeerplaatsen. Als je niet weet wanneer de vrachtwagens precies arriveren, ga je dan voor de hele dag 30 magazijnmedewerkers betalen? Hierdoor loop je het risico dat, wanneer er niks te doen is, je medewerkers niks te doen hebben, en stel er komen toch ineens negen vrachtwagens tegelijk, dan kan het zijn dat je nog steeds te veel werk hebt voor 30 medewerkers. Zou het niet fantastisch zijn dat je, afhankelijk van hoe veel vrachtwagens er op het moment voor je magazijn staan, je altijd on-demand, precies het juiste aantal werknemers hebt om de vrachtwagens in korte tijd te legen, en zodra je ze niet meer nodig hebt, dat ze op magische wijze weer verdwijnen (en je als supermarktmanager niet 60x een minimum uurloon moet betalen)

Hiervoor zijn er drie dingen nodig:

  • Applicatie Metrics (Applicatie specifieke statistieken)
    • Dit is in de analogie iemand die noteert hoe veel vrachtwagens er nu staan te wachten om te parkeren, zodat ze uitgeladen kunnen worden
  • Prometheus (een Applicatie die deze Statistieken kan verzamelen en over tijd kan weergeven)
    • In de analogie is dit die deze informatie verzamelt en ook onthoudt wanneer er wat gemeten is.
  • Horizontal Pod Autoscalers (vanaf hier HPAs genoemd): Kubernetes objecten die het aantal Pods van een applicatie kan opschalen op basis van het applicatie gebruik.
    • Dit zijn een soort micromanagers die op basis van de hiervoor gemeten data gaan bedenken hoe veel magazijn medewerkers er op dit moment nodig zijn om de vrachtwagens zo snel mogelijk leeg te maken.

Let op dat hier ook wel eens misbruik van gemaakt kan worden; als je geen maximum instelt in het aantal werknemers / pods wat je wilt gebruiken kan een kwaadwillen persoon ervoor zorgen dat je oneindig veel opschaalt, wat ervoor kan zorgen dat je enorm hoge kosten moet betalen. Voor dit doel is het slim om een maximum in te stellen voor hoe ver je opschaalt, zodat je geen onvoorziene kosten gaat maken.


Van vraag naar Ontwerp

Uitgerust met een solide kennisachtergrond begaf het team  zich naar de klantlocatie. Eenmaal ter plekke werd snel de scope van het project vastgesteld, waarbij de exacte vereisten en benodigde stappen helder werden gedefinieerd. Hierdoor ontstond al snel een duidelijk beeld van de te volgen koers. Bovendien verliep het samenwerken met de collega's van de klant vlot en aangenaam, wat de sfeer ten goede kwam.

Gedurende de dag werd intensief gewerkt aan het ontwerp, met als doel een snelle implementatie te bewerkstelligen. Echter, al in de beginfase stuitte het team op een afhankelijkheid: standaard konden Horizontal Pod Autoscalers (HPAs) enkel schalen op basis van CPU- en geheugengebruik, terwijl de klant specifiek wenste te schalen op basis van de lengte van de applicatiewachtrij. Aangezien het verwerken van de wachtrij een losstaand proces betrof met beperkte invloed op het CPU-gebruik, volstonden de standaardparameters niet. Derhalve werd besloten om te schalen op basis van de wachtrijlengte.

Om dit te bewerkstelligen, diende de applicatie ook metrics beschikbaar te stellen aan het Kubernetes-cluster, zodat de HPAs deze konden raadplegen. Hiervoor was de toevoeging van de Prometheus Adapter aan het Kubernetes-cluster noodzakelijk. Met het ontwerp reeds in een vergevorderd stadium, vond overleg plaats met de klant om de locatie van de Applicatie Metrics te bepalen, zodat alle benodigde elementen naadloos konden worden geïntegreerd.

Echter, de gepubliceerde metrics waren nog niet in een formaat dat door Prometheus kon worden geïnterpreteerd. Gelukkig bevond de product owner van het team zich ter plaatse, waardoor direct een verzoek kon worden ingediend om de Metrics van de applicatie geschikt te maken voor publicatie.

Van ontwerp naar implementatie: een naadloze overgang

Bij terugkomst op donderdag bleek dat de ontwikkelaars van de klant de benodigde aanpassingen hadden doorgevoerd. Hierdoor konden eindelijk de applicatie-specifieke statistieken worden geëxporteerd en gebruikt om de workload op te schalen. Desalniettemin was het een uitdaging om dit proces af te ronden, aangezien nog niet exact duidelijk was welke statistieken dienden te worden benut voor het schalen van de applicatie.

Uiteindelijk werd besloten om te schalen op basis van de geschatte resterende tijd. Dit bracht met zich mee dat bij het opschalen van het aantal worker pods, het aantal verwerkte berichten zou toenemen en de resterende verwerkingstijd zou afnemen. Aan het einde van de dag konden de resultaten van de inspanningen worden geëvalueerd: met behulp van Grafana werd waargenomen hoe de workload toenam en de tijd om berichten te verwerken afnam, totdat het maximale aantal worker pods werd bereikt. In geval van een te lange wachtrij zou Kubernetes automatisch het aantal worker pods opschalen, waarbij het aantal verwerkte berichten per seconde toenam en de resterende tijd verminderde.

Succesvolle implementatie

Het resultaat mocht er zijn: het systeem functioneerde uitstekend en het was verheugend te constateren dat het gewenste effect al binnen twee dagen werd bereikt. Hoewel het proces uitdagend was, heerste aan het einde van de rit voldoening over het feit dat de klant tevreden was met de oplossing. Voor het team was het tevens een bevredigende ervaring om een complexe opdracht met succes te volbrengen.

Wil je meer weten over schaalbaarheid van cloudomgevingen?

Neem contact op met cloud consultant Maurice om jouw case te bespreken.

Afspraak maken
Maurits B - LR
Maurits Beudeker Cloud consultant
Publicatiedatum: 16 mei 2024

Meer kennis, howto's en inzichten ter inspiratie