AKS-Plattform: Architektur¶

Diese Seite beschreibt das High-Level-Design: die layers, die Umgebungen, die Ressourcengruppen und wie die Varianten Azure und Azure Local eine gemeinsame Struktur teilen.

Referenzdesign

Das ist das Layout der Referenzkonfiguration. Deine Plattform kann andere Namen, CIDR-Bereiche, Größen oder Schalter verwenden.

Layers¶

Die Lösung ist in layers aufgebaut. Jeder layer ist ein Terraform module mit einem deploy_*-Schalter (der Networking-layer wird immer ausgewertet). Ein layer nutzt die Outputs der layers unter ihm, deshalb zählt die Reihenfolge beim ersten Deployment.

flowchart TB
    subgraph tf["Terraform (per platform and environment)"]
        net["Networking<br/>spoke, subnets, DNS, network profile"]
        idn["Identity<br/>Entra ID groups, managed identities,<br/>workload and CI/CD identities"]
        sec["Security policy<br/>Azure Policy, Defender, diagnostics, alerts"]
        cls["Cluster baseline<br/>AKS, node pools, maintenance, add-ons"]
        kv["Secrets<br/>Key Vault, private endpoint"]
    end
    subgraph gitops["GitOps repositories (Argo CD)"]
        ns["Namespaces, priority classes, RBAC"]
        pol["Kyverno policies, network policies, quotas"]
        svc["Platform services:<br/>ingress gateway, monitoring, certificates"]
        app["Applications"]
    end
    net --> cls
    idn --> cls
    net --> kv
    net --> sec
    cls --> gitops
    ns --> app
    pol --> app
    svc --> app

Layer	Terraform module (Azure)	Was er erstellt	Schalter
Networking	`modules/azure/networking`	Ressourcengruppe, VNet, vier Subnets, NSG, Route Table, Private DNS zone, öffentliche IP für Ingress (standalone); oder Data Lookups eines bestehenden spokes (hub-integrated). Berechnet außerdem das AKS network profile.	`network_mode`
Identity	`modules/azure/identity`	Ressourcengruppe, Entra-ID-Gruppen, Break-glass-Gruppe, Kubelet managed identity, Workload-Identitäten, CI/CD-Identitäten mit federated credentials, optionale Rollenzuweisungen	`deploy_identity`
Security policy	`modules/azure/security-policy`	Azure-Policy-Zuweisungen, Defender-for-Cloud-Pläne, Diagnoseeinstellungen, Security Alerts, Intervall des Image Cleaners	`deploy_security_policy`
Cluster baseline	`modules/azure/cluster-baseline`	Ressourcengruppe, AKS-Cluster, User Node Pools, Rollenzuweisungen der Cluster-Identitäten, optionale Diagnoseeinstellungen	`deploy_cluster_baseline`
Secrets	`modules/azure/secrets`	Ressourcengruppe, Key Vault, private endpoint, optionale Diagnoseeinstellungen	`deploy_key_vault`

Die Variante Azure Local hat unter modules/azure-local/ pro layer ein passendes module, mit kleinerem Umfang (AKS auf Azure Local). Gemeinsame Bausteine (Entra-ID-Gruppen, Break-glass, Identitäten, Rollenzuweisungen, Key Vault) liegen in modules/identity/ und modules/secrets/ und werden von beiden Varianten wiederverwendet.

Umgebungen und Cluster¶

Das Design betreibt zwei Cluster. Production-Workloads laufen nur auf dem Production-Cluster. Development, Test und Acceptance laufen gemeinsam auf dem Non-Production-Cluster, getrennt durch namespaces.

flowchart LR
    subgraph prod["Production cluster (aks-prod)"]
        pns["Namespaces per team:<br/>team-a-prod"]
    end
    subgraph nonprod["Non-production cluster (aks-nonprod)"]
        dns["team-a-dev"]
        tns["team-a-test"]
        ans["team-a-accp"]
    end
    pvnet["Production spoke"] --- prod
    nvnet["Non-production spoke"] --- nonprod

Wert für environment	Plattform	Netzwerkmodus	Cluster-Name in der Referenzkonfiguration
`prod`	`azure`	standalone	`aks-prod`
`nonprod`	`azure`	standalone	`aks-nonprod`
`nonprod-integrated`	`azure`	hub-integrated	`aks-nonprod-integrated`
`prod-integrated`	`azure`	hub-integrated	Der Selector existiert in der pipeline; keine Konfigurationsdatei in den Quellen
`nonprod`, `prod`	`azure-local`	Azure Local logical network	Wird von den pipeline-Variablen der Umgebung gesetzt

Die Gründe für zwei Cluster: Blast Radius, unabhängiger Upgrade-Lebenszyklus (zuerst Non-Production), unterschiedliche Zugriffsregeln (Entwickler bekommen außerhalb von Production weiter gefasste Rechte), Kosten und Netzwerktrennung. Die spokes sind nicht miteinander gepeert.

Jede Plattform und jede Umgebung hat eine eigene Konfigurationsdatei (config/<environment>.tfvars), eine eigene Backend-Datei (config/backend-<environment>.hcl) und damit ihren eigenen Terraform state.

Ressourcengruppen¶

Ressourcengruppe (Azure)	Inhalt
`rg-<env>-network`	Spoke VNet, Subnets, Route Table, Private DNS zone, öffentliche IP für Ingress (nur standalone)
`rg-<env>-identity`	Managed identities (Kubelet, Workload, CI/CD)
`rg-<env>-aks`	Der AKS-Cluster und seine User Node Pools
`rg-<env>-aks-nodes`	Von AKS verwaltete Node-Ressourcengruppe
`rg-<env>-secrets`	Key Vault und sein private endpoint
`rg-<env>-security`	Security Alerts, wenn aktiviert

Auf Azure Local bekommen die Gruppen für Identity, Secrets und Security das Suffix -arc (rg-<env>-identity-arc und so weiter). Die Ressourcengruppe des Clusters wird vom Bootstrap erstellt und in den pipeline-Variablen benannt.

Policy-Scope

In der Azure-Variante bekommt der Security-policy-layer die ID der Network-Ressourcengruppe als Scope seiner Azure-Policy-Zuweisungen (module.networking.spoke_resource_group_id), während der Cluster in rg-<env>-aks liegt. Azure Policy for Kubernetes gilt für Cluster innerhalb des zugewiesenen Scopes. Bestätige mit dem Plattform-Team, welcher Scope in deinem Deployment wirksam ist.

Namen und tags¶

Ressourcennamen folgen <type>-<purpose>-<env>: vnet-<env>, snet-aks-nodes-<env>, mi-kubelet-<env>, mi-cicd-<name>, fc-github-<name>, kv-<name>. Die modules ergänzen einen tag layer. Der Environment Root ergänzt environment, managed_by (terraform) und platform (azure oder azure-local), neben den tags project und owner aus der Konfiguration. Siehe auch Namen und tags für die plattformweiten Konventionen.

Beziehung zu MCP hub und spokes¶

Modus	Beziehung
Standalone	Die Lösung braucht den hub nicht. Sie erstellt ihren eigenen spoke, und Peering ist im Code vorhanden, aber deaktiviert.
Hub-integrated	Die Lösung nutzt einen spoke aus der landing zone, Private DNS zones im Besitz des hubs und den Egress-Pfad des hubs. Der hub muss die Voraussetzungen unter Networking bieten. Zum hub-and-spoke-Modell siehe Architekturreferenz.