AKS Platform: Using the Cluster¶
This page is for workload teams: how you get access, where your application runs, how it reaches Azure services and what the platform expects of your deployments.
Reference design, your deployment may differ
Namespace and group names follow the reference configuration (team-a stands for your team). Your platform team gives
you the real names, the cluster addresses and the intake channel (<support channel>).
What you get¶
| Item | Detail |
|---|---|
| Namespaces | One per environment: <team>-dev, <team>-test, <team>-accp on the non-production cluster and <team>-prod on the production cluster |
| Access groups | A leads group and a developers group per team and cluster, in Entra ID |
| Quota and defaults | A resource quota, a limit range and a default-deny network policy per namespace (Security policy) |
| Ingress | A shared gateway. You bring a route (Expose your application) |
| Azure access | A workload identity per application, with only the roles you need |
| Secrets | A Key Vault of the platform, reached through workload identity |
Request an onboarding¶
Ask the platform team through your intake channel (Request a change describes the generic flow). Tell them:
- the team name and the environments you need;
- who the team leads are (they can add members to the groups);
- the applications that need an Azure identity, with namespace, service account name and the Azure roles they need (for example Key Vault Secrets User on one Key Vault);
- the data classification and cost centre of the namespaces (the design makes labels for these mandatory).
The platform team adds the groups and identities in Terraform and the namespace, quota and role bindings in the GitOps repository.
Access to the cluster¶
| Role | Dev and test | Acceptance | Production |
|---|---|---|---|
| Developer | Deploy and debug (namespace-developer) |
View and read logs | View and read logs |
| Team lead | Full namespace management | Full namespace management | Deploy and debug |
You sign in with Entra ID (MFA). There are no local accounts and no shared kubeconfig credentials. Use the Azure CLI and
kubelogin to get credentials for the cluster. The API server has no public endpoint, so you reach it from a network that
can route to the spoke (a private network path, VPN or a self-hosted agent). Production is changed through GitOps only. Break-glass
access is for the platform team and is time-limited (Identity and access).
Group membership is managed by your team leads or your identity team. Roles that give more access are activated in PIM where your platform requires it (Access, groups and PIM).
Deploy your application¶
Applications are deployed with GitOps. The reference setup has an application GitOps repository with a shared generic-app
Helm chart and one values file per team, application and environment. Argo CD syncs the values to the cluster, prunes removed
objects and reverts manual changes (selfHeal).
According to the load testing design, the chart gives these defaults, which you can override per application:
| Setting | Default of the chart |
|---|---|
| Autoscaling (HPA) | Minimum 2, maximum 10 replicas, CPU target 75%, memory target 80% |
| Resources | Requests 100m CPU and 128 MiB, limits 500m CPU and 256 MiB |
| Probes | Liveness /healthz, readiness /readyz |
| Disruption budget | Available, with minAvailable: 1 |
| Route | An HTTPRoute attached to the internal gateway |
Your pods must satisfy the pod security rules, or they are audited or blocked: no privileged containers, no host namespaces or
host paths, resource requests and limits, images from the approved registries, non-root user, dropped capabilities, seccomp
RuntimeDefault, and no latest tag in production (Security policy).
Kyverno can mutate some of these into your pods, but set them yourself.
Do not change the cluster by hand
A manual kubectl change to a managed object is reverted by Argo CD. The load test is the one deliberate exception: it
sets one environment variable that the Argo CD application ignores on purpose.
Expose your application¶
The platform team owns the gateway, the certificates and the load balancer. You own the route. This example is illustrative; the gateway name and namespace are those of the reference non-production cluster:
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
Do not use controller-specific annotations in your route, so the platform can replace the controller without changing your routes. The default-deny policy lets traffic in from the gateway namespace only. Calls from other namespaces need a network policy of your own.
Reach Azure services¶
Use workload identity, not stored credentials:
- Run the pod as the service account you named in the onboarding request. The platform team created the managed identity and its federated credential for exactly that namespace and service account.
- Ask the platform team for the client ID of the managed identity and for the service account annotation and pod label that your cluster version expects for workload identity.
- In the application, use
DefaultAzureCredentialorManagedIdentityCredentialfrom the Azure SDK and read the Key Vault directly.
A Key Vault is reachable only through its private endpoint. Egress to private endpoints is allowed by the default network policies on ports 443, 5432 and 6379. Other egress needs a network policy and, where a firewall controls egress, a firewall rule (Firewall rules and IP groups).
Workload identities are per application and per environment. An application in test cannot use the identity of prod.
Capacity and limits¶
| Limit | Where it comes from |
|---|---|
| Namespace quota (CPU, memory, pods, services, volume claims, secrets, config maps) | The namespace baseline |
| Maximum per container 4 CPU and 8 GiB | Limit range |
| Cluster maximum | Node pool maximum of the cluster (Cluster baseline) |
| Non-production availability | The non-production cluster may be stopped outside office hours (Operations) |
| Persistent volume backup | Not provided by the platform. Plan it with the platform team before you store data |
Alerts and on-call¶
The platform team receives alerts about the platform. Alerts about your application are yours: define your own rules and routes for your team. See Operate your workload.