AKS-Plattform: Cluster baseline¶
Die Cluster baseline ist die Standardkonfiguration jedes AKS-Clusters der Lösung. Sie ist der Terraform layer
cluster-baseline (modules aks-cluster, node-pools, cluster-identities, diagnostic-settings). Diese Seite listet die
wichtigen Einstellungen und die Werte der Referenzkonfiguration auf.
Referenzdesign, dein Deployment kann abweichen
Die Werte unten stammen aus den Terraform modules und den Konfigurationsdateien nonprod und prod der Azure-
Variante. Das Designdokument beschreibt einige andere Werte; die Unterschiede sind dort genannt, wo sie wichtig sind.
Im module fest vorgegeben¶
Diese Einstellungen sind im module gesetzt und lassen sich nicht per Variable abschalten.
| Einstellung | Wert | Warum |
|---|---|---|
| Entra-ID-Integration | An, mit Azure RBAC für die Kubernetes-Autorisierung | Menschen melden sich mit Entra ID an. |
| Lokale Konten | Deaktiviert | Keine gemeinsamen Admin-Zugangsdaten (local_account_disabled = true). |
| API-Server-Zugriff | VNet-Integration in einem eigenen Subnet | Der API-Server hat eine private Adresse im spoke, keinen öffentlichen Endpunkt. |
| OIDC issuer und workload identity | Aktiviert | Pods bekommen Azure-Zugriff ohne gespeicherte Secrets (Identität und Zugriff). |
| Azure-Policy-Add-on | Aktiviert | Azure Policy for Kubernetes (Security policy). |
| System Node Pool | Name system, Autoscaling, Managed OS Disk, nur kritische Add-ons, Label node-pool=system |
Hält Anwendungs-Pods von den System-Nodes fern. |
| Cluster-Identität | Eine user-assigned managed identity, genutzt für Control Plane und Kubelet | Siehe Cluster-Identitäten. |
| Netzwerk-Plugin | Azure CNI im Overlay-Modus mit der Network-Policy-Engine Calico | Siehe Networking. |
Werte pro Umgebung¶
| Einstellung | Production | Non-production |
|---|---|---|
| Cluster-Name | aks-prod |
aks-nonprod |
| Kubernetes-Version | Minor-Version in der Konfiguration fixiert (1.34 in den Referenzdateien) | Gleich |
| SKU-Tier | Standard (mit SLA) |
Free |
| Upgrade-Channel | none (manuell) |
patch |
| VM-Größe System Pool | Standard_D4s_v5 |
Standard_D2s_v5 |
| Nodes System Pool (min bis max) | 3 bis 5 | 1 bis 2 |
| Zonen System Pool | 1, 2, 3 | 1 |
| Max. Pods pro Node System Pool | 30 | 100 |
VM-Größe User Pool general |
Standard_D4s_v5 |
Standard_D4s_v5 |
Nodes User Pool general (min bis max) |
3 bis 20 | 1 bis 5 |
Zonen User Pool general |
1, 2, 3 | 1 |
Max. Pods pro Node User Pool general |
30 | 100 |
| Label User Pool | workload-type=general |
workload-type=general |
| OS Disk | 128 GB, managed | 128 GB, managed |
| Surge bei Upgrades (User Pool) | 33% | 33% |
| Ressourcengruppe | rg-prod-aks (Nodes in rg-prod-aks-nodes) |
rg-nonprod-aks (Nodes in rg-nonprod-aks-nodes) |
Designdokument gegenüber Code
Das Designdokument beschreibt Non-production mit 2 bis 3 System-Nodes und 2 bis 10 User-Nodes über die Zonen 1 und 2, mit
30 Pods pro Node. Die Konfigurationsdatei nonprod setzt die oben gezeigten kleineren Werte, um Kosten zu sparen. Die hub-integrated
Non-production-Datei nutzt dieselben Größen wie nonprod.
User Node Pools sind in der Konfiguration eine Map. Einen Pool hinzuzufügen (zum Beispiel einen eigenen Ingress-, Platform-, Spot- oder GPU-Pool) ist eine Konfigurationsänderung: Name, VM-Größe, min. und max. Anzahl, Zonen, Disk-Größe, max. Pods, Labels, Taints und Surge. Das Pool- module aktiviert Autoscaling auf jedem Pool.
Upgrades und Wartungsfenster¶
| Production | Non-production | |
|---|---|---|
| Upgrades der Kubernetes-Version | Manuell, im Fenster, nachdem Non-production validiert wurde | Der Channel patch wendet Patch-Versionen automatisch an; Minor-Upgrades bleiben manuell |
| Fenster für Auto-Upgrade | Samstag 03:00, 4 Stunden, UTC+1 | Dienstag 20:00, 4 Stunden, UTC+1 |
| Fenster für Node-OS | Samstag 03:00, 4 Stunden, UTC+1 | Dienstag 20:00, 4 Stunden, UTC+1 |
Beide Fenster sind wöchentlich. Der Offset ist fest, deshalb verschiebt sich das Fenster gegenüber der Ortszeit um eine Stunde, wenn die Sommerzeit beginnt oder endet. Ändere den Offset in der Konfiguration, wenn das stört.
Das Designdokument nennt das Fenster für das Node-Image bei Production am Sonntag und bei Non-production am Mittwoch. Die Konfigurationsdateien setzen es auf denselben Tag wie das Fenster für das Kubernetes-Upgrade.
Regeln aus dem Design:
- Non-production wird zuerst aktualisiert, und Production folgt nach einer Validierungsphase, sodass beide Cluster im Normalbetrieb dieselbe Minor- Version fahren;
- Eine Minor-Version lässt sich auf AKS nicht zurückrollen. Nach einem fehlgeschlagenen Upgrade hilft ein Fix nach vorn oder ein Rollback auf Workload-Ebene;
- Prüfe vor einem Minor-Upgrade auf entfernte Kubernetes-APIs (das Design nennt
kubentundpluto); - Terraform verfolgt die Version, deshalb zeigt sich eine manuelle Versionsänderung außerhalb von Terraform als Drift.
Add-ons und Optionen¶
| Option | Referenzkonfiguration | Hinweise |
|---|---|---|
| Azure-Policy-Add-on | An | Im module fest vorgegeben. |
| Key Vault Secrets Provider (CSI driver) | An in nonprod, prod und nonprod-integrated, mit Secret-Rotation alle 2 Minuten |
Das Designdokument sagt, der CSI driver wird nicht genutzt und Anwendungen lesen Key Vault mit dem SDK. Der Code-Schalter ist in den Referenzdateien an. |
| Azure Monitor (Container Insights) | Aus | Braucht die ID eines Log Analytics workspace. |
| Image Cleaner | Aus | Wenn an, läuft er alle 168 Stunden (7 Tage). |
| Managed Prometheus | Nicht im Code | Das Design sagt, es später zu evaluieren. |
| AKS-Diagnoseeinstellungen | Aus (deploy_aks_diagnostics = false) |
Die Production-Datei listet die Kategorien, die vor go-live zu aktivieren sind: kube-apiserver, kube-audit-admin, kube-controller-manager, guard, cloud-controller-manager. Braucht einen Log Analytics workspace. |
| Defender for Containers | Aus | Siehe Security policy. |
Das Design sagt, dass Diagnoseeinstellungen vor dem Production-go-live Pflicht sind, mit einer Aufbewahrung von 90 Tagen (Production) und 30 Tagen (Non-production) in Log Analytics. Die Aufbewahrung ist eine Eigenschaft des workspace und wird von dieser Lösung nicht gesetzt.
Cluster-Identitäten¶
Der Identity layer erstellt pro Cluster eine user-assigned managed identity (mi-kubelet-<env>). Die Cluster baseline nutzt sie
als Control-Plane-Identität und als Kubelet-Identität. Das module cluster-identities gibt ihr diese Azure-Rollen:
| Rolle | Scope | Zweck |
|---|---|---|
| Network Contributor | Node-Subnet | Nodes in das Subnet einbinden |
| Network Contributor | API-Server-Subnet | VNet-Integration des API-Servers |
| Private DNS Zone Contributor | Jede private DNS zone in aks_private_dns_zone_ids |
Private DNS-Einträge verwalten (in den Referenzdateien keine gesetzt) |
| Managed Identity Operator | Die Identität selbst | Die Kubelet-Identität den Node Scale Sets zuweisen |
| AcrPull | Jede Registry in aks_acr_ids |
Images ohne Pull Secrets ziehen (in den Dateien für Production und nonprod keine gesetzt) |
Der Environment Root weist derselben Identität außerdem Network Contributor auf dem spoke VNet zu.
Designdokument gegenüber Code
Das IAM-Designdokument beschreibt eine system-assigned Control-Plane-Identität und eine separate user-assigned Kubelet-Identität. Der Code nutzt für beide eine user-assigned Identität. Der Code ist maßgeblich.
Bootstrap für GitOps¶
Die Cluster baseline gibt GitOps einen erreichbaren, authentifizierten Cluster mit workload identity und einer Network-Policy-Engine. Sie deployt keine namespaces, kein RBAC und keine Plattform-Services. Das Design listet diese als GitOps-Bootstrap-Ressourcen:
| Ressource | Zweck |
|---|---|
Namespaces platform-system, gateway-system, monitoring, policy-system |
Heimat der Plattform-Komponenten |
Priority class platform-critical (Wert 1000000) |
Zentrale Plattform-Pods, die nicht verdrängt werden dürfen |
Priority class platform-high (Wert 900000) |
GitOps-Controller, Ingress Gateway, Zertifikatsverwaltung |
Priority class workload-default (Wert 100000) |
Default für Anwendungs-Pods, werden zuerst verdrängt |
| Cluster Role Bindings für die Plattform-Gruppen | Platform Admin, Operator, Auditor, Break-glass |
Recovery-Modell¶
Das Design behandelt einen Cluster als wegwerfbar und neu aufbaubar: Ein zerstörter Cluster wird mit Terraform neu aufgebaut (das Design rechnet mit 30 bis 60 Minuten), und GitOps stellt danach Plattform-Services, RBAC, Policies und Anwendungen wieder her. Daten auf Persistent Volumes sind nicht abgedeckt. Plane Azure Backup for AKS oder Velero pro Workload ein.
Das Design nennt außerdem Resource Locks (CanNotDelete auf der Production-Ressourcengruppe und auf dem State Storage Account) und
State Storage mit Versionierung und Soft Delete. Der Terraform-Code der Lösung erstellt keine Locks. Bestätige mit dem
Plattform-Team, wie sie in deiner Umgebung gesetzt sind.