Blog

Best practices voor het opzetten van een AKS cluster

Kubernetes is “hot & happening”, vrijwel iedereen wil er mee aan de slag. Het aanmaken van een AKS-cluster is zo gedaan, maar gaat dat ook zo makkelijk als je Kubernetes echt in productie wilt nemen? In dit artikel geven wij belangrijke tips en best-practices voor het opzetten en gebruiken van een AKS-productie omgeving.

Gepubliceerd: 16 februari 2024

Voordat je begint

Het aanmaken van een AKS-cluster is makkelijk en er zijn meer dan genoeg handleidingen online te vinden. Bijvoorbeeld de Microsoft handleidingen op https://docs.microsoft.com/en-us/azure/aks/ zijn volledig en altijd up-to-date. Maar er zijn er vier belangrijke keuzes die je zal moeten maken voordat je een productie cluster aanmaakt.

1. Het type VM

Kies een geschikte VM-size voor jouw Kubernetes cluster. Kubernetes zelf gebruikt ook geheugen voor het management van het cluster. Deze overhead is bij de kleinste VMs met 2Gb geheugen maar liefst 65%. Pas bij 64Gb geheugen is de overheid van Kubernetes lager dan 10%. Mijn advies is in de meeste gevallen om grote VMs te kiezen, maar wel altijd meer dan 1 VM.

Gelukkig is het tegenwoordig mogelijk om de VMs van een AKS-cluster te wijzigen, dit was voorheen niet mogelijk. Je kan dus beginnen met een iets kleinere VM en wanneer jouw cluster groeit de VMs vervangen door grotere exemplaren voor meer efficiency.

Voor meer informatie met betrekking tot VM-size en efficiency bekijk deze link.

Vergeet ook niet dat naast CPU en geheugen er ook een limiet is op het aantal disks en IOPS per type VM. Dit kan mogelijk een beperking zijn als je applicaties veel gebruik maken van storage. Grotere VMs hebben meer IOPS en hieraan kunnen meerdere disks gekoppeld worden.

2. Het netwerk model

Een AKS-cluster kent twee netwerk modellen, Basic en Advanced Networking. Ook het netwerk model is naderhand niet meer te wijzigen. Het Basic netwerk model is, zoals de naam al zegt, beperkt qua mogelijkheden. Zo zijn VPN verbindingen naar het cluster niet mogelijk en kan het cluster niet naar andere virtuele netwerken verbinden. Bij het Advanced Networking model is dit wel mogelijk maar moet je wel rekening houden met het gebruik van meer IP-adressen. Voor meer informatie hierover, bekijk deze link.

3. Aantal pods per node

Bij het Advanced Netwerk model (welke je waarschijnlijk wilt gebruiken) moet je van te voren het maximale aantal pods voor de VMs aangeven. Standaard is dit 110 pods per VM. Azure zal per VM dit aantal IP-adressen reserveren zodat elke pod een eigen IP-adres kan krijgen. Hier moet je netwerk wel groot genoeg voor zijn. Een /24 netwerk heeft maar 250 IP-adressen dus hier kan je maar 2 VMs in uitrollen. Maar… bij het updaten van een AKS-cluster vervangt AKS de VMs stuk voor stuk door nieuwe VMs, ook deze nieuwe VMs hebben de 110 IP-adressen nodig. Een /24 netwerk is dus maar groot genoeg voor één VM.

Dus kies een lager aantal pods per VM of een groot genoeg netwerk. Een /23 heeft 500 IP-adressen dus groot genoeg voor 3 VMs en een /22 heeft 1000 IP-adressen dus is groot genoeg voor 8 VMs. 

4. Kubernetes RBAC met Azure AD

Binnen Azure geldt het RBAC model, elke Azure AD gebruiker is gekoppeld aan een rol en heeft hierbij de rechten die door deze rol worden verstrekt. Vanuit Azure zijn er twee rollen in AKS, admin en user. De admin heeft volledige toegang tot het AKS-cluster, een normale user heeft alleen toegang tot de namespaces waar expliciet toegang tot gegeven is.

Maak gebruik van deze mogelijkheid en geef developers alleen de toegang die ze nodig hebben voor dagelijks gebruik, bijvoorbeeld de namespace van hun project. Gebruik het admin account alleen voor management van het cluster.

Bovenstaande keuzes zijn belangrijk voor het correct opzetten van een productie AKS-cluster. Echter, net als bij de rest van Azure komen er vrijwel dagelijks nieuwe features uit. Lees dan ook goed de volgende link voor de actuele best-practices voordat je een productie AKS-cluster opzet. Immers, enkele van deze features zijn alleen beschikbaar voor nieuwe cluster en kunnen niet naderhand toegevoegd worden.

 

Monitoring, weet wat er speelt

Monitoring is net als bij elke andere dienst van groot belang. Door AKS te koppelen aan Log Analytics zijn vanuit de portal alle logs en metrics direct inzichtelijk. Hiermee is het niet meer nodig om zelf een monitoring tool te installeren en beheren. Naast de visuele feedback kan Log Analytics met behulp van alerts afwijkend gedrag melden en zelfs ingrijpen. Voor alle informatie over het monitoren van AKS. Bekijk deze link

Grafiekjes, wie is er niet dol op:

 

Niet IaaS, niet PaaS maar KaaS

Een AKS-cluster is een combinatie van een IaaS en PaaS-dienst, zeg maar KaaS 🧀. Microsoft neemt de verantwoordelijkheid voor het Kubernetes cluster (PaaS), de onderliggende VMs (IaaS) is de verantwoordelijkheid van de gebruiker. Microsoft zal de updates voor de VMs wel installeren maar het daadwerkelijk rebooten en activeren van deze updates is aan de gebruiker. Gelukkig is hiervoor een prima oplossing beschikbaar in de vorm van Kured. Door Kured in het AKS-cluster te deployen en zal deze automatisch de nodes herstarten zodra dit noodzakelijk is. Zolang het cluster uit 3 of meer nodes bestaat gaat dit zonder downtime van de services, Kured zorgt hiervoor. Meer informatie over Kured is hier te vinden.

De werking van Kured, rebooten wanneer nodig: 

 

Resource limits en health probes

Als je een AKS-cluster in productie neemt is het van groot belang dat de verschillende workloads elkaar niet in de weg zitten. Hoe voorkom je bijvoorbeeld dat een collega een applicatie deployed die het hele AKS-cluster omvertrekt? Met quota’s en resource limits.

Een beheerder kan per namespace quota’s instellen op cpu, geheugen en aantal pods. Hiermee voorkom je dat een gebruiker het hele AKS-cluster voor zichzelf claimed. Door per pod een maximum cpu en geheugen in te stellen kan een developer voorkomen dat een pod alle toegekende resources verbruikt.

Microsoft heeft een prima handleiding met betrekking tot resoure requests en resource limits. 

Vergeet ook niet het toevoegen van ready en liveness probes. Deze zijn cruciaal voor Kubernetes om de status van de pods te bepalen. Zonder health probes kunnen gebruikers naar pods geleid worden die nog niet zijn opgestart of pods die zijn gecrashed. Health probes zijn een standaard element binnen Kubernetes.

 

En nu verder…

Heb je de bovenstaande tips gevolgd, dan heb je prima AKS-cluster om te beginnen met productie workloads. Er zijn nog vele andere features die van belang zijn voor het gebruik van Kubernetes in productie. Zeker qua beveiliging is er nog veel mogelijk.

Hou Microsoft goed in de gaten. AKS is continue in ontwikkeling en er komen regelmatig nieuwe features uit. Microsoft zet groots in op AKS en dat is te zien.