Die App braucht mehr Kapazität? Deployment skalieren und Cluster Autoscaler aktivieren

#kubernetes #aks #scaling #cluster-autoscaler

Deine Anwendung benötigt mehr laufende Kopien für ihre Arbeit. Diese Kopien brauchen aber auch Platz im Cluster. Kubernetes-Skalierung hat zwei getrennte Ebenen:

Änderung	Was wächst?	Wer entscheidet hier?
Deployment skalieren	Anwendungs-Pods	Du änderst die gewünschte Anzahl von Replikaten
Cluster Autoscaler aktivieren	Worker-Nodes eines Node Pools	Der Autoscaler ergänzt Nodes, wenn geeignete Pods auf den vorhandenen Nodes nicht eingeplant werden können

Sechs Replikate bedeuten keine sechs VMs. Mehrere Pods können einen Node teilen, sofern ihre Ressourcenanforderungen und Platzierungsregeln es erlauben. Der Cluster Autoscaler ändert nicht die Replikatanzahl deines Deployments und ergänzt keine Nodes allein deshalb, weil ein CPU-Diagramm hohe Werte zeigt. Die automatische Anpassung der Anwendungsreplikate anhand von Metriken übernimmt ein Horizontal Pod Autoscaler (HPA). Diesen konfigurieren wir in diesem Trip nicht.

Verwende aks-ctlab-weu in UK West, den Namespace ct-apps und das Deployment ct-web aus dem Replikate-Trip. Starte den Cluster bei Bedarf. Nutze deine vorhandenen Berechtigungen für die AKS-Ressourcenverwaltung und Kubernetes-Administration. Dieses Lab setzt den ursprünglichen agentpool mit Standard_D4as_v6 und vier vCPUs pro Node voraus.

Anwendung im Portal skalieren

Öffne Kubernetes services → aks-ctlab-weu → Kubernetes resources → Workloads → Deployments. Filtere nach ct-apps und öffne ct-web.

Öffne die YAML-Ansicht und wähle bei Bedarf Edit. Ändere nur die gewünschte Replikatanzahl direkt unter dem obersten spec:

spec:
  replicas: 6

Dies ist ein Ausschnitt, der das zu ändernde Feld zeigt, kein vollständiges Manifest zum Ersetzen der Ressource. Lasse Pod-Vorlage, Image, Labels und Ressourcen unverändert und wähle Save oder Apply. Ändere weder status noch eine Annotation mit einer älteren Kopie des Manifests.

Aktualisiere das Deployment und warte auf 6 gewünschte / 6 bereite Replikate. Filtere unter Workloads → Pods nach ct-apps und prüfe die ct-web-…-Pods. Falls Orders- oder Gateway-Workloads aus dem vorherigen Trip vorhanden sind, erscheinen diese ebenfalls. Zähle nur die ct-web-Anwendungs-Pods.

Deployment ct-web mit sechs gewünschten und bereiten Replikaten.

Jeder ct-web-Container fordert 100m CPU und 64Mi Arbeitsspeicher an. Sechs Replikate fordern zusammen somit 0,6 CPU-Kerne und 384Mi Arbeitsspeicher an, zusätzlich zu den anderen Cluster-Workloads. Häufig passen sie auf die vorhandenen Nodes. Eine unveränderte Node-Anzahl ist dann zu erwarten.

Der vorhandene Service wählt weiterhin app: ct-web aus. Neue bereite Pods werden automatisch als Backends berücksichtigt. Service und HTTPRoute benötigen keine Änderung. Mehr Replikate können die Anwendungskapazität erhöhen, beseitigen aber keine Engpässe wie eine gemeinsam verwendete Datenbank.

Cluster Autoscaler aktivieren

Öffne aks-ctlab-weu → Settings → Node pools und wähle agentpool. Notiere die aktuelle Node-Anzahl und Skalierungseinstellungen. Wähle anschließend Scale und setze:

Scale method: Autoscale
Minimum node count: 2
Maximum node count: 3

Wähle Apply oder Save. Falls Autoscaling bereits aktiviert ist, prüfe und aktualisiere die vorhandenen Grenzen. Dieser Bereich setzt voraus, dass das kleine Lab derzeit zwei oder drei Nodes hat. Übertrage ihn nicht ohne Prüfung der Workloads auf einen größeren gemeinsam genutzten Pool.

Das Maximum ist eine Grenze und kein Auftrag, sofort drei Nodes anzulegen. Das Minimum verhindert eine Verkleinerung unter zwei Nodes. Drei Nodes dieser VM-Größe verwenden insgesamt 12 vCPUs; Upgrades können zusätzliches Kontingent benötigen. Prüfe unter Usage + quotas des Abonnements die Kontingente für UK West, einschließlich der passenden VM-Familie und der regionalen vCPUs. Ein zusätzlicher Node und seine Datenträger erhöhen die Kosten.

Konfiguriere die Skalierung am AKS Node Pool, nicht direkt am VM Scale Set in der Ressourcengruppe MC_. Behalte für dieses Lab die Standardwerte des clusterweiten Autoscaler-Profils bei.

