Azure Kubernetes Service
AUTORITATIVE ANLEITUNG — VERPFLICHTENDE EINHALTUNG
Diese Kompetenz erstellt eine empfohlene AKS-Clusterkonfiguration basierend auf den Benutzeranforderungen und unterscheidet zwischen Day-0-Entscheidungen (Netzwerk, API-Server – später schwer änderbar) und Day-1-Funktionen (nach der Erstellung aktivierbar). Siehe CLI-Referenz für Befehle.
Kurzreferenz
| Eigenschaft | Wert |
|---|---|
| Geeignet für | AKS-Clusterplanung und Day-0-Entscheidungen |
| MCP-Tools | mcp_azure_mcp_aks |
| CLI | az aks create, az aks show, kubectl get, kubectl describe |
| Verwandte Kompetenzen | azure-diagnostics (Fehlerbehebung AKS), azure-validate (Bereitschaftsprüfungen) |
Wann diese Kompetenz verwendet werden soll
Aktivieren Sie diese Kompetenz, wenn der Benutzer Folgendes möchte:
- Einen neuen AKS-Cluster erstellen
- Eine AKS-Clusterkonfiguration für Produktionsworkloads planen
- AKS-Netzwerke entwerfen (API-Server-Zugriff, Pod-IP-Modell, Egress)
- AKS-Identitäts- und Geheimnisverwaltung einrichten
- AKS-Governance konfigurieren (Azure Policy, Deployment Safeguards)
- AKS-Überwachbarkeit aktivieren (Container Insights, Managed Prometheus, Grafana)
- Eine AKS-Upgrade- und Patchstrategie festlegen
- AKS-Kostentransparenz und -analyse aktivieren
- Die Unterschiede zwischen AKS Automatic und Standard-SKU verstehen
- Eine Day-0-Checkliste für die AKS-Cluster-Einrichtung und -Konfiguration erhalten
Regeln
- Beginnen Sie mit den Anforderungen des Benutzers für die Bereitstellung von Compute, Netzwerk, Sicherheit und anderen Einstellungen.
- Verwenden Sie zuerst den
azureMCP-Server und wählen Siemcp_azure_mcp_aksaus, um die genauen AKS-spezifischen MCP-Tools zu entdecken, die vom Client bereitgestellt werden. Wählen Sie das kleinste entdeckte AKS-Tool, das für die Aufgabe geeignet ist, und greifen Sie nur dann auf die Azure CLI (az aks) zurück, wenn die benötigte Funktionalität nicht über die AKS-MCP-Oberfläche verfügbar ist. - Bestimmen Sie, ob AKS Automatic oder Standard-SKU basierend auf dem Benutzerbedarf an Kontrolle vs. Komfort angemessener ist. Standardmäßig zu AKS Automatic wechseln, sofern nicht bestimmte Anpassungen erforderlich sind.
- Dokumentieren Sie Entscheidungen und Begründungen für Clusterkonfigurationsentscheidungen, insbesondere bei Day-0-Entscheidungen, die später schwer zu ändern sind (Netzwerk, API-Server-Zugriff).
Erforderliche Eingaben (Nur das Nötigste fragen)
Wenn der Benutzer unsicher ist, verwenden Sie sichere Standardwerte.
- AKS-Umgebungstyp: dev/test oder Produktion
- Region(en), Verfügbarkeitszonen, bevorzugte Node-VM-Größen
- Erwartete Skalierung (Node-/Cluster-Anzahl, Workload-Größe)
- Netzwerkanforderungen (API-Server-Zugriff, Pod-IP-Modell, Ingress/Egress-Kontrolle)
- Sicherheits- und Identitätsanforderungen, einschließlich Image-Registry
- Upgrade- und Überwachbarkeitspräferenzen
- Kosteneinschränkungen
Arbeitsablauf
1. Clustertyp
- AKS Automatic (Standard): Am besten für die meisten Produktionsworkloads geeignet, bietet eine kuratierte Erfahrung mit vorkonfigurierten Best Practices für Sicherheit, Zuverlässigkeit und Leistung. Verwenden Sie diesen, es sei denn, Sie haben spezifische individuelle Anforderungen an Netzwerk, Autoscaling oder Node-Pool-Konfigurationen, die von Node Auto-Provisioning (NAP) nicht unterstützt werden.
- AKS Standard: Verwenden Sie diesen, wenn Sie die vollständige Kontrolle über die Umgebungskonfiguration benötigen, was zusätzlichen Aufwand für die Einrichtung und Verwaltung erfordert.
2. Netzwerk (Pod-IP, Egress, Ingress, Dataplane)
Pod-IP-Modell (Wichtige Day-0-Entscheidung):
- Azure CNI Overlay (empfohlen): Pod-IPs aus privatem Overlay-Bereich, nicht VNet-routbar, skaliert auf große Umgebungen und gut für die meisten Workloads geeignet
- Azure CNI (VNet-routbar): Pod-IPs direkt aus dem VNet (Pod-Subnetz oder Node-Subnetz), verwenden, wenn Pods direkt aus dem VNet oder On-Premises adressierbar sein müssen
- Dokumentation: https://learn.microsoft.com/azure/aks/azure-cni-overlay
Dataplane & Netzwerkrichtlinie:
- Azure CNI unterstützt durch Cilium (empfohlen): eBPF-basiert für Hochleistungs-Paketverarbeitung, Netzwerkrichtlinien und Überwachbarkeit
Egress:
- Static Egress Gateway für stabile, vorhersagbare ausgehende IPs
- Für eingeschränkten Egress: UDR + Azure Firewall oder NVA
Ingress:
- App Routing Addon mit Gateway API — empfohlener Standard für HTTP/HTTPS-Workloads
- Istio Service Mesh mit Gateway API - für fortgeschrittenes Traffic-Management, mTLS, Canary-Releases
- Application Gateway for Containers — für L7-Lastenausgleich mit WAF-Integration
DNS:
- LocalDNS auf allen Node-Pools aktivieren für zuverlässige, leistungsstarke DNS-Auflösung
3. Sicherheit
- Überall Microsoft Entra ID verwenden (Steuerungsebene, Workload Identity für Pods, Node-Zugriff). Statische Anmeldeinformationen vermeiden.
- Azure Key Vault über Secrets Store CSI Driver für Geheimnisse
- Azure Policy + Deployment Safeguards aktivieren
- Verschlüsselung ruhender Daten für etcd/API-Server aktivieren; Übertragungsverschlüsselung für Node-zu-Node
- Nur signierte, richtliniengeprüfte Images zulassen (Azure Policy + Ratify), bevorzugt Azure Container Registry
- Isolation: Namespaces, Netzwerkrichtlinien, begrenztes Logging verwenden
4. Überwachbarkeit
- Managed Prometheus und Container Insights mit Grafana für AKS-Überwachbarkeit (Logs + Metriken) verwenden.
- Diagnoseeinstellungen aktivieren, um Steuerungsebene-Logs und Audit-Logs in einem Log Analytics-Arbeitsbereich für Sicherheitsüberwachung und Fehlerbehebung zu sammeln.
- Für andere Überwachungs- und Fehlerbehebungstools Funktionen wie die Agentic CLI für AKS, Application Insights, Resource Health Center, AppLens-Detektoren und Azure Advisors verwenden.
5. Upgrades & Patching
- Wartungsfenster für kontrollierte Upgrade-Zeitpunkte konfigurieren
- Auto-Upgrades für Steuerungsebene und Node-Betriebssystem aktivieren, um mit Sicherheitspatches und Kubernetes-Versionen auf dem neuesten Stand zu bleiben
- LTS-Versionen für Unternehmensstabilität (2-Jahres-Support) in Betracht ziehen, indem die AKS-Umgebung auf die Premium-Stufe aktualisiert wird
- Fleet-Upgrades: AKS Fleet Manager für gestaffelte Rollouts über Test- bis Produktionsumgebungen verwenden
6. Leistung
- Ephemerale Betriebssystem-Datenträger (
--node-osdisk-type Ephemeral) für schnelleren Node-Start verwenden - Azure Linux als Node-Betriebssystem auswählen (kleinerer Fußabdruck, schnellerer Start)
- KEDA für ereignisgesteuertes Autoscaling über HPA hinaus aktivieren
7. Node-Pools & Compute
- Dedizierter System-Node-Pool: Mindestens 2 Nodes, nur für System-Workloads getaint (
CriticalAddonsOnly) - Node Auto Provisioning (NAP) auf allen Pools aktivieren für Kosteneinsparungen und reaktionsschnelle Skalierung
- Neueste Generation SKUs (v5/v6) für Host-Level-Optimierungen verwenden
- B-Serie-VMs vermeiden — Burstable-SKUs verursachen Leistungs-/Zuverlässigkeitsprobleme
- SKUs mit mindestens 4 vCPUs für Produktionsworkloads verwenden
- Topologie-Verteilungseinschränkungen festlegen, um Pods gemäß SLO über Hosts/Zonen zu verteilen
8. Zuverlässigkeit
- Über 3 Verfügbarkeitszonen bereitstellen (
--zones 1 2 3) - Standard-Tarif für zoneredundante Steuerungsebene + 99,95 % SLA für API-Serververfügbarkeit verwenden
- Microsoft Defender for Containers für Laufzeitschutz aktivieren
- PodDisruptionBudgets für alle Produktionsworkloads konfigurieren
- Topologie-Verteilungseinschränkungen verwenden, um Pod-Verteilung über Fehlerdomänen sicherzustellen
9. Kostenkontrolle
- Spot-Node-Pools für Batch-/unterbrechbare Workloads verwenden (bis zu 90 % Einsparungen)
- Stoppen/Starten von Dev/Test-Clustern:
az aks stop/start - Reservierte Instanzen oder Savings Plans für stationäre Workloads in Betracht ziehen
Leitplanken / Sicherheit
- Keine Geheimnisse (Token, Schlüssel) anfordern oder ausgeben.
- Wenn Anforderungen für kritische Day-0-Entscheidungen mehrdeutig sind, stellen Sie dem Benutzer klärende Fragen. Für Day-1-fähige Funktionen schlagen Sie 2–3 sichere Optionen mit Kompromissen vor und wählen Sie eine konservative Standardeinstellung.
- Keine Null-Ausfallzeit versprechen; Workload-Sicherheitsvorkehrungen (PDBs, Probes, Replicas) und gestaffelte Upgrades zusammen mit Best Practices für Zuverlässigkeit und Leistung empfehlen.
MCP-Tools
| Tool | Zweck | Wichtige Parameter |
|---|---|---|
mcp_azure_mcp_aks | AKS-MCP-Einstiegspunkt, um die genauen AKS-spezifischen Tools des Clients zu entdecken | Zuerst das aufrufbare AKS-Tool entdecken, dann dessen Parameter verwenden |
Fehlerbehandlung
| Fehler / Symptom | Wahrscheinliche Ursache | Abhilfe |
|---|---|---|
| MCP-Toolaufruf fehlschlägt oder timeout | Ungültige Anmeldeinformationen, Abonnement oder AKS-Kontext | az login überprüfen, den aktiven Abonnementkontext mit az account show bestätigen und die Zielressourcengruppe prüfen, ohne Abonnementkennungen an den Benutzer zurückzugeben |
| Kontingent überschritten | Regionale vCPU- oder Ressourcengrenzen | Kontingenterhöhung anfordern oder andere Region/VM-SKU auswählen |
| Netzwerkkonflikt (IP-Erschöpfung) | Pod-Subnetz zu klein für Overlay/CNI | IP-Bereiche neu planen; möglicherweise Cluster-Neuerstellung erforderlich (Day-0) |
| Workload Identity funktioniert nicht | Fehlender OIDC-Aussteller oder föderierte Anmeldeinformation | --enable-oidc-issuer --enable-workload-identity aktivieren, föderierte Identität konfigurieren |