AKS-Plattform: Betrieb¶

Diese Seite richtet sich an das Plattform-Team (XMMS im Managed-Modell, dein eigenes Team im Eigenbetrieb, siehe Betriebsmodelle). Sie beschreibt die wiederkehrende Arbeit: Upgrades, Start und Stopp von Non-production, Monitoring und Alerting, Break-glass-Zugriff und die bekannten Lücken.

Referenzdesign, dein Deployment kann abweichen

Zeitpläne und Schwellenwerte sind die Werte der Referenzkonfiguration. support-Zeiten, Reaktionszeiten und Eskalation legen dein Vertrag oder dein eigener Prozess fest, siehe Betriebsverantwortlichkeiten und Incident Management.

Upgrades von Kubernetes und Node-Image¶

Upgrades folgen den Wartungsfenstern in Cluster baseline.

Schritt	Aktion
1	Eine neue AKS-Minor-Version wird verfügbar. Das Design will eine unterstützte GA-Version, die mindestens eine Minor-Version hinter der neuesten liegt.
2	Prüfe die Plattform- und Anwendungsmanifeste auf entfernte Kubernetes-APIs (das Design nennt `kubent` und `pluto`).
3	Aktualisiere Non-production: Ändere `aks_kubernetes_version` in der Non-production-Konfiguration und führe die pipeline aus. Patch-Versionen im Channel `patch` kommen von selbst.
4	Validiere Plattform-Add-ons und Workloads. Das Design verlangt vor Production eine Validierungsphase von etwa zwei Wochen, mit automatisierten Tests.
5	Aktualisiere Production in ihrem Fenster mit derselben Änderung an der Production-Konfiguration.
6	Node-Image-Upgrades folgen dem Fenster für Node-OS. Sie laufen unterbrechungsfrei, wenn Workloads Disruption Budgets haben, und mit der Surge-Einstellung 33%.

Eine Minor-Version lässt sich nicht zurückrollen. Ändere die Version nicht im Portal, weil Terraform das als Drift meldet.

Start und Stopp von Non-production¶

Ein geplanter Workflow stoppt den Non-production-Cluster außerhalb der Bürozeiten und startet ihn wieder, um Kosten zu sparen.

Einstellung	Wert
Zeitplan	Montag bis Freitag. Start um 07:00 UTC (09:00 CET), Stopp um 15:00 UTC (17:00 CET)
Verhalten	Liest zuerst den Power State. Startet nur einen gestoppten Cluster, stoppt nur einen laufenden Cluster, überspringt sonst
Manuell	Der Workflow lässt sich auch von Hand mit `start` oder `stop` ausführen
Befehl	`az aks start` und `az aks stop` ohne Warten
Cluster	Cluster-Name und Ressourcengruppe sind im Workflow für den Standalone-Non-production-Cluster gesetzt

Prüfe, wie der Zeitplan auf das Wartungsfenster trifft

Der Zeitplan ist in UTC, deshalb verschieben sich die Ortszeiten mit der Sommerzeit um eine Stunde. Die Wartungsfenster von Non-production beginnen am Dienstag um 20:00 (UTC+1), also nach der Stoppzeit. Ein gestoppter Cluster wird nicht aktualisiert, das Fenster geht also verloren, wenn der Cluster nicht läuft. Bestätige, wie deine Plattform damit umgeht, zum Beispiel durch Verschieben des Fensters oder durch Auslassen des Stopps an diesem Tag. Der Workflow deckt den hub-integrated Non-production-Cluster nicht ab.

Monitoring und Alerting¶

Die Azure-Ressourcen der Lösung schalten Monitoring nur ein, wenn du einen Log Analytics workspace angibst. Der Monitoring-Stack im Cluster wird vom Plattform-GitOps-Repository deployt. Das Load-Testing-Design beschreibt den Referenz-Non-production- Cluster wie folgt.

