Blog

Mijn node crasht. Wat zou de oorzaak hiervan kunnen zijn?

Bij één van onze klanten deden zich 3 incidenten voor op node 3 of node 4 in het cluster, zie figuur 1. De klant maakt gebruik van 2 control planes en 4 worker nodes, elk met 16 GiB aan geheugen. Deze incidenten resulteerden allemaal in een OOM of een herstart van de onderliggende host-machine. In deze blogpost leggen we uit hoe we, met behulp van Observe (beschikbaar voor al onze klanten maar ook apart verkrijgbaar), hebben vastgesteld waar de oorzaak lag en hoe we dit probleem in de toekomst kunnen voorkomen.

Als je na het lezen van het artikel overspoeld wordt door data of niet goed weet hoe je met al deze metrics moet omgaan, neem dan contact op met SRE!

Figuur 1. Node 3 en Node 4 error melding status Critical Load.

Waarom gebruiken we Observe?

Op de markt zijn er diverse trend monitoring systemen beschikbaar, misschien krijg je standaard een basis trendmonitoring bij je hostingpakket. Niet elke monitoring tool biedt echter de mogelijkheid om snel en nauwkeurig te zien welke nodes problemen veroorzaken, en heeft beperkt inzicht in de configuratie van Usage, Request en Limits op Namespaces en Pods. Observe daarentegen biedt uitgebreidere informatie over hostnames, clusters, Namespaces en Pods, en biedt daarmee meer flexibiliteit. Het geeft inzicht in de status van Namespaces en Pods, inclusief de ingestelde Requests, Usage en Limits. Daarnaast kan je als gebruiker zelf alerts instellen.

Voor onze Cyso-klanten visualiseren we al hun data en statistieken in Observe, wat ons een uniform platform biedt. In Observe kan je precies zien waar problemen zijn ontstaan, waardoor gericht zoeken naar oplossingen eenvoudiger en sneller gaat. Dit stelt zowel onze klanten als onze supportafdeling in staat om potentiële problemen vroegtijdig te signaleren en op te lossen, nog voordat gebruikers daar hinder van ondervinden. Hierdoor kunnen applicaties blijven draaien terwijl eventuele problemen worden aangepakt. Bij Cyso kunnen we meedenken over de dashboards die kunnen worden opgebouwd op basis van de geconfigureerde metrics. Zo heb je niet alleen een plek om je gegevens op te slaan, maar kunnen we Observe optimaal benutten.

Onderzoek

Bij een incident van het type OOM (Out Of Memory) ontvang je een alert van ons via e-mail en in MyCyso. Hierin wordt vermeld op welke node(s) het incident plaatsvindt en wat er is gebeurd. Bij het raadplegen van Observe zien we direct dat de beschikbaarheid in de afgelopen 30 dagen aanzienlijk is gedaald in vergelijking met de vorige maand, zoals te zien is in figuur 2. De beschikbaarheid bevindt zich momenteel in de rode zone, terwijl we streven naar een uptime van 99,9%. Dit wijst erop dat er mogelijk meer aan de hand is en is een indicatie voor Cyso-engineers om een onderzoek op te starten.

 

Figuur 2. Dashboards / Endpoint availability / Availability endpoints percentages history 30 days. Je ziet dat de beschikbaarheid aan het afnemen is.

 

Vervolgens kun je kijken naar de momentopname rond het tijdstip van het incident, zoals te zien is in figuur 3. Het overzicht van het gehele cluster kan worden gebruikt om in te zoomen, te downdrillen, op een specifieke node, door middel van het bekijken van het dashboard van die node, zoals getoond in figuur 4. Wanneer je weet om welke node het gaat, kun je de informatie van de incidentmelding correleren met de tijdopname van die specifieke node. Op deze manier hebben we ontdekt dat de workloads van de klant op node 3 en 4 waren toegenomen en dat de Limits en Requests opnieuw moesten worden beoordeeld.

 

Figuur 3. Dashboards / Kubernetes / Compute Resources / Node (Pods). In het cluster overzicht kan je goed het OOM moment zien.

De oplossing

Met behulp van het Simplified Dashboard kun je zien hoeveel resources er daadwerkelijk worden gebruikt en hoeveel er zijn aangevraagd, zie figuur 4. Je kunt vervolgens voor elke Namespace de Resources, Requests en Limits bekijken en deze informatie correleren met je deployments. Het is een Best Practice om op de juiste wijze overal Requests en Limits toe te passen.

 

Figuur 4. Dashboards / Kubernetes / Compute Resources / Simplified / Cluster. Memory Request waarbij alle kolommen zijn ingevuld.

 


Hoe hoort je Quota, van bijvoorbeeld Memory of CPU, ingeregeld te zijn?

