Der Worker kladde-worker hat wenig zu tun: nach dem nächtlichen Abruf und wenn jemand eine Kontaktliste hochlädt. Den Rest der Zeit wartet er auf eine leere Warteschlange und belegt einen Pod mit Speicher und CPU-Anforderung. In Lektion 3.5.7 haben Sie dasselbe Problem auf Container Apps gelöst: Der Worker wächst mit der Länge der Warteschlange und schrumpft auf null. Diese Lektion zeigt, wie das auf Kubernetes aussieht. Die Frage: Wie skaliert ein Deployment nach der Länge einer Service-Bus-Warteschlange, bis auf null, ohne dass irgendwo ein Schlüssel steht?

Was KEDA auf Container Apps ist, was pollingInterval, cooldownPeriod und messageCount bedeuten und wie ein Worker sauber beendet wird, steht in Lektion 3.5.7 und wird hier nicht wiederholt. Hier geht es um das, was Kubernetes anders macht: Objekte statt Bicep-Felder, ein eigener Weg für die Anmeldung und ein Nachbar, mit dem KEDA sich nicht verträgt.

Der Horizontal Pod Autoscaler

Kubernetes bringt eine eigene Skalierung mit: den Horizontal Pod Autoscaler (HPA). Er ist eine Regelschleife und rechnet im Takt der Steuerungsebene (voreingestellt alle 15 Sekunden) aus, wie viele Repliken ein Deployment braucht. Der Kern der Rechnung:

gewünschte Repliken = aufrunden( aktuelle Repliken × aktueller Messwert / Zielwert )

Woher der Messwert kommt, ist die entscheidende Frage:

Art des Messwerts Quelle Beispiel
Ressourcenwert je Pod die Schnittstelle metrics.k8s.io, meist vom Metrics Server CPU-Auslastung in Prozent der Anforderung (requests) des Containers
eigener Wert je Pod custom.metrics.k8s.io Anfragen pro Sekunde je Pod
Wert eines Objekts oder von außen custom.metrics.k8s.io, external.metrics.k8s.io die Länge einer Warteschlange

Für den Web-Teil der Kladde ist die CPU-Auslastung ein guter Messwert: Mehr Anfragen heißt mehr CPU. Für den Worker ist sie ein schlechter. Ein Worker, der auf Nachrichten wartet, braucht keine CPU, und einer, der 5.000 Nachrichten in der Warteschlange hat, kann zugleich ein Minimum davon verbrauchen, wenn er auf eine Datenbank wartet. Was ihn wirklich beschreibt, ist die Warteschlange: ein Wert von außen, den der HPA nur über eine Schnittstelle für externe Messwerte lesen kann. Dafür braucht es etwas, das die Warteschlange fragt und die Antwort an diese Schnittstelle liefert.

Ein HPA ab Kubernetes 1.37 kann bei Objekt- und externen Messwerten auf null Repliken gehen (minReplicas: 0; Beta, standardmäßig eingeschaltet). Bei Ressourcenwerten geht es nie, weil sie sich nur an laufenden Pods messen lassen. Der HPA allein hilft Ihnen trotzdem nicht weiter, denn er liest die Warteschlange nicht selbst.