Zum Inhalt

AKS-Plattform

Manche workloads brauchen Kubernetes: containerisierte Anwendungen, die selbstständig skalieren, ausgerollt werden und sich erholen. Die AKS-Plattform ist eine Lösung, die einem Plattform-Team ein festes, wiederholbares Fundament für solche Cluster gibt: den Cluster selbst, sein Netzwerk, Identitäten und Zugriff, Security Policy und Secrets, alles als Terraform. Workload-Teams bekommen Namespaces auf diesem Cluster mit einem vorhersehbaren Vertrag (Zugriff über Gruppen, workload identity statt gespeicherter Zugangsdaten, standardmäßige Netzwerk- und Pod-Security- Regeln).

Die Lösung hat zwei Varianten: AKS in Azure und AKS auf Azure Local (der Kubernetes-Cluster läuft auf Hardware im eigenen Rechenzentrum und wird über Azure Arc verwaltet). Beide nutzen dasselbe Layout und dasselbe Modell für Identität und Secrets.

Referenzdesign, pro Plattform festgelegt

Die AKS-Plattform ist nicht Teil des Kerncodes von MCP hub und spoke. Ob sie verfügbar ist, welche Variante du bekommst und welche Optionen aktiviert sind, hängt von deiner Plattform ab. Die Namen, Größen und Zeitpläne auf diesen Seiten sind die Werte der Referenzkonfiguration; dein Deployment kann abweichen. Das Plattform-Team ist XMMS mit einem managed-service-Vertrag oder dein eigenes Team im Eigenbetrieb (Betriebsmodelle).

Status der Quellen

Diese Seiten sind aus dem Terraform-Code, den pipelines und den Designdokumenten der Lösung entstanden. Wo die Designdokumente und der Terraform-Code sich widersprechen, nennen die Seiten, was der Code tut, und sagen das auch. Die Plattform-Services im Cluster (GitOps- Controller, Ingress Gateway, Monitoring, Policy Engine) werden aus separaten GitOps-Repositorys deployt, die nicht zu dieser Dokumentation gehören. Sie werden hier nur so weit beschrieben, wie die Designdokumente sie beschreiben.

Begriffe

Begriff Bedeutung
Layer Eine Terraform-Modulgruppe der Lösung: Networking, Identität, Security Policy, Cluster baseline, Secrets. Jeder layer hat einen Schalter deploy_*.
Cluster baseline Die Standardkonfiguration eines AKS-Clusters: Node Pools, Netzwerkprofil, Identität, Add-ons, Wartungsfenster.
Umgebung nonprod oder prod, dazu nonprod-integrated und prod-integrated für Cluster in einem in den hub integrierten Netzwerk. Jede Plattform und Umgebung hat eine eigene Konfigurationsdatei und einen eigenen Terraform-state.
Plattform azure (AKS in Azure) oder azure-local (AKS auf Azure Local).
Standalone / hub-integrated Die zwei Netzwerkmodi der Azure-Variante: Die Lösung baut einen eigenen spoke, oder sie nutzt einen spoke aus dem hub und der landing zone (Networking).
Bootstrap Das einmalige Erstellen eines Azure-Local-Clusters mit der Azure CLI, bevor Terraform übernimmt (AKS auf Azure Local).
GitOps-Repositorys Separate Repositorys mit den Kubernetes-Manifesten (Namespaces, RBAC, Policies, Plattform-Services, Anwendungen), die Argo CD auf den Cluster anwendet.

Was du bekommst

Bereich Was die Lösung tut Seite
Servicebeschreibung Umfang, Varianten, Grenzen und Aufteilung der Verantwortlichkeiten Servicebeschreibung
Den Cluster nutzen Namespaces, Zugriffsgruppen, workload identity, Ingress und Key Vault aus Sicht eines Workload-Teams Den Cluster nutzen
Security policy Admission-Regeln, Network Policies, Quotas und Ausnahmen Security policy
Architektur Layers, Umgebungen, Ressourcengruppen und wie die Teile zusammenhängen Architektur
Cluster baseline Node Pools, Upgrades, Add-ons, Identitäten des Clusters Cluster baseline
Networking Spoke-Layout, Egress, DNS, private endpoints, hub-Integration Networking
Identität und Zugriff Entra-ID-Gruppen, Azure- und Kubernetes-RBAC, CI/CD-Identitäten, Secrets Identität und Zugriff
Azure Local Was bei AKS auf Azure Local anders ist und was nicht verwaltet wird AKS auf Azure Local
Voraussetzungen Was vor einem Deployment existieren muss, pro Variante Voraussetzungen
Deployment pipelines, Konfigurationsdateien, Rollen der pipeline-Identität Deployment
Betrieb Upgrades, Start und Stopp, Alerting und Bereitschaft, bekannte Lücken Betrieb
Lasttests Wie die Plattform lastgetestet wird und was gemessen wird Lasttests
Entscheidungen Die wichtigsten Design-Entscheidungen in Kurzform Entscheidungen

Die Varianten im Überblick

AKS in Azure AKS auf Azure Local
Cluster-Ressource Terraform (azurerm_kubernetes_cluster) Azure-CLI-Bootstrap (az aksarc create), danach Arc-Extensions mit Terraform
Wo die Nodes laufen Azure Azure-Local-Hardware in deinem Rechenzentrum
Netzwerk VNet und Subnetze, von der Lösung gebaut oder vom hub bereitgestellt Vorhandenes logisches Netzwerk von Azure Local
Egress und DNS Route Table oder hub-firewall, Private DNS zones Dein physisches Netzwerk
Load Balancing Azure Load Balancer MetalLB, über Azure Arc aktiviert
Policy Azure-Policy-Add-on, dazu Kyverno aus GitOps Azure-Policy-Extension für Arc, dazu Kyverno aus GitOps
Secrets und Identität Key Vault, workload identity Key Vault, workload identity

Die Azure-Local-Variante ist neuer und weniger vollständig. Was automatisiert ist und was nicht, steht unter AKS auf Azure Local.

Verantwortlichkeiten

Plattform-Team Workload-Team
Terraform layers, Cluster baseline, Upgrades Ja
Entra-ID-Gruppen und Azure-Rollenzuweisungen Ja Stellt die Anfrage
Namespaces, Quotas, RBAC-Bindings, Policies Ja (über das GitOps-Repository) Stellt die Anfrage
Plattform-Services (Ingress Gateway, Monitoring, Zertifikate) Ja
Routen, Anwendungs-Deployments, Netzwerkregeln der Anwendung Ja
Container-Images und was die Anwendung mit ihren Secrets macht Ja

Die vollständige Tabelle steht unter Servicebeschreibung. Die allgemeine Aufteilung steht unter Verantwortlichkeiten.