Horizontal Pod Autoscaling (HPA), Resource planning & Node Affinity

In een Kubernetes-omgeving is het essentieel om goed om te gaan met resources om ervoor te zorgen dat jouw applicaties efficiënt en betrouwbaar draaien. Maar hoe kun je er nu voor zorgen dat jouw workload altijd genoeg resources heeft, zonder onnodig te betalen voor te veel resources? Maak kennis met de Horizontal Pod Autoscaler (HPA), een feature van Kubernetes die het mogelijk maakt om automatisch de resources toe te wijzen aan je workload, afhankelijk van de belasting. In deze blog leer je niet alleen hoe je de HPA kunt instellen, maar ook hoe je node affinity kunt gebruiken om jouw pods over verschillende regio's te verdelen.

Beluister hier de aflevering:

Resources planning

te zorgen dat de pods op de juiste nodes worden geplaatst, zijn er resource requests, waarmee je aangeeft welke resources minimaal vrij moeten zijn op een node voordat de container wordt gestart. Dit brengt meer balans in het cluster. Limits kunnen ook worden gebruikt om aan te geven hoeveel resources een pod maximaal mag gebruiken. Bij een gebrek aan geheugen in de node zal de Out Of Memory Killer (OOMKiller) het proces stoppen, wat ervoor kan zorgen dat de pod opnieuw wordt opgestart. Het is dus belangrijk om de juiste limieten te zetten en de applicatie te monitoren om deze optimaliseren. Kubernetes zal een pod verplaatsen naar een andere node als de node vol is, wat kan resulteren in evicted pods. Het is belangrijk om het schrijven van bestanden in de container te minimaliseren en binnen de limieten te blijven.

HPA

Als je wel eens met Kubernetes hebt gewerkt, heb je vast wel eens gehoord van de Horizontal Pod Autoscaler (HPA). Maar wat is het precies en hoe kun je het gebruiken? Stel je voor, je hebt een webwinkel waarbij de verkoop van sokken in de winter sterk toeneemt. Ook zijn er drukke tijden gedurende de dag. Om de klanten zo goed mogelijk van dienst te zijn, heb je meer resources nodig. Aan de andere kant wil je wel zorgen dat je nog winst maakt. Hier komt de HPA goed van pas.

De HPA is een feature van Kubernetes waarmee je automatisch meer resources kunt toewijzen aan je workload, bijvoorbeeld bij drukke periodes in de webwinkel. Wanneer het weer rustiger wordt, kan de HPA de resources weer teruggeven. Hierdoor kun je de workload efficiënt en kosteneffectief beheren.

Bij horizontaal schalen voeg je extra replica's toe aan je workload, terwijl bij verticaal schalen je de bestaande replica's voorziet van meer geheugen en CPU. In Kubernetes kun je alleen horizontaal schalen, maar er is wel een verticale autoscaler als add-on beschikbaar.

Het instellen van de HPA is eenvoudig: je geeft een CPU-percentage op en een minimale en maximale pod count. De HPA houdt de CPU-belasting van de pod in de gaten en past de deployment aan met meer containers wanneer nodig. Je kunt ook een eigen metric aanmaken voor het autoscalen, maar de HPA werkt altijd met percentages. Om te voorkomen dat de autoscaler te snel op- en afschaalt, kun je een stabilization window instellen. Het uitrollen van een nieuwe versie van de deployment is geen probleem wanneer deze in een HPA zit. De deployment zal rekening houden met de autoscaler en deze op de juiste manier toewijzen.

Node Affinity

Een klant wil graag dat zijn pods over verschillende regio's actief zijn, waarbij er sprake is van zowel Windows- als Linux-containers en de applicatie niet uitvalt bij het uitvallen van één regio. Binnen Kubernetes is dit op te lossen met een gemixed cluster, waarbij je met labels werkt. Alles binnen Kubernetes heeft namelijk een label, wat key-value gerelateerd is. Zo kun je pods vastzetten op nodes en kun je gebruikmaken van affinity en anti-affinity. Voor Windows OS heb je al een label, maar voor andere zaken kun je een eigen label aanmaken, bijvoorbeeld om een pod op een bepaalde node te laten landen. Hierbij heb je de opties RequiredDuringSchedulingIgnoredDuringExecution en PreferredDuringSchedulingIgnoredDuringExecution om aan te geven op welke node de pod moet worden gestart. Daarnaast is er ook NodeAffinity, waarmee je kunt bepalen welke nodes een pod juist niet mag hebben. Ten slotte kan je ook met topologySpreadContraints aangeven hoeveel pods er bij elkaar mogen staan op één node en met de optie NodeName geef je aan op welke node de pod gestart moet worden. Echter, deze optie is niet handig bij de node namen in de cloud, die vaak niet hetzelfde zijn en kunnen veranderen.

‍