Hoe ik mijn OpenShift kosten en resources omlaag kan brengen

In de afgelopen periode hebben we bij Hosting & Streaming gezien dat we met enige regelmaat nodes hebben moeten bijschalen in het OpenShift Cluster omdat we vanuit OpenShift en vanuit de afnemers de melding hebben gekregen dat Pods niet konden worden gestart omdat er een tekort zou zijn aan beschikbare CPU in het cluster.

Dit is enigszins opmerkelijk omdat het cluster op dit moment ongeveer 30% van het totale beschikbare CPU daadwerkelijk in gebruik heeft.

In OpenShift zien we de CPU resources op 3 manier:

• Limit
• Request
• Usage

De Limit is hier de maximale CPU die een Pod mag gebruiken. OpenShift zal het CPU gebruik gaan limiteren wanneer deze waarde is bereikt.

De Usage is de CPU dat een Pod daadwerkelijk in gebruik heeft op dat moment.

De Request speelt de belangrijkste rol. OpenShift zal de hoeveelheid CPU wat er met het Request wordt aangevraagd willen garanderen aan de Pod. Dat betekend dat er een flinke discrepantie kan zitten tussen de CPU wat wordt aangevraagd voor de Pod en wat er daadwerkelijk in gebruik is.

Stel er draait een Deployment vanuit waar een Pod wordt gestart die een CPU request doet van 500 milicore. Onze nodes hebben effectief maximaal 3000 milicore (3 cores) beschikbaar. Dat betekend dat er op deze node maximaal 6 van deze Pods opgestart kan worden.

Als deze pods nou daadwerkelijk maar een 100 milicore CPU verbruiken, dan betekend het dus dat er per Pod 400 milicore aan CPU niet meer ingezet kan worden voor andere Pods. Dat betekend dat in dit voorbeeld in totaal 2400 milicore (2,4 core) aan CPU verspilt wordt.

Het instellen van de CPU requests kan dus efficiënter. Het indelen hiervan zal voornamelijk liggen bij de developers van de applicaties.

Op applicaties waar geen requests worden ingesteld zal automatisch een default worden ingesteld, deze is voor zowel de Request als de Limit hetzelfde:

• Default CPU: 200m
• Default Memory: 128Mi

Ons advies en dringende verzoek is dan ook om goed te kijken naar de applicaties; hoeveel Requests deze heeft ingesteld en hoeveel hiervan daadwerkelijk in gebruik is (Usage). In OpenShift is dit per Project mooi in te zien door in de “Developers” view naar “Observe” te gaan, en hier te kijken naar het daadwerkelijke CPU gebruik.

Vervolgens kan je het CPU Request aanpassen naar een waarde die dichterbij het daadwerkelijke gebruik ligt, zonder de Limit aan te passen. Op deze manier zal de Pod net zoveel CPU beschikbaar hebben alleen zal er minder gegarandeerde CPU beschikbaar zijn.

Daarnaast is er nog een speler in het spel: de “Cluster Resource Override Operator”. Dit is een tool die we hebben draaien om de CPU Requests een beetje in toom te houden.

Deze Operator kijkt naar de Limit die op een Pod staat en zal de Request op de Pod aanpassen naar 25% van de Limit.

we hebben een Pod die met een Limit van 800 milicore wordt gestart, de Operator zal dan de Requests van de Pod aanpassen naar 200 milicore. Ongeacht de eventueel eerder ingestelde waarde. Dat zou dus betekenen dat wanneer er op de Pod door de developers een waarde van 50 milicore CPU is ingesteld als Request, dat ook deze wordt overschreven naar 200 milicore.

Deze functionaliteit kunnen we per Project uitzetten en dat zullen we dan ook in overleg doen. We willen dus de komende tijd het gesprek aan gaan met de afnemers van het cluster om de Requests te optimaliseren zodat we deze operator kunnen uitschakelen en meer Pods op dezelfde node kunnen laten draaien. Op deze manier willen we efficiënter met ons Cluster en haar resources om gaan, wat ook flink gaat schelen in de kosten.

Mocht je naar aanleiding van bovenstaande informatie nog vragen hebben, vraag ze dan gerust in het #openshift kanaal in slack. Heb je hulp nodig, schiet dan een ticket in via https://support.npohosting.nl.