AKS-Plattform: Deployment¶

Diese Seite beschreibt, wie die Lösung deployt wird: das Terraform-Layout, die pipelines, die Konfigurationsdateien, die Rollen der pipeline-Identity und die Reihenfolge eines ersten Deployments. Die pipelines führt das Plattform-Team aus (XMMS im Managed-Modell, dein eigenes Team im Eigenbetrieb, siehe Betriebsmodelle).

Referenzdesign, dein Deployment kann abweichen

Namen von pipelines, Eingaben und Umgebungsnamen sind die des Referenz-Repositorys. Deine Plattform kann dasselbe Terraform aus einer anderen pipeline ausführen.

Terraform-Layout¶

terraform/
  environments/
    azure/            # root for AKS in Azure
      config/         # <environment>.tfvars and backend-<environment>.hcl
    azure-local/      # root for AKS on Azure Local, with scripts/bootstrap-aks-arc.ps1
  modules/
    azure/            # composition per layer for Azure
    azure-local/      # composition per layer for Azure Local
    network/ identity/ secrets/ cluster-baseline/ security-policy/   # building blocks
  pagerduty/          # on-call setup, separate root and state

Punkt	Wert
Terraform-Version	1.5 oder höher (`~> 1.5` in der pipeline)
Provider	`azurerm` 4.x, `azuread` 3.x (die Azure-Root fügt einen `azurerm`-Provider mit Alias für die hub subscription hinzu)
State	Azure Storage, eine Backend-Datei und ein State-Key pro Plattform und Umgebung
Arbeitsverzeichnis	`terraform/environments/<platform>/`
Variablen	`-var-file=config/<environment>.tfvars`

Manueller Lauf, aus dem Arbeitsverzeichnis:

terraform init -backend-config=config/backend-<environment>.hcl
terraform plan -var-file=config/<environment>.tfvars -out=tfplan
terraform apply tfplan

Pipelines¶

Pipeline	Plattform	Eingaben
Terraform Platform Pipeline (GitHub Actions)	`azure` und `azure-local`	`platform`, `environment` (`nonprod`, `prod`, `nonprod-integrated`, `prod-integrated`), `action`, `target_module`, `vars_ref`
Terraform platform pipeline (Azure DevOps)	`azure` und `azure-local`; die Quellen beschreiben sie als für Azure Local verwendet	`platform`, `environment` (`nonprod`, `prod`), `action`, `target_module`
Terraform PagerDuty pipeline (GitHub Actions)	On-Call-Setup	`environment`, `action`
AKS non-production start and stop (GitHub Actions)	Kosteneinsparung	`action` (geplant und manuell)
Load test (GitHub Actions)	Nicht-Produktion	Raten, Dauern, Fehler-Trigger (Lasttests)

Actions¶

Action	Wirkung
`plan`	Nur Terraform plan
`apply`	plan, dann apply
`destroy-plan`, `destroy`	Die Zerstörung planen, oder zerstören
`bootstrap`	Nur Azure Local: den Cluster und MetalLB erstellen
`bootstrap-and-apply`	Nur Azure Local: Bootstrap, dann plan und apply
`bootstrap-and-plan`	Nur Azure Local, Azure-DevOps-pipeline: Bootstrap, dann plan

Ziel-Layers¶

target_module ist im Normalbetrieb all. Ein einzelner layer (networking, identity, security-policy, cluster-baseline, secrets) nutzt Terraform -target und ist nur für den Bootstrap oder eine kontrollierte Wiederherstellung gedacht. Die pipeline warnt, wenn du ihn verwendest. Die GitHub-pipeline ergänzt cicd-aks-rbac, das nur die Rollenzuweisungen der pipeline auf dem Cluster anspricht.

Was ein Lauf macht¶

Löst das GitHub Environment aus Plattform und Umgebung auf. Die -integrated-Umgebungen verwenden die GitHub Environments der Standalone-Cluster wieder; es werden keine neuen Environments erstellt.
Liest die Authentifizierungswerte (auth.conf) und, für Azure Local, die Bootstrap-Werte (bootstrap.conf) dieser Umgebung aus einem separaten privaten Variablen-Repository, mit einem GitHub-App-Token.
Meldet sich per GitHub OIDC bei Azure an (kein Client Secret) und setzt die Terraform-Variablen ARM_*.
Führt terraform fmt -check, init, validate aus, dann plan oder apply für den gewählten layer.
Führt auf Azure Local zuerst den Bootstrap aus, wenn die Action es verlangt, und übergibt cluster_id und oidc_issuer_url über eine erzeugte config/ci.auto.tfvars an Terraform.

