AKS Platform: servicebeschrijving¶

Deze pagina beschrijft wat het AKS Platform biedt, welke varianten er zijn, hoe wijzigingen verlopen en waar de grenzen liggen. De andere pagina's gaan dieper in op de details: Het cluster gebruiken, Securitypolicy, Architectuur en de pagina's waar die naar verwijzen.

Referentieontwerp, per platform ingesteld

De service wordt door het platformteam geleverd onder een overeenkomst (Beheermodellen). Supporturen, reactietijden, contactpersonen en tarieven maken deel uit van die overeenkomst en staan niet in deze documentatie. Waar een pagina een standaardwaarde noemt (een grootte, een venster, een retentie), is dat de waarde van de referentieconfiguratie. Jouw platform kan afwijken.

In het kort¶

Het platformteam bouwt en onderhoudt AKS-clusters als infrastructure as code met Terraform. Elk cluster krijgt dezelfde baseline: private API server, aanmelden alleen via Entra ID, workload identity, een vaste indeling van node pools, onderhoudsvensters en een baseline voor securitypolicy. Workload teams deployen in namespaces van die clusters en gebruiken het cluster via groepen en GitOps, niet via gedeelde credentials.

Wat wordt aangeboden¶

Gebied	Inbegrepen
Cluster	Eén AKS-cluster per omgeving (productie en niet-productie), met system en user node pools, autoscaling, availability zones in productie en onderhoudsvensters (Cluster baseline).
Netwerk	Een spoke met aparte subnets voor nodes, ingress, private endpoints en de API server. In de hub-integrated modus komt de spoke uit de hub en landing zone (Netwerk).
Toegang	Entra ID-groepen voor platformbeheerders, operators, auditors, break-glass en per team. Lokale Kubernetes-accounts staan uit (Identity en toegang).
Workload identity	Een user-assigned managed identity per applicatie en per omgeving, gefedereerd met een Kubernetes service account. Geen opgeslagen client secrets.
Secrets	Een Key Vault met RBAC-autorisatie, purge protection en zonder publieke toegang, bereikbaar via een private endpoint (Azure-variant).
Securitypolicy	Azure Policy voor Kubernetes, en Kyverno-policies, default-deny network policies en namespacequota uit de GitOps-repository (Securitypolicy).
Deployment	Terraform via pipelines met één state per platform en omgeving (Deployment).
Beheer	Geplande upgradevensters, een optioneel start- en stopschema voor niet-productie, een on-call-opzet in PagerDuty (Beheer).
Load testing	Een herhaalbare load test en alertvalidatie voor het niet-productiecluster (Load testing).

Varianten¶

Variant	Wat het is	Status in de bronnen
Azure, standalone	De oplossing bouwt een eigen spoke-VNet, subnets, route table en Private DNS zone. Egress loopt via de AKS load balancer.	Gedeployd in de referentieconfiguratie voor `nonprod` en `prod`.
Azure, hub-integrated	Het cluster gebruikt een spoke die de hub en landing zone hebben aangemaakt. Egress volgt de hub (user-defined routing). Private DNS zones komen uit de hub.	In code geïmplementeerd en gebruikt door een `nonprod-integrated`-omgeving. Het ontwerpdocument zegt nog "implementation pending".
Azure Local	AKS on Azure Local (AKS Arc). Het cluster wordt met de Azure CLI aangemaakt, Terraform beheert Arc-extensies, identity, policy en Key Vault.	Code en pipeline bestaan. In de gecommitte configuratie staat elke layer-schakelaar op `false`, dus wat is gedeployd is in de bronnen niet te zien.

Zie AKS on Azure Local voor de verschillen.

Hoe wijzigingen verlopen¶

Er zijn twee soorten wijzigingen, en ze volgen twee paden.

Azure-resources (cluster, netwerk, identities, Key Vault, Azure Policy): een wijziging van de Terraform-configuratie, gepland en toegepast door een pipelinerun (Deployment). Handmatige wijzigingen in de Azure-portal aan resources die Terraform beheert zijn drift en worden door de volgende run teruggedraaid.
Resources in het cluster (namespaces, RBAC-bindings, policies, quota, platformservices, applicaties): een pull request op een GitOps-repository. Argo CD past het toe. De Kubernetes-manifests die vroeger in de Terraform-repository stonden zijn deprecated en worden alleen als historie bewaard.

Typische standaardwijzigingen:

een team onboarden: Entra ID-groepen en namespaces, RBAC-bindings;
een workload identity voor een applicatie toevoegen, met zijn rol op een Key Vault;
een policy-uitzondering toevoegen (pull request met onderbouwing, gereviewd door het securityteam, met een einddatum);
de grootte van een node pool wijzigen of een user node pool toevoegen;
naar een nieuwe Kubernetes minor-versie gaan, eerst niet-productie.

Verantwoordelijkheden¶

	Platformteam	Workload team
Terraform-code, layers, cluster baseline, nieuwe versies	Ja
Kubernetes minor-upgrades en node image-upgrades	Ja	Test de applicatie na upgrades in niet-productie
Entra ID-groepen, proces voor groepslidmaatschap, Azure-roltoewijzingen	Ja	Vraagt aan, noemt de teamleads
Workload identity voor een applicatie	Maakt hem aan	Vraagt hem aan, gebruikt het service account in de applicatie
Namespaces, resource quota's, limit ranges, standaard network policies	Ja
Network policies van de applicatie bovenop de standaard	Reviewt	Schrijft ze
Kyverno- en Azure Policy-baseline, policy-uitzonderingen	Ja (het securityteam keurt uitzonderingen goed)	Vraagt uitzonderingen aan
Ingress gateway, certificaten, monitoringstack	Ja
Routes (`HTTPRoute`), applicatiedeployments en manifests		Ja
Container images, scanning, wat de applicatie met secrets doet		Ja
Alerts over de applicatie		Ja
Alerts over het platform en de on-call-respons	Ja
Break-glass-toegang en de review ervan	Ja

De algemene verdeling staat beschreven in Verantwoordelijkheden. Contractdetails zoals uren en reactietijden staan in je overeenkomst.

Grenzen¶

Geen onderdeel van de service	Waarom
Back-up van persistent volumes	Geen onderdeel van de cluster baseline. Het ontwerp stelt Azure Backup for AKS of Velero voor, gepland per workload.
Applicatieworkloads en hun data	Ze horen bij het workload team.
Een web application firewall	Niet opgenomen in het eerste ontwerp.
Defender for Containers	Uitgeschakeld in de referentieconfiguratie. Kan worden ingeschakeld, zie Securitypolicy.
Een firewall in de standalone modus	Het ontwerp beschrijft egress via Azure Firewall. De Terraform-code van de standalone modus deployt er geen. In de hub-integrated modus volgt egress de hub (Netwerk).
Azure Local-hardware, Arc Resource Bridge, custom location, logical network	Infrastructuurvoorwaarden van de Azure Local-variant, met een eigen lifecycle (Randvoorwaarden).
Wijzigingen die met de hand in het cluster zijn gedaan	In productie staat het ontwerp alleen GitOps-wijzigingen toe. Directe wijzigingen worden door Argo CD teruggedraaid.