Azure Kubernetes Service: Best Practices für Production
Zurück zum Blog
von Stefan Sørensen

Azure Kubernetes Service: Best Practices für Production

Erfahren Sie, wie Sie AKS erfolgreich in Production betreiben - von Cluster-Setup bis Security Hardening.

AzureKubernetesDevOps

Azure Kubernetes Service (AKS) ist eine der beliebtesten Managed-Kubernetes-Lösungen auf dem Markt. Als Cloud-Architect, der AKS täglich in Production-Umgebungen einsetzt, zeige ich Ihnen in diesem Artikel die wichtigsten Best Practices – von der initialen Cluster-Konfiguration bis hin zu Security Hardening und Observability.

1. Cluster-Konfiguration

Node Pools richtig konfigurieren

Ein gut strukturiertes Node-Pool-Design ist das Fundament eines stabilen AKS-Clusters. Die Trennung von System- und User Node Pools verhindert, dass Anwendungs-Workloads kritische Kubernetes-System-Pods verdrängen.

  • System Node Pool: Ausschließlich für Kubernetes-System-Pods (CoreDNS, kube-proxy etc.) – mindestens 2 Nodes für HA
  • User Node Pools: Separate Pools je Workload-Typ (z. B. CPU-intensiv vs. speicherintensiv)
  • Autoscaling aktivieren: Cluster Autoscaler pro Node Pool konfigurieren
az aks nodepool add \
  --cluster-name myAKSCluster \
  --resource-group myResourceGroup \
  --name userpool \
  --node-count 2 \
  --min-count 1 \
  --max-count 10 \
  --enable-cluster-autoscaler \
  --mode User

Resource Requests & Limits setzen

Fehlende oder falsch konfigurierte Resource Requests und Limits sind einer der häufigsten Gründe für Produktionsausfälle in AKS. Ohne diese kann der Cluster Autoscaler keine fundierten Skalierungsentscheidungen treffen.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Pod Disruption Budgets (PDB)

Definieren Sie PDBs für alle kritischen Deployments, um sicherzustellen, dass während Node-Upgrades oder Skalierungsvorgängen stets eine Mindestanzahl von Pods verfügbar bleibt.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Namespaces zur Isolation nutzen

Verwenden Sie nie den default-Namespace für Production-Workloads. Strukturieren Sie Ihre Workloads durch dedizierte Namespaces, um RBAC und Network Policies granular anwenden zu können.

2. Security

Azure Entra ID Integration & RBAC

Integrieren Sie AKS mit Microsoft Entra ID (ehemals Azure AD) für zentrales Identity Management mit MFA und Conditional Access. Das eliminiert statische kubeconfig-Dateien, die schwer zu rotieren sind und gestohlen werden können.

az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-azure-rbac \
  --enable-aad \
  --aad-admin-group-object-ids <group-object-id>

Wichtig: Beschränken Sie cluster-admin-Zugriff auf ein Minimum. Übermäßige Nutzung dieser Rolle schafft ein Single Point of Failure und erhöht das Insider-Risiko.

Privater Cluster & API Server Absicherung

Stellen Sie AKS als Private Cluster bereit, damit der Management-Traffic zum API Server ausschließlich über das private Netzwerk läuft. Für nicht-private Cluster sollten Sie mindestens Authorized IP Ranges konfigurieren.

az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-private-cluster \
  --network-plugin azure

Network Policies

Implementieren Sie Network Policies, um den Traffic zwischen Pods nach dem Zero-Trust-Prinzip zu kontrollieren. Ohne Network Policies kann jeder Pod mit jedem anderen Pod kommunizieren – ein erhebliches Sicherheitsrisiko.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
***
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Empfehlung: Verwenden Sie Azure CNI statt Kubenet in Production – Azure CNI integriert Pods direkt in das VNET und erlaubt feingranulare NSG-Kontrollen.

Workload Identity (kein Service Principal!)

Ersetzen Sie Service Principals durch Azure Workload Identity (früher aad-pod-identity). So entfällt das Rotieren von Secrets komplett.

az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-oidc-issuer \
  --enable-workload-identity

Pod Security Standards

Aktivieren Sie Pod Security Standards (baseline oder restricted) auf Namespace-Ebene, um gefährliche Konfigurationen wie privilegierte Container oder Host-Namespace-Sharing zu blockieren.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Secrets Management mit Azure Key Vault

Speichern Sie Secrets niemals direkt in Kubernetes – diese sind in etcd lediglich Base64-kodiert. Nutzen Sie stattdessen den Azure Key Vault Provider for Secrets Store CSI Driver.

az aks enable-addons \
  --addons azure-keyvault-secrets-provider \
  --name myAKSCluster \
  --resource-group myResourceGroup

Microsoft Defender for Containers

