====== 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.

===== Limit, Request en Usage in OpenShift=====

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. 


== Een voorbeeld ==

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.

===== Wat we hieraan kunnen doen =====

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. 
{{:chp:handleiding:pasted:20220425-111220.png?maxwidth=1000}}

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.

===== De Cluster Resource Override Operator =====

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.

== Een voorbeeld ==
 
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.


===== Vragen of hulp =====

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.