AKS-platform: het cluster gebruiken¶
Deze pagina is voor workload teams: hoe je toegang krijgt, waar je applicatie draait, hoe die Azure-services bereikt en wat het platform van je deployments verwacht.
Referentieontwerp, jouw deployment kan afwijken
Namen van namespaces en groepen volgen de referentieconfiguratie (team-a staat voor jouw team). Je platformteam geeft je
de echte namen, de clusteradressen en het intakekanaal (<support channel>).
Wat je krijgt¶
| Onderdeel | Detail |
|---|---|
| Namespaces | Eén per omgeving: <team>-dev, <team>-test, <team>-accp op het non-productiecluster en <team>-prod op het productiecluster |
| Toegangsgroepen | Een leads-groep en een developers-groep per team en cluster, in Entra ID |
| Quota en standaardwaarden | Een resource quota, een limit range en een default-deny network policy per namespace (Security policy) |
| Ingress | Een gedeelde gateway. Jij levert een route (Je applicatie beschikbaar maken) |
| Azure-toegang | Een workload identity per applicatie, met alleen de rollen die je nodig hebt |
| Secrets | Een Key Vault van het platform, bereikt via workload identity |
Een onboarding aanvragen¶
Vraag het aan bij het platformteam via je intakekanaal (Een wijziging aanvragen beschrijft de algemene werkwijze). Vertel ze:
- de teamnaam en de omgevingen die je nodig hebt;
- wie de teamleads zijn (zij kunnen leden aan de groepen toevoegen);
- de applicaties die een Azure identity nodig hebben, met namespace, naam van het service account en de Azure-rollen die ze nodig hebben (bijvoorbeeld Key Vault Secrets User op één Key Vault);
- de dataclassificatie en de kostenplaats van de namespaces (het ontwerp maakt labels hiervoor verplicht).
Het platformteam voegt de groepen en identities toe in Terraform en de namespace, quota en role bindings in de GitOps- repository.
Toegang tot het cluster¶
| Rol | Dev en test | Acceptatie | Productie |
|---|---|---|---|
| Developer | Deployen en debuggen (namespace-developer) |
Bekijken en logs lezen | Bekijken en logs lezen |
| Teamlead | Volledig namespacebeheer | Volledig namespacebeheer | Deployen en debuggen |
Je meldt je aan met Entra ID (MFA). Er zijn geen lokale accounts en geen gedeelde kubeconfig-credentials. Gebruik de Azure CLI en
kubelogin om credentials voor het cluster op te halen. De API server heeft geen publiek endpoint, dus je bereikt hem vanaf een netwerk dat
naar de spoke kan routeren (een privénetwerkpad, VPN of een self-hosted agent). Productie wordt alleen via GitOps gewijzigd. Break-glass-
toegang is voor het platformteam en is tijdgebonden (Identiteit en toegang).
Groepslidmaatschap wordt beheerd door je teamleads of je identityteam. Rollen met meer toegang worden geactiveerd in PIM waar je platform dat vereist (Toegang, groepen en PIM).
Je applicatie deployen¶
Applicaties worden gedeployd met GitOps. De referentieopzet heeft een GitOps-repository voor applicaties met een gedeelde generic-app
Helm chart en één values-bestand per team, applicatie en omgeving. Argo CD synct de values naar het cluster, verwijdert objecten
die zijn weggehaald en draait handmatige wijzigingen terug (selfHeal).
Volgens het loadtestontwerp geeft de chart deze standaardwaarden, die je per applicatie kunt overschrijven:
| Instelling | Standaard van de chart |
|---|---|
| Autoscaling (HPA) | Minimaal 2, maximaal 10 replicas, CPU-target 75%, geheugentarget 80% |
| Resources | Requests 100m CPU en 128 MiB, limits 500m CPU en 256 MiB |
| Probes | Liveness /healthz, readiness /readyz |
| Disruption budget | Beschikbaar, met minAvailable: 1 |
| Route | Een HTTPRoute gekoppeld aan de interne gateway |
Je pods moeten voldoen aan de pod security-regels, anders worden ze geaudit of geblokkeerd: geen privileged containers, geen host namespaces of
host paths, resource requests en limits, images uit de goedgekeurde registries, niet-root gebruiker, verwijderde capabilities, seccomp
RuntimeDefault en geen latest tag in productie (Security policy).
Kyverno kan een deel hiervan in je pods muteren, maar stel ze zelf in.
Wijzig het cluster niet handmatig
Een handmatige kubectl-wijziging aan een beheerd object wordt door Argo CD teruggedraaid. De loadtest is de ene bewuste uitzondering: die
zet één omgevingsvariabele die de Argo CD-applicatie met opzet negeert.
Je applicatie beschikbaar maken¶
Het platformteam beheert de gateway, de certificaten en de load balancer. Jij beheert de route. Dit voorbeeld is ter illustratie; de gatewaynaam en namespace zijn die van het referentiecluster voor non-productie:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: orders-api
namespace: team-a-dev
spec:
parentRefs:
- name: internal-shared-gateway
namespace: gateway-system
hostnames:
- orders.apps.internal.nonprod.example.com
rules:
- backendRefs:
- name: orders-api
port: 80
Gebruik geen controllerspecifieke annotaties in je route, zodat het platform de controller kan vervangen zonder je routes te wijzigen. De default-deny policy laat alleen verkeer toe vanuit de gateway-namespace. Aanroepen vanuit andere namespaces hebben een eigen network policy nodig.
Azure-services bereiken¶
Gebruik workload identity, geen opgeslagen credentials:
- Draai de pod als het service account dat je in de onboardingaanvraag hebt genoemd. Het platformteam heeft de managed identity en zijn federated credential precies voor die namespace en dat service account aangemaakt.
- Vraag het platformteam om de client-ID van de managed identity en om de annotatie op het service account en het pod-label die jouw clusterversie voor workload identity verwacht.
- Gebruik in de applicatie
DefaultAzureCredentialofManagedIdentityCredentialuit de Azure SDK en lees de Key Vault direct.
Een Key Vault is alleen bereikbaar via zijn private endpoint. Egress naar private endpoints wordt door de standaard network policies toegestaan op poort 443, 5432 en 6379. Andere egress heeft een network policy nodig en, waar een firewall egress regelt, een firewallregel (Firewallregels en IP-groepen).
Workload identities gelden per applicatie en per omgeving. Een applicatie in test kan de identity van prod niet gebruiken.
Capaciteit en limieten¶
| Limiet | Waar het vandaan komt |
|---|---|
| Namespace quota (CPU, geheugen, pods, services, volume claims, secrets, config maps) | De namespace baseline |
| Maximaal 4 CPU en 8 GiB per container | Limit range |
| Cluster maximum | Maximum van de node pool van het cluster (Cluster baseline) |
| Beschikbaarheid non-productie | Het non-productiecluster kan buiten kantooruren worden gestopt (Operations) |
| Back-up van persistent volumes | Niet geleverd door het platform. Plan het met het platformteam voordat je data opslaat |
Alerts en on-call¶
Het platformteam ontvangt alerts over het platform. Alerts over je applicatie zijn van jou: definieer je eigen regels en routes voor je team. Zie Je workload beheren.