Mastering Azure Kubernetes Services deel 2: Aantal AKS clusters

Aantal AKS Clusters

Een veel voorkomende vraag bij het inzetten van AKS luidt, hoeveel AKS clusters hebben we nodig?

Door gebruik te maken van logische scheidingen binnen een cluster met namespaces en permissies kun je theoretisch alle applicaties/workloads, inclusief otap op één AKS cluster hosten. Er bestaat echter een risico, ook al is dit risico minimaal, dat een kubernetes upgrade fout gaat. Ook kunnen componenten die veel directe interactie met de control plane hebben, zoals bijvoorbeeld Prometheus, verstoringen veroorzaken wanneer een dergelijke component een bug heeft. Daarom is het raadzaam om minimaal voor twee clusters te gaan, één voor ontwikkeling en één voor productie.

Figuur 1: Azure Regio met twee AKS clusters

Naast logische scheidingen binnen een cluster kun je ook fysieke scheidingen aanbrengen voor verschillende applicaties door gebruik te maken van meerdere node pools binnen een cluster of zelfs volledig gescheiden clusters. Dit voorkomt bijvoorbeeld issues met ‘noisy neighbours’, en kan noodzakelijk zijn in een multi-tenancy architectuur omdat het security domain van Kubernetes het gehele cluster is. Ook omdat de control plane gratis is en je (automatisch) compute resources terug kunt schalen of een compleet cluster kunt stoppen zijn meerdere gescheiden cluster niet per definitie nadelig. Wel zal het optimale gebruik van compute resources hiermee iets afnemen en de beheerlast toenemen, maar de complexiteit van de cluster configuratie juist weer afnemen.

Kortom, zoals zo vaak is er niet één antwoord op de vraag hoeveel AKS clusters in te zetten. Bedenk dat Kubernetes een complex hosting platform is met veel configuratiemogelijkheden. Zorg dat de gekozen opzet, met achterliggende beweegredenen goed vastgelegd wordt, door bijvoorbeeld gebruik te maken van architecture decision records (ADRs).

Beschikbaarheid en disaster recovery

Omdat een AKS cluster vaak meerdere workloads host, speelt de beschikbaarheid van AKS, en in geval van nood, de herstelmogelijkheid van AKS ,een belangrijke rol voor het up- en running houden van veel business processen (business continuity).

Service Level Agreement

De control plane is standaard high available (HA) en AKS kent een SLO (Service Level Objective) van 99,5% met de ‘free’ TIER. Met de standaard TIER geldt een SLA (Service Level Agreement) van 99,9% voor clusters zonder availability zones en 99,95% voor clusters met availability zones. Voor de standaard tier geldt een prijs per cluster per uur, naast de compute prijs voor de node pools. Ook met de free tier is het raadzaam availability zones te gebruiken voor de nodes. Availability zones zorgen voor gedistribueerde fysiek gescheiden nodes en storage, wat de beschikbaarheid, in geval van hardware fouten of gepland onderhoud, verhoogt. Let op, availability zones voor AKS kunnen alleen ingesteld worden tijdens het creëren van een AKS cluster of het creëren van node pools. Gebruik daarbij minimaal twee, idealiter drie nodes.

Beschikbaarheid tijdens upgrades

De verantwoordelijkheid voor het ‘upgraden’ van een AKS cluster ligt vaak bij een centraal AKS beheerteam. Met het upgraden van Kubernetes, upgrade je standaard de control plane , de system node pool (deze host system pods met ‘core’ componenten zoals CoreDNS) en user node pools.

Om workloads beschikbaar te houden tijdens Kubernetes upgrades gebruikt AKS zogenaamde buffer nodes met de nieuwe Kubernetes versie. Pods verhuizen naar de buffer node(s), waarna de vrijgekomen node het image met de nieuwere versie krijgt en de node vervolgens als volgende buffer node fungeert. Dit proces herhaalt zich totdat alle nodes zijn voorzien van de nieuwe image. Om het upgrade proces te optimaliseren en workloadonderbrekingen te minimaliseren zijn er configuratiemogelijkheden zoals ‘planned maintenance window’, ‘max surge’ en ‘pod disruption budget’.

Met een Kubernetes upgrade worden de nodes van de node pools van een nieuwe image versie voorzien met ook de laatste OS security patches. Daarnaast is het mogelijk handmatig danwel automatisch de control plane en individuele nodepools onafhankelijk van elkaar te upgraden/patchen. Zorg er dus voor dat AKS upgrade processen en bijbehorende configuraties geoptimaliseerd zijn en vastliggen voordat een AKS cluster in productie gaat.

Disaster Recovery

De benodigde beschikbaarheid van een AKS cluster is natuurlijk afhankelijk van de benodigde recover time objective (RTO) en recover point objective (RPO) van de op het cluster draaiende workload(s), waarbij de beschikbaarheid voor de workload niet alleen afhankelijk is van de beschikbaarheid van het cluster, maar ook van alle andere (azure) resources in de ‘keten’ van een workload.

Aangezien workload services draaiend op een AKS cluster, afgezien van potentieel benodigde  persistent volumes (PV), normaliter voor hun ‘state’ afhankelijk zijn van resources buiten het cluster, zoals bijvoorbeeld azure storage of azure database, speelt de RPO vanuit het cluster gezien een minder belangrijke rol en ligt de focus op de RTO. Voor de workload zelf is de RPO uiteraard belangrijk en moet de ‘state’ voldoende vaak gerepliceerd worden.

Een workload (micro) service bestaat uit één of meerdere images die vanuit een registry, bijvoorbeeld azure container registry (acr) geladen worden. Een image wordt ‘gebouwd’ met een dockerfile en uitgerold naar het cluster met een deployment (yaml) file. Een AKS cluster wordt vaak met infrastructure as code (IaC) zoals een bicep, of terraform file uitgerold. Al deze files voor het herstellen van de workload (micro) service en het AKS cluster staan in een repo van bijvoorbeeld Github of Azure DevOps die standaard multi region gerepliceerd wordt. Deze files vormen dus de backup, en de workloadservices, inclusief het AKS cluster zijn herstelbaar door middel van een redeployment.

Het opnieuw uitrollen van een AKS cluster neemt uiteraard tijd in beslag. Bij een laag vereiste RTO voor de workloads zullen meerdere nodepools of clusters, danwel in dezelfde regio, danwel in de standaard gekoppelde regio beschikbaar moeten zijn om de workloads te hosten en de load te verdelen. In algemene zin kun je stellen, hoe beter (lager) de vereiste RTO, hoe complexer en duurder de benodigde oplossing is, van single region single nodepool, naar single region multi nodepools, tot  multi-region multi nodepools.

Lees verder:

Mastering Azure Kubernetes Services deel 3: AKS Netwerk