Waarom AKS?

Naast AKS biedt Azure ook andere containerplatformen zoals Azure Container Instance (ACI), Azure App Service (Web App for containers) en kun je containers bijvoorbeeld ook hosten met Azure Container Apps (ACA). Dus de vraag rijst, wanneer kies je voor AKS?

Azure Container Instance (ACI)

Azure Container Instance (ACI) wordt met name ingezet voor batch-taken, het automatisch uitvoeren van relatief kleine taken waarna de container automatisch stopt. ACI is minder geschikt voor 24 x 7 behoeftige scenario’s. ACI ondersteunt geen schaalbaarheid in de vorm van gerepliceerde images, geen automatische revisies, en heeft standaard geen statisch IP-adres.

Plus- en minpunten
+ Geschikt voor draaien van kleine/korte taken.
– Geen mogelijkheid voor schaalbaarheid in de vorm van gerepliceerde images

Azure App Service (Web App for containers)

Azure App Service is een Azure beheerd hosting omgeving met name bedoeld voor het draaien van websites en API’s. Behalve het direct deployen van code naar een App Service, is het ook mogelijk om de code in een container te verpakken en deze vervolgens in de app service te draaien. Net als ACI, is Azure App Service met name handig voor het draaien van ‘single’ containers zonder verdere container orchestratie, maar dan wel 24 x7 in tegenstelling tot ACI.

Plus- en minpunten
+ Geschikt voor single container applicaties en/of agents (24 x 7).
–  Geen container orchestratie mogelijkheid.

Azure Container Apps (ACA)

Azure Container Apps (ACA) is gebouwd ‘on top of’ AKS en gebaseerd op best practices van een AKS configuratie. Met ACA worden beheertaken, zoals benodigd bij AKS, volledig uit handen genomen. De configuratie keuzevrijheid is echter veel beperkter dan bij AKS, maar dat maakt ACA dan ook veel minder complex dan AKS. Voor ACA is geen Kubernetes kennis nodig, sterker nog er is geen toegang tot de Kubernetes API. ACA is, in tegenstelling tot ACI en Azure App Service, wel een container orchestration platform en is dan ook, net als AKS, zeer geschikt voor moderne applicaties met een microservices architectuur.  ACA, in tegenstelling tot AKS, ondersteunt op dit moment geen Windows containers. ACA ondersteunt automatische revisies, automatische schaling en load balancing tussen containers zonder complexe configuraties. Voor wat betreft monitoring zijn de opties voor ACA ook beperkter dan voor AKS. ACA ondersteunt bijvoorbeeld nog geen Azure container Insights.

ACA Netwerk

ACA gebruikt envoy proxy (as a service) voor binnenkomend http(s) verkeer. Bij AKS daarentegen wordt standaard geen (reverse) proxy geconfigureerd en dien je zelf een keuze te maken tussen een grote variëteit aan ingress controllers en configuraties (zie: Mastering Azure Kubernetes Services deel 3: AKS Netwerk)

ACA Messaging

ACA gebruikt dapr als distributed application runtime. Dapr op haar beurt ondersteunt inter applicatie communicatie via messaging op basis van publish en subscribe of service naar service calls op basis van http of gRPC (zie Dapr-integratie met Azure Container Apps).

ACA Scaling

Wanneer http verkeer naar container revisies stopt wordt door ACA het aantal replica’s automatisch naar nul geschaald, waardoor er geen compute resources meer draaien en je dus geen kosten meer hebt. Voor het schalen van niet http verkeer zoals dapr pub/sub wordt KEDA gebruikt. KEDA is een kubernetes native event driven autoscaler die je in staat stelt containers te schalen op basis van het aantal te processen events. De schaling configureer je met (custom) rules en is relatief eenvoudig waarvoor je geen KEDA kennis nodig hebt. Let op, net als bij Azure Functions en AKS is sprake van een ‘cold start’ voor het opstarten van een eerste container na terugschaling naar nul. Om dit tegen te gaan zet je het minimum aantal replicas op één. Ook kent ACA zogenaamde scaling limits waardoor je minder keuzes hebt in de te gebruiken en het aantal compute resources dan bij AKS. Wel heeft Microsoft naast het ACA consumption plan type, onlangs een dedicated plan type uitgebracht waarmee je aangepaste compute configraties met zogenaamde workload profiles kunt configureren.

Plus- en minpunten
+ Met name geschikt voor applicatie met een microservices architectuur.
+ Relatief eenvoudig te configureren in vergelijking tot AKS.
– Ondersteunt geen Windows containers.
– Beperkt in configuratiemogelijkheden.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is met name bedoeld voor het ontwikkelen van moderne applicaties gebaseerd op een microservices architectuur. AKS biedt meer configuratie flexibiliteit door onder andere de volledige toegang tot de kubernetes API. Dit brengt echter ook meer verantwoordelijkheid met zich mee. Toegang tot de kubernetes API is bijvoorbeeld standaard publiek en ook al configureer je het AKS platform met een AKS-managed Azure Entra-ID integratie, dan bestaat er standaard nog steeds een local admin account achterdeur toegang zonder auditing! Wanneer dit niet gewenst is moet deze standaard configuratie aangepast worden.

Kubernetes clusters zijn complex en ondanks het feit dat Microsoft met AKS een deel van deze complexiteit weg haalt, blijft het op een veilige manier uitrollen en beheren van een AKS cluster nog steeds behoorlijk complex. AKS beheerders zijn niet alleen verantwoordelijk voor cluster- en node pool- upgrades, maar dienen ook op de hoogte te zijn en blijven van de te configureren opties en de consequenties van gemaakte AKS architectuur keuzes. Voorbeelden zijn de keuze tussen public clusters, private clusters, clusters met API Server VNet-integratie, diverse ingress controller mogelijkheden, configuratie van de system nodepool, storage configuratie voor statefull applicaties, en monitoring opties. Developers op hun beurt dienen op de hoogte te zijn van het gebruik van namespaces, (automatische) schaling, service mesh architecturen, met bijbehorende verschillende soorten services en configuratie opties.

Plus- en minpunten
+ Met name geschikt voor applicatie met een microservices architectuur.
+ Ondersteunt Windows en Linux containers.
+ Veel configuratiemogelijkheden en keuzevrijheid voor aanvullende services.
– Veel configuratiemogelijkheden maakt AKS complex.
– Zelf verantwoordelijk voor upgrades.

Wanneer de keuze op AKS is gevallen lees dan verder, want deze blogserie gaat dieper in op AKS architectuur- en configuratiemogelijkheden. Voor algemene basiskennis van AKS zie AKS Core Concepts

Lees verder:

Mastering Azure Kubernetes Services deel 2: Aantal AKS clusters