Pro Plattform und Umgebung läuft jeweils nur ein Lauf (eine Concurrency Group). Genehmigungen für die Produktion werden mit den Protection Rules des GitHub Environments erzwungen, oder mit Approval Gates im Azure-DevOps-Environment.

Das Storage Account für den Terraform-State der hub-integrierten Umgebung liegt in der subscription der Standalone-Cluster, während die Ressourcen in der spoke subscription erstellt werden. Die Backend-Datei legt deshalb die State-subscription fest.

Rollen der pipeline-Identity¶

Die Identity der Azure-pipeline braucht, um die vollständige Plattform zu deployen:

Rolle	Scope	Zweck
Contributor	Subscription	Die Ressourcen erstellen und verwalten
Resource Policy Contributor	Subscription	Azure-Policy-Zuweisungen erstellen
Role Based Access Control Administrator	Subscription, mit einer Condition	Rollenzuweisungen für die Managed Identities erstellen
Storage Blob Data Contributor	State-Storage-Account	Den State lesen und schreiben
Graph-Berechtigung `Group.ReadWrite.All` (Admin Consent) oder die Entra-Rolle Groups Administrator	Tenant	Entra-ID-Gruppen erstellen und verwalten

Beschränke die Rolle Role Based Access Control Administrator mit der Condition „allow user to only assign selected roles to selected principals“ und erlaube nur: Managed Identity Operator (Cluster-Identity auf Kubelet-Identity), Network Contributor (Cluster-Identity auf dem VNet und den Subnetzen), Private DNS Zone Contributor (Cluster-Identity auf DNS zones), AcrPull (Kubelet- Identity auf der Registry).

Weitere Rollen im Code

Der Code weist außerdem Key Vault Secrets User an Workload Identities und Azure Kubernetes Service RBAC Admin an pipeline-Identities zu. Nimm diese Rollen in die Condition auf, wenn die pipeline-Identity diese Zuweisungen erstellt. Im hub-integrierten Modus braucht die Identity außerdem Zugriff in der spoke subscription (Netzwerk).

Erstes Deployment einer Umgebung¶

Bereite die Konfigurationsdatei und die Backend-Datei für die Umgebung vor, sowie die Voraussetzungen (Voraussetzungen).
Führe plan mit target_module = all aus und prüfe ihn.
Führe apply aus. Die layers werden in Abhängigkeitsreihenfolge angewendet: zuerst Netzwerk und Identity, dann Security Policy, Cluster Baseline und Secrets.
Lies die OIDC-Issuer-URL des Clusters aus, setze oidc_issuer_url in der Konfiguration und führe apply erneut aus. Erst dann werden die Workload Identities und ihre Federated Credentials erstellt.
Setze die Mitgliedschaften der Entra-ID-Gruppen und lass GitOps dann Namespaces, RBAC, policies und Plattform-Services anwenden.

Führe für Azure Local zuerst den Bootstrap aus (AKS on Azure Local).

Bekanntes Problem: Graph API¶

Ein Problem der Microsoft Graph API bricht terraform apply mit Target all ab, wenn sich Rollenzuweisungen auf dem Cluster ändern (ein Problem im Provider azuread, das auf einen Fix wartete). Der Workaround ist, die Rollenzuweisungen der pipeline über das Target cicd-aks-rbac zu ändern. Die Rollenzuweisungen für die pipeline liegen aus diesem Grund außerhalb des Identity-Moduls.

On-Call-Setup (PagerDuty)¶

Eine separate Terraform-Root terraform/pagerduty hat einen eigenen State und eine eigene pipeline. Sie erstellt pro Umgebung:

Ressource	Einstellung
Team und Mitgliedschaften	In der Konfiguration angegebene Benutzer, mit einer Rolle
Schedule	Wöchentliche Rotation in der Zeitzone Amsterdam, beschränkt auf Bürotage und -zeiten
Escalation Policy	Ein Schedule, Eskalationsverzögerung 30 Minuten, zweimal wiederholt
Service	Erstellt Alerts und Incidents, Auto-Resolve nach 4 Stunden, Acknowledgement-Timeout 30 Minuten, Dringlichkeit nach Severity in den support-Zeiten und niedrig außerhalb
Alert Grouping	Intelligent Grouping
Service-Abhängigkeit	Der Service unterstützt einen Business Service des Anbieters
Integration	Events-API-v2-Integration für Prometheus Alertmanager

Die Zeiten, Eskalationsschritte und wer Bereitschaft hat, werden in deinem Vertrag oder deinem internen On-Call-Prozess vereinbart. Die Werte im Code sind die Defaults.