AKS-Autoscaling für agentpool mit mindestens zwei und höchstens drei Nodes.

Optional: Das Hinzufügen eines Nodes beobachten

Mit den bisherigen Schritten hast du die Anwendung skaliert und Node-Autoscaling aktiviert. Für ein tatsächliches Scale-out-Ereignis brauchst du Pods, die auf den vorhandenen Nodes keinen Platz finden.

Dieser optionale Test ist für zwei aktuell vorhandene Nodes mit jeweils vier vCPUs ausgelegt. Hat dein Pool bereits drei Nodes, kann der Test ohne weiteren Node hineinpassen. Das ist kein Fehler. Erhöhe das Maximum nicht nur, um ein Ereignis zu erzwingen. Für den dritten Node müssen außerdem Kontingent und VM-Kapazität verfügbar sein.

Öffne Kubernetes resources → Services and ingresses → Create → Apply a YAML und wende das folgende Manifest an. Hat dein Node Pool einen anderen Namen, ersetze agentpool im Node-Selektor durch diesen Namen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ct-capacity-check
  namespace: ct-apps
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ct-capacity-check
  template:
    metadata:
      labels:
        app: ct-capacity-check
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        kubernetes.azure.com/agentpool: agentpool
      containers:
        - name: nginx
          image: nginx:stable-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "2"
              memory: 64Mi
            limits:
              cpu: "2"
              memory: 128Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 2
            periodSeconds: 5

Dies erstellt ein separates, temporäres Deployment. Seine drei Pods fordern jeweils zwei CPU-Kerne an, obwohl NGINX im Leerlauf wenig CPU verbraucht. Requests beeinflussen die Platzierung. Dies ist ein Test der Kapazitätsreservierung, kein CPU-Stresstest. Er ändert die Ressourcen von ct-web nicht und erhält keinen Traffic von dessen Service.

Zwei dieser Pods passen nicht gemeinsam auf einen AKS-Node mit vier vCPUs, weil ein Teil der CPU für den Node und Kubernetes reserviert ist. Bei nur zwei solchen Nodes findet daher mindestens ein Test-Pod zunächst keinen Platz. Wähle unter Workloads → Pods einen wartenden ct-capacity-check-…-Pod und prüfe Events. Erwarte eine Scheduling-Meldung wie Insufficient cpu.

Der Autoscaler kann daraufhin innerhalb des konfigurierten Maximums einen dritten Node anfordern. Öffne Node pools und prüfe Autoscale events, Autoscale warnings oder Scale-up not triggered, sofern angezeigt. Die Bereitstellung kann einige Minuten dauern. Sobald der neue Node Ready ist, kann der wartende Pod eingeplant werden. Prüfe, ob der Pool 3 Nodes und das Test-Deployment 3 bereite Replikate erreicht.

AKS Node Pool mit drei Nodes nach dem Scale-out durch den Kapazitätstest.

Bleiben Test-Pods Pending, prüfe ihre Events und die Autoscaler-Warnungen. Das erreichte Maximum, Kontingentgrenzen, fehlende VM-Kapazität, ein falscher Pool-Selektor oder die Ressourcenbelegung durch andere Workloads können die Platzierung verhindern. Zusätzliche Nodes beheben keinen Image-Pull-Fehler. Entferne den Test-Workload, wenn er nicht erfolgreich abgeschlossen werden kann, statt die Grenzen immer weiter zu erhöhen.

Lab zurücksetzen und Scale-down prüfen

Lösche nach dem Test nur ct-capacity-check unter Workloads → Deployments. Würdest du einzelne Pods löschen, würde das Deployment sie ersetzen.

Öffne erneut ct-web → YAML und setze das oberste spec.replicas zurück auf 3. Speichere und prüfe, ob drei Anwendungs-Pods bereit bleiben. Kubernetes entfernt die zusätzlichen Replikate. Der Service wählt weiterhin die verbleibenden bereiten Pods aus.

Der Cluster Autoscaler kann später einen nicht mehr benötigten Node entfernen. Das erfolgt jedoch nicht sofort. Standardwartezeiten und Workload-Einschränkungen gelten weiterhin. Pod Disruption Budgets oder System-Workloads können das Entfernen verhindern. Drei Nodes unmittelbar nach dem Aufräumen sind daher kein Fehlernachweis. Prüfe die Autoscaler-Ereignisse, statt eine Rückkehr auf zwei Nodes zu einem festen Zeitpunkt zu erwarten.

Behalte bei Bedarf Autoscaling mit Minimum 2 / Maximum 3 für weitere Übungen. Der Wechsel zu Manual beendet die automatische Node-Skalierung, garantiert aber für sich genommen keine Rückkehr auf zwei Nodes. Prüfe die tatsächliche Anzahl und den Bedarf der Workloads, bevor du eine manuelle Größe anwendest.

Stoppe den Cluster zwischen Sitzungen über Overview → Stop oder lösche seine Lab-Ressourcengruppe, wenn du AKS nicht mehr benötigst. Verbleibende Datenträger und Netzwerkressourcen können auch bei gestopptem Cluster Kosten verursachen.