Aktivieren Sie Defender for Containers für Runtime-Bedrohungsschutz, Schwachstellenscanning von Container-Images in der ACR und Kubernetes-Audit-Log-Analyse.

az security pricing create -n Containers --tier Standard

3. Monitoring & Logging

Container Insights + Managed Prometheus

Für eine vollständige Observability-Lösung kombinieren Sie Azure Container Insights (Log Analytics) mit Managed Prometheus und Azure Managed Grafana. Diese drei Komponenten lassen sich beim Cluster-Erstellen direkt über den Portal-Tab „Integrations" aktivieren.

# Managed Prometheus aktivieren
az aks update \
  --enable-azure-monitor-metrics \
  --name myAKSCluster \
  --resource-group myResourceGroup

# Container Insights aktivieren
az aks enable-addons \
  --addon monitoring \
  --name myAKSCluster \
  --resource-group myResourceGroup \
  --workspace-resource-id "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace>"

Alerting für kritische Events

Konfigurieren Sie Alerts für risikoreiche Events – zum Beispiel die Erstellung privilegierter Pods oder öffentlicher Load Balancer. So können Sie reagieren, bevor Angreifer eine Fehlkonfiguration ausnutzen.

Empfohlene Alert-Regeln in Azure Monitor:

  • Node Not Ready
  • OOMKilled-Pods (Out of Memory)
  • Persistent Volume nahezu voll
  • Hohe API-Server-Latenz
  • Fehlgeschlagene Deployments

API Server Audit Logs

Aktivieren Sie Diagnostic Settings, um API-Server-Audit-Logs an Log Analytics zu senden. Diese Logs zeigen, wer wann was im Cluster getan hat – unverzichtbar für forensische Untersuchungen und Compliance.

az monitor diagnostic-settings create \
  --name AKSAuditLogs \
  --resource <aks-resource-id> \
  --workspace <log-analytics-workspace-id> \
  --logs '[{"category":"kube-audit","enabled":true}]'

4. Upgrades & Lifecycle Management

Automatische Upgrades konfigurieren

Halten Sie AKS und Node Pools aktuell – veraltete Cluster enthalten ungepatchte Schwachstellen. Nutzen Sie den Auto-Upgrade-Channel für kontrollierte, automatisierte Updates.

az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --auto-upgrade-channel stable \
  --node-os-upgrade-channel SecurityPatch

Maintenance Windows

Definieren Sie Maintenance Windows, um Upgrades auf wartungsfreundliche Zeitfenster zu beschränken – insbesondere wichtig in Production-Umgebungen mit SLA-Anforderungen.

5. Cost Optimization

Spot Node Pools für nicht-kritische Workloads

Für batch-artige oder unterbrechbare Workloads (CI/CD-Runner, Datenverarbeitung) bieten Spot Node Pools Einsparungen von bis zu 90% gegenüber regulären VMs.

az aks nodepool add \
  --cluster-name myAKSCluster \
  --resource-group myResourceGroup \
  --name spotpool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-count 0 \
  --min-count 0 \
  --max-count 5 \
  --enable-cluster-autoscaler

Vertical Pod Autoscaler (VPA)

Ergänzend zum Horizontal Pod Autoscaler (HPA) hilft der Vertical Pod Autoscaler dabei, Resource Requests kontinuierlich zu optimieren und Über- bzw. Unterprovisioning zu vermeiden.

Fazit: AKS Production Readiness Checklist

Bereich Maßnahme Priorität
Cluster-Setup System/User Node Pool Trennung 🔴 Kritisch
Security Entra ID Integration + RBAC 🔴 Kritisch
Security Privater Cluster oder Authorized IPs 🔴 Kritisch
Security Workload Identity statt Service Principal 🔴 Kritisch
Security Network Policies (Zero Trust) 🔴 Kritisch
Security Key Vault für Secrets 🟠 Hoch
Security Defender for Containers 🟠 Hoch
Monitoring Container Insights + Managed Prometheus 🔴 Kritisch
Monitoring Alert Rules für kritische Events 🟠 Hoch
Monitoring API Audit Logs 🟠 Hoch
Lifecycle Auto-Upgrade Channel konfigurieren 🟠 Hoch
Kosten Spot Pools für Batch-Workloads 🟡 Mittel

Mit diesen Best Practices ist Ihr AKS-Cluster production-ready – sicher, beobachtbar und kosteneffizient. Die Kombination aus Microsoft-nativen Tools (Defender, Container Insights, Key Vault) und Kubernetes-Bordmitteln (RBAC, Network Policies, PDBs) bildet eine solide Grundlage für jeden Enterprise-Einsatz.

Stefan Sørensen
Stefan Sørensen
Cloud Enterprise Architect
← Alle Artikel