In Kubernetes kunnen verschillende aspecten worden onderscheiden op basis van Namespace, deployment en Pod. Dit omvat Usage, Requests en Limits. “Usage” geeft het daadwerkelijke gebruik weer, “Requests” vertegenwoordigt de verwachte vraag, en “Limits” zijn de maximale toegestane capaciteit. Je kunt dit visualiseren als een bakje, de Namespace, binnen het grotere cluster. Dit bakje is verdeeld over verschillende nodes maar is niet direct gekoppeld aan één specifieke node.

Requests en Limits:

    • Resource Requests: Dit definieert de minimale gegarandeerde resources voor een container. Kubernetes gebruikt dit om te bepalen waar een pod op een node kan worden gepland. Als een node voldoende middelen heeft om aan de requests van een pod te voldoen, kan deze op die node worden gepland.
    • Resource Limits: Dit definieert de maximale toegestane resources voor een container. Dit helpt voorkomen dat containers meer resources gebruiken dan bedoeld, waardoor wordt gewaarborgd dat geen enkele workload de volledige node in beslag neemt.

Stel je voor dat je de Requests instelt op 20 appels. Het bakje kan meer dan 20 appels bevatten, mits er geen limiet is ingesteld. Zonder limiet kan het aantal appels in principe oneindig blijven groeien. Als je echter een limiet instelt, bijvoorbeeld op 80 appels, zal er een deksel op het bakje komen zodra deze limiet is bereikt. Er kunnen dan nooit meer dan 80 appels in het bakje komen.

Daarnaast kan Kubernetes op bepaalde manieren vergeleken worden met het spel Tetris. De limits fungeren als het maximale formaat van de Tetris-blokken die in het “speelveld” van de node passen. Wanneer de limieten hoger zijn dan de capaciteit van het cluster, kunnen deze niet geplaatst worden. Op een cluster heb je bijvoorbeeld een grid (node) van 8 bij 8 en een workload (Request) kan een vakje van 2 bij 2 in beslag nemen. Je kunt dit 4 keer doen en dan is het grid vol. Dit wordt gedefinieerd met Limits. Met de limiet geef je aan dat het blokje wat je nu in dat grid plaatst 1 bij 1 is (Request), maar het mag maximaal groeien tot 4 bij 4 (Limit). Als je de limiet niet instelt, kan het blokje van 1 bij 1 het volledige grid van 8 bij 8 innemen en is de capaciteit bereikt. 

Bij CPU-resources leidt een overschrijding van het bakje, zonder limiet, niet tot een incident, maar de prestaties van de applicatie nemen wel af doordat het bijvoorbeeld trager wordt. Voor het geheugen is dit echter anders. Als het bakje overstroomt, kan dit resulteren in een crash van de node. Dit kan leiden tot dataverlies en verminderde beschikbaarheid van je applicatie doordat nodes uitvallen.

Impact van het niet instellen van Limits:

Als je alleen Requests instelt zonder Limits, kan een container meer middelen gebruiken dan zijn aangevraagde hoeveelheid. Dit kan leiden tot:

    • Resource Concurrentie: Een container zonder limits kan meer CPU of geheugen verbruiken, waardoor andere containers op de node worden beïnvloed.
    • Node Instabiliteit: Als een container buitensporige middelen verbruikt, kan dit ertoe leiden dat andere containers worden verwijderd of zelfs dat de node onstabiel wordt (OOM).

Daarom is het cruciaal dat het Memory Usage niet hoger is dan het Memory Request. Als de Usage hoger is dan de Request en er is geen Limit ingesteld, kan de Namespace blijven groeien totdat het systeem crasht. Als er geen limiet is ingesteld, is het verstandig om dit alsnog te doen om de stabiliteit van je applicatie te waarborgen.

Wanneer een Namespace met een ingestelde limiet zijn capaciteit heeft bereikt, wordt er gekeken of de pods in andere namespaces kunnen worden ondergebracht. Als alle namespaces vol zijn en er dus te veel workloads op een server zitten, kunnen de workloads niet worden geplaatst. Als er niet op tijd wordt geschaald en er geen ruimte meer is, kan Kubernetes die workload niet plaatsen en dan krijg je een error event in je cluster event log. De melding geeft aan dat de workload niet plaatsbaar is omdat er geen/niet genoeg Resources beschikbaar zijn. Kubernetes zal blijven proberen de workload te plaatsen, maar zal tot die tijd een error blijven geven. 

Als alle Namespaces vol zijn, moet er ofwel een nieuwe node worden toegevoegd, of moeten de bestaande deployments efficiënter worden geconfigureerd. Het is belangrijk om direct de juiste Limits en Resources toe te passen door horizontaal of verticaal te schalen. Zolang er geen Limits en Resources ingesteld zijn, zal je uiteindelijk oneindig moeten blijven schalen. Het schalen is echter geen oplossing, het is tijdelijk een soort ademruimte geven om de Resources, Requests en Limits af te dwingen. Daarnaast is schalen altijd duurder dan preventie, dus dit gedrag wil je koste wat het kost voorkomen. Als dat niet gebeurt, is het niet de vraag of het systeem omvalt, maar wanneer dat gaat gebeuren.

 