Komponente	Detail
Metriken	kube-prometheus-stack im namespace `monitoring`, mit kube-state-metrics und node-exporter. Aufbewahrung 7 Tage oder 8 GB
Dashboards	Grafana aus demselben Stack. Dashboards werden aus Config Maps mit einem Label bereitgestellt
Logs	Grafana Alloy als Daemon Set, liefert an Loki. Loki ist eine Data Source in Grafana
Alert-Regeln	Prometheus-Regeln im GitOps-Repository: SLO-Burn-Rate-Alerts und Recording Rules
Routing	Alertmanager gruppiert nach Alert-Name, namespace und SLO. Kritische Alerts gehen an PagerDuty (Wiederholung jede Stunde), Warnungen gehen an PagerDuty (Wiederholung alle 4 Stunden), der Alert `Watchdog` geht nirgendwohin
Incidents	PagerDuty-Service pro Umgebung, aus dem On-call-Terraform (Deployment)

Das Design definiert diese Service Level Objectives und alarmiert darauf mit einer schnellen und einer langsamen Burn Rate (das 14,4-Fache und das 3-Fache des Error Budgets):

Bereich	Ziel
Verfügbarkeit des Kubernetes-API-Servers	99,9%
Erfolgsrate von Ingress	99,9%, mit p95-Latenz unter 500 ms und p99 unter 1 s
Verfügbarkeit der Workload-Pods	99,5%
DNS	99,99% Erfolg
GitOps-Sync	100% der Anwendungen synchronisiert

Weitere Alerts im Design: Pod-Restart-Rate, Crash Loops, Deployments ohne Ready Replicas, Zertifikate und die Security- Alerts unter Identität und Zugriff. Um die ganze Kette von der Regel bis zum Incident zu prüfen, nutze den Load Test. Siehe auch den Alert-Katalog für die Alerts der MCP-Plattform selbst.

Break-glass-Aktivierung¶

Der Engineer aktiviert die Break-glass-Gruppe in PIM mit einer Begründung. Die Aktivierung ist zeitlich begrenzt (höchstens 4 Stunden) und braucht MFA.
Die Aktivierung löst einen kritischen Alert aus, sodass das Plattform-Team sofort Bescheid weiß. Das Kubernetes Audit Log hält fest, was die Gruppe tut.
Argo CD macht von Hand vorgenommene Änderungen rückgängig, übernimm deshalb jede Änderung, die bleiben soll, in Git.
Die Gruppenmitgliedschaft wird jedes Quartal geprüft.

Einen Cluster neu aufbauen¶

Der Cluster ist für den Neuaufbau ausgelegt: Führe die pipeline für die Umgebung aus und lass GitOps dann Plattform-Services, RBAC, Policies und Anwendungen wiederherstellen. Persistent Volumes werden dadurch nicht wiederhergestellt. Production-Daten brauchen ein eigenes Backup. Resource Locks und State-Schutz sind unter Cluster baseline beschrieben.

Review der Policy-Ausnahmen¶

Prüfe alle aktiven Policy-Ausnahmen jedes Quartal. Entferne abgelaufene. Siehe Security policy.

Bekannte Probleme¶

Problem	Workaround	Status
Ein Graph-API-Problem lässt `apply` mit dem Target `all` fehlschlagen, wenn sich Cluster-Rollenzuweisungen ändern	Nutze das Target `cicd-aks-rbac` (Deployment)	Wartet auf einen Provider-Fix
Hub-integrated-Modus: Die private DNS zone der Container Registry ist erforderlich, aber es wird kein private endpoint für die Registry erstellt	Der hub stellt einen bereit, oder ergänze ihn in diesem Repository	Offener Punkt im Design
Der Besitz der Route Table im hub-integrated-Modus ist nicht final geklärt	Pro Umgebung entscheiden	Offener Punkt im Design
Azure Local: Die Arc Resource Bridge erreicht die Cluster Control Plane nicht (`APIServerNotOnline`)	TCP 6443 zwischen dem Management-Netzwerk und dem Logical Network öffnen (Voraussetzungen)	Aktion im Kundennetzwerk