07/03/2016
Cyso behaalt ISO 20000 en NEN 7510 certificering
Cyso heeft de officiële certificeringen voor de ISO 20000 en NEN 7510 norm toegevoegd aan het reeds in bezit zijnde ISO 27001 certificaat.
Blog
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.
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.
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.
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.
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:
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:
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.
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!