Figuur 5. Dashboards / Kubernetes / Compute Resources / Simplified / Cluster. Doordat hier de Memory Limits kolom leeg is, is de kans groot dat hij gaat crashen.

 

In het Simplified / Memory / Namespace Overview is het mogelijk om de health status van de Namespaces te bekijken, zoals te zien is in figuur 6. Hieruit blijkt dat er een Namespace met een Memory Usage van 1700% is. Dit betekent dat er 17 keer meer Resources worden verbruikt dan oorspronkelijk verwacht/geconfigureerd (Request), zoals te lezen in vorige stuk ligt dat aan het ontbreken van het limiet. Hierdoor worden ze in het overzicht als rood aangeduid, wat betekent dat ze als ongezond worden beschouwd, ze zijn unhealthy. Bij de grijze blokken ontbreekt het Request en/of Limit en daardoor is er geen data beschikbaar. Dit zorgt ervoor dat Kubernetes niet goed weet hoe hiermee om te gaan. Groene blokken duiden op correcte instellingen zonder problemen (voorlopig). Het streven is om zoveel mogelijk groene blokken te hebben. Het is echter belangrijk om te weten dat het behalen van 100% groen lastig is, maar 95% haalbaar moet zijn. Wil je toch die laatste 5% behalen? Neem dan contact op met onze SRE afdeling. 

 

Figuur 6. Dashboards / Kubernetes / Compute Resources / Simplified / Memory / Namespaces.

 

Als je merkt dat een Namespace geen Limit heeft of meer Usage heeft dan Request, dan kun je de detailweergave bekijken van de Pods die zich in die Namespace bevinden, zie figuur 7 en 8. Je kunt controleren of zowel Limits als Resources zijn toegepast. Indien dit niet (overal) het geval is, is het raadzaam om de deployments anders te configureren. Na analyse van onze klant ontdekten we dat ongeveer 100 Pods/deployments waren waarbij de Resources en Limits niet correct waren ingesteld. Het is mogelijk dat bij tal van andere deployments een soortgelijke misconfiguratie voorkomt. Dit dient te worden gecorrigeerd om de stabiliteit van het platform/cluster te blijven optimaliseren. Probeer daarom zoveel mogelijk alle deployments te voorzien van (nieuwe) Limits en Requests, en controleer of de huidige deployments correct zijn geconfigureerd. Raadpleeg hiervoor de Kubernetes documentatie of lees de documentatie op de Observe website.

 

Figuur 7. Dashboards / Kubernetes / Compute Resources / Simplified / Memory / Pod. Hier zie je een correct afgestelde Pod.
Figuur 8. Dashboards / Kubernetes / Compute Resources / Simplified / Memory / Pod. Hier zie je een niet goed afgestelde Pod/deployment.

Conclusie

Kortom, door gebruik te maken van Observe Dashboards kun je goed inzicht krijgen in de knelpunten. Wanneer je een incidentmelding ontvangt, controleer dan allereerst of de beschikbaarheid afneemt. Daarna kun je naar het Cluster overzicht gaan om te kijken of er onbalans is in de verhoudingen. Vervolgens kun je inzoomen op specifieke Namespace en binnen die Namespace kijken naar de dimensies die niet (goed) zijn afgesteld. Op deze manier kun je ze correct corrigeren.

Met deze blog hopen we je inzicht en handvatten te bieden om grip te krijgen op de situatie. Als je nog hulp, vragen, behoefte aan meer informatie of voorbeelden nodig hebt, laat het ons dan weten. We helpen je graag bij het verbeteren van je platform!

Wil je op de hoogte blijven van de laatste ontwikkelingen op IT gebied. Meld je dan hier aan voor de nieuwsbrief.

Benieuwd naar de mogelijkheden? Let’s talk!

Cyso stories

25/06/2013

Auto Deploy met VMware en Chef – Inleiding

In dit artikel leggen wij uit hoe wij bij Cyso ervoor hebben gezorgd dat development van onze core applicaties op één platform staat.
4 trends voor cloud adoptie
05/05/2020

Vier trends die van invloed zijn op de adoptie van de cloud in 2020

4 Trends die invloed op de cloud adoptie hebben. De cloud kan een sneeuwbaleffect creëren voor de transformatie van organisaties.
08/03/2024

Voorkom reputatieschade met de Domein Monitor Service

Het beschermen van je merk tegen online bedreigingen is niet alleen een kwestie van veiligheid, maar ook van reputatiebehoud.

Interesse in een van onze diensten?

Wat is je vraag? Neem nu contact met ons op.

Wil je dat wij contact met jou opnemen? Laat je gegevens achter en wij bellen je terug.

Cyso contact