AKS-Plattform: Servicebeschreibung¶
Diese Seite beschreibt, was die AKS-Plattform bietet, welche Varianten es gibt, wie Änderungen laufen und wo die Grenzen liegen. Die anderen Seiten gehen ins Detail: Den Cluster nutzen, Security policy, Architektur und die Seiten, auf die sie verweisen.
Referenzdesign, pro Plattform festgelegt
Der Service wird vom Plattform-Team im Rahmen einer Vereinbarung geliefert (Betriebsmodelle). Support-Zeiten, Reaktionszeiten, Kontakte und Gebühren sind Teil dieser Vereinbarung und stehen nicht in dieser Dokumentation. Wo eine Seite einen Standard nennt (eine Größe, ein Fenster, eine Aufbewahrungsfrist), ist das der Wert der Referenzkonfiguration. Deine Plattform kann abweichen.
Kurz gesagt¶
Das Plattform-Team baut und pflegt AKS-Cluster als Infrastructure as Code mit Terraform. Jeder Cluster bekommt dieselbe Baseline: privater API-Server, Anmeldung nur über Entra ID, workload identity, ein festes Node-Pool-Layout, Wartungsfenster und eine Baseline für Security Policy. Workload-Teams deployen in Namespaces dieser Cluster und nutzen den Cluster über Gruppen und GitOps, nicht über gemeinsame Zugangsdaten.
Was angeboten wird¶
| Bereich | Enthalten |
|---|---|
| Cluster | Ein AKS-Cluster pro Umgebung (Produktion und Nicht-Produktion), mit System- und User-Node-Pools, Autoscaling, Availability Zones in Produktion und Wartungsfenstern (Cluster baseline). |
| Netzwerk | Ein spoke mit getrennten Subnetzen für Nodes, Ingress, private endpoints und den API-Server. Im hub-integrierten Modus kommt der spoke aus dem hub und der landing zone (Networking). |
| Zugriff | Entra-ID-Gruppen für Plattform-Admins, Operatoren, Auditoren, Break-glass und pro Team. Lokale Kubernetes-Konten sind deaktiviert (Identität und Zugriff). |
| Workload identity | Eine User-assigned Managed Identity pro Anwendung und pro Umgebung, föderiert mit einem Kubernetes Service Account. Keine gespeicherten Client Secrets. |
| Secrets | Ein Key Vault mit RBAC-Autorisierung, Purge Protection und ohne öffentlichen Zugriff, erreichbar über einen private endpoint (Azure-Variante). |
| Security policy | Azure Policy for Kubernetes sowie Kyverno-Policies, Default-deny-Network-Policies und Namespace-Quotas aus dem GitOps-Repository (Security policy). |
| Deployment | Terraform über pipelines, mit einem state pro Plattform und Umgebung (Deployment). |
| Betrieb | Geplante Upgrade-Fenster, ein optionaler Start-/Stopp-Zeitplan für Nicht-Produktion, ein Bereitschaftssetup in PagerDuty (Betrieb). |
| Lasttests | Ein wiederholbarer Lasttest und eine Alert-Validierung für den Nicht-Produktions-Cluster (Lasttests). |
Varianten¶
| Variante | Was sie ist | Status in den Quellen |
|---|---|---|
| Azure, standalone | Die Lösung baut ihr eigenes spoke-VNet, Subnetze, eine Route Table und eine Private DNS zone. Egress läuft über den AKS Load Balancer. | In der Referenzkonfiguration für nonprod und prod deployt. |
| Azure, hub-integrated | Der Cluster nutzt einen spoke, den hub und landing zone erstellt haben. Egress folgt dem hub (User-defined Routing). Private DNS zones kommen vom hub. | Im Code umgesetzt und von einer Umgebung nonprod-integrated genutzt. Das Designdokument sagt noch „implementation pending“. |
| Azure Local | AKS auf Azure Local (AKS Arc). Der Cluster wird mit der Azure CLI erstellt, Terraform verwaltet Arc-Extensions, Identität, Policy und Key Vault. | Code und pipeline sind vorhanden. In der committeten Konfiguration steht jeder layer-Schalter auf false, daher ist in den Quellen nicht sichtbar, was deployt wurde. |
Die Unterschiede stehen unter AKS auf Azure Local.
Wie Änderungen laufen¶
Es gibt zwei Arten von Änderungen, und sie nutzen zwei Wege.
- Azure-Ressourcen (Cluster, Netzwerk, Identitäten, Key Vault, Azure Policy): eine Änderung an der Terraform-Konfiguration, geplant und angewendet von einem pipeline-Lauf (Deployment). Manuelle Änderungen im Azure-Portal an Ressourcen, die Terraform verwaltet, sind Drift und werden vom nächsten Lauf rückgängig gemacht.
- Ressourcen im Cluster (Namespaces, RBAC-Bindings, Policies, Quotas, Plattform-Services, Anwendungen): ein pull request auf ein GitOps-Repository. Argo CD wendet ihn an. Die Kubernetes-Manifeste, die früher im Terraform-Repository lagen, sind veraltet und nur noch als Historie erhalten.
Typische Standardänderungen:
- ein Team onboarden: Entra-ID-Gruppen und Namespaces, RBAC-Bindings;
- eine workload identity für eine Anwendung und ihre Rolle auf einem Key Vault hinzufügen;
- eine Policy-Ausnahme hinzufügen (pull request mit Begründung, vom Security-Team geprüft, mit Ablaufdatum);
- die Größe eines Node Pools ändern oder einen User-Node-Pool hinzufügen;
- auf eine neue Kubernetes-Minor-Version wechseln, zuerst Nicht-Produktion.
Verantwortlichkeiten¶
| Plattform-Team | Workload-Team | |
|---|---|---|
| Terraform-Code, layers, Cluster baseline, neue Versionen | Ja | |
| Kubernetes-Minor-Upgrades und Node-Image-Upgrades | Ja | Testet die Anwendung nach Upgrades in Nicht-Produktion |
| Entra-ID-Gruppen, Prozess für Gruppenmitgliedschaften, Azure-Rollenzuweisungen | Ja | Stellt die Anfrage, nennt die Team Leads |
| Workload identity für eine Anwendung | Erstellt sie | Fragt sie an, nutzt den Service Account in der Anwendung |
| Namespaces, Resource Quotas, Limit Ranges, Default-Network-Policies | Ja | |
| Network Policies der Anwendung zusätzlich zu den Defaults | Prüft | Schreibt sie |
| Kyverno- und Azure-Policy-Baseline, Policy-Ausnahmen | Ja (das Security-Team genehmigt Ausnahmen) | Beantragt Ausnahmen |
| Ingress Gateway, Zertifikate, Monitoring-Stack | Ja | |
Routen (HTTPRoute), Anwendungs-Deployments und Manifeste |
Ja | |
| Container-Images, Scanning, was die Anwendung mit Secrets macht | Ja | |
| Alerts zur Anwendung | Ja | |
| Alerts zur Plattform und die Bereitschaftsreaktion | Ja | |
| Break-glass-Zugriff und sein Review | Ja |
Die allgemeine Aufteilung steht unter Verantwortlichkeiten. Vertragsdetails wie Zeiten und Reaktionszeiten stehen in deiner Vereinbarung.
Grenzen¶
| Nicht Teil des Services | Warum |
|---|---|
| Backup von Persistent Volumes | Nicht Teil der Cluster baseline. Das Design empfiehlt Azure Backup for AKS oder Velero, pro workload geplant. |
| Anwendungs-workloads und ihre Daten | Sie gehören dem Workload-Team. |
| Eine Web Application Firewall | Im ersten Design nicht enthalten. |
| Defender for Containers | In der Referenzkonfiguration deaktiviert. Es lässt sich aktivieren, siehe Security policy. |
| Eine firewall im Standalone-Modus | Das Design beschreibt Egress über Azure Firewall. Der Terraform-Code des Standalone-Modus deployt keine. Im hub-integrierten Modus folgt der Egress dem hub (Networking). |
| Azure-Local-Hardware, Arc Resource Bridge, Custom Location, logisches Netzwerk | Infrastruktur-Voraussetzungen der Azure-Local-Variante, mit eigenem Lebenszyklus (Voraussetzungen). |
| Von Hand im Cluster vorgenommene Änderungen | In Produktion erlaubt das Design nur GitOps-Änderungen. Direkte Änderungen macht Argo CD rückgängig. |