Black Friday: de HPA gaat van vier naar twintig API-pods – groene grafiek, kalm team. De checkout-time-out is echter: PostgreSQL bereikt max_connections, Redis single-thread verzadigd. De nieuwe pods vermenigvuldigen verbindingen zonder de transactiecapaciteit te vergroten. Autoscaling “succesvol” aan de Kubernetes-kant, mislukking aan de zakelijke kant.
Het opschalen van pods lost staatloze knelpunten op. Het maakt stateful of gedeelde knelpunten vaak erger als niemand de volledige keten in kaart heeft gebracht. Voordat u iets automatiseert, moet u bepalen welke bron het eerst onder de piek komt (basis, makelaar, API van derden, uitgaande bandbreedte) en wie de bevoegdheid heeft om deze op te schalen.
HPA: de standaardstatistiek en zijn blinde vlekken
De Horizontal Pod Autoscaler vergelijkt een statistiek (CPU, geheugen, aangepaste statistiek) met een doel en wijzigt het aantal replica's. Op papier is het eenvoudig. In productie is de CPU slechts een onvolmaakte proxy voor de werkelijke belasting.
| Metrisch | Goed signaal wanneer | Slecht signaal wanneer |
|---|---|---|
| CPU-% | Intensief computergebruik (rendering, encryptie) | Wachten op schijf of database |
| Geheugen | Verbergen in pod | Lekkage verborgen door kalkaanslag |
| Verzoeken/s of latentie (aangepast) | Staatloze API | Stroomopwaartse verzadiging |
| Wachtrijdiepte (KEDA) | Asynchrone werknemers | Lijn zonder gezonde consumenten |
Zonder metrics-server en een Prometheus-adapter (of gelijkwaardig) blijft de HPA blind voor de business. Een pod kan twintig procent CPU laten zien terwijl hij wacht op een PostgreSQL-antwoord dat acht seconden vastzit. De maatstaf stijgt te laat – of helemaal niet.
Het toevoegen van pods op basis van honderd procent gebruikte verbindingen zorgt alleen maar voor meer wachtende klanten.
Om af te stappen van de standaard CPU, moet u signalen blootleggen die de gebruikerservaring weerspiegelen: latentie van het 95e percentiel op /api/checkout, lengte van de Redis-wachtrij, aantal berichten te laat op RabbitMQ. De HPA wordt alleen nuttig als de gekozen metriek correleert met de time-outs die onder belasting worden waargenomen.
VPA en formaat wijzigen vóór vermenigvuldigen
De Vertical Pod Autoscaler beveelt CPU-geheugenverzoeken en -limieten aan of dwingt deze af. Te lage verzoeken veroorzaken CPU-beperking en zorgen ervoor dat de HPA onnodig wordt geschaald. Te hoge verzoeken vullen de knooppunten: de nieuwe pods blijven in behandeling, het autoscaler-cluster wordt dringend geactiveerd en de factuur volgt.
Pragmatische workflow: stabiliseer eerst verzoeken (VPA in de “Uit”-modus om aanbevelingen te verzamelen) en schakel vervolgens HPA in op replica’s. Bewaak op een Europees beheerd cluster de kosten per node: een autoscaler-cluster zonder budgetwaarschuwing maakt van een verkeerspiek een verrassing aan het einde van de maand.
Cluster autoscaler en in behandeling zijnde pods
Wanneer de HPA pods maakt zonder ruimte op bestaande knooppunten, blijven deze in behandeling. Het autoscaler-cluster richt een knooppunt in, met een vertraging van enkele minuten (image downloaden, opstarten, opslaan). Gedurende deze tijd blijft er verkeer binnenkomen op bestaande pods, die al verzadigd zijn.
Anticipeer met een PodDisruptionBudget om een kritieke implementatie niet te belasten tijdens het terugschalen van een knooppunt. Plan meerdere knooppuntpools (algemeen versus intensief computergebruik) als uw belasting heterogeen is. Stel een maximale knooppuntlimiet in om een ongecontroleerde factuur te voorkomen tijdens een slecht geconfigureerde schaallus.
KEDA voor werknemers en bestanden
Symfony Messenger-werkers, Laravel-bestanden, Kafka-consumenten: het juiste signaal is vertraging of wachtrijdiepte, niet een CPU van vijftien procent terwijl duizenden berichten wachten. KEDA kan vanaf nul worden geschaald – praktisch voor batchladingen, maar wees voorzichtig met een koude start die niet compatibel is met een real-time beschikbaarheidsverplichting.
Documenteer de topologie van uitwisselingen en bestanden voordat u automatiseert. Een slecht bekabelde scaler in de verkeerde wachtrij schaalt werknemers op, terwijl de kritieke wachtrij elders groeit.
Stateful services: schaal niet blindelings automatisch
PostgreSQL, Elasticsearch, bepaalde Redis-implementaties: horizontaal schalen is niet triviaal. Soms is het antwoord een groter knooppunt (het aanpassen van de grootte van de virtuele machine), een leesreplica of een upstream-cache – niet meer API-pods die verbindingen vermenigvuldigen.
Breng de keten in kaart: welke hulpbron breekt als eerste bij duizend extra verzoeken per seconde? Meet tijdens de belastingstest voordat u de verkeerde hendel automatiseert. Automatisch schalen van Kubernetes is geen vervanging voor doordachte data-architectuur.
De top: de grafiek die ten onrechte geruststelt
De juiste vraag is niet “hoeveel peulen?” » maar “welke hulpbron gaat als eerste onder de piek – en wie schaalt deze op? »
Beslis en ga vooruit zonder blinde vlek
Begin met een belastingstest met statistieken per laag: applicatie, basis, makelaar, netwerk. Kies de juiste scaler (HPA, KEDA, cluster autoscaler) op basis van het signaal dat correleert met time-outs van gebruikers, en niet op basis van de gemakkelijkste statistiek om in een grafiek weer te geven. Stel maximale replica's, verstoringsbudgetten en latentiewaarschuwingen in het 95e percentiel in.
Vergelijk beheerde clusters en knooppuntpools via de overzicht en de vergelijker. De gidsen vervolledigen het cloudarchitectuurframework. Valideer onder belasting: als de latentie op het 95e percentiel stabiel blijft wanneer de replica's omhoog gaan, ligt het knelpunt ergens anders – en dat is waar u moet investeren.
Veelgestelde vragen
Is HPA op CPU voldoende in productie?
Zelden alleen. Een stabiele CPU kan een groeiende Redis-wachtrij of een database met uitgeputte verbindingen verbergen. Combineer applicatiestatistieken (wachtrijvertraging, verzoeken per seconde, latentie van het 95e percentiel) via de Prometheus-adapter of KEDA om te schalen op wat verband houdt met time-outs van gebruikers.
Wat is het verschil tussen HPA, VPA en autoscalercluster?
De HPA past het aantal podreplica's aan op basis van een doelstatistiek. De VPA beveelt CPU-geheugenverzoeken en -limieten aan of handhaaft deze. Het autoscaler-cluster voegt knooppunten toe wanneer peulen in behandeling blijven vanwege een gebrek aan bronnen op het bestaande cluster.
KEDA brengt wat vergeleken met de klassieke HPA?
KEDA biedt scalers op basis van bestandsdiepte, cron-triggers en externe statistieken. Voor asynchrone werkers zijn deze signalen vaak expressiever dan een lage gemiddelde CPU terwijl duizenden berichten wachten.
Hoe flapperen voorkomen?
Configureer stabilizationWindowSeconds, drempels met hysteresis, een afkoelingsvertraging tussen twee schaalgebeurtenissen en een realistisch minimum aan replica's. Zonder deze vangrails oscilleert en destabiliseert de HPA hardnekkige verbindingen.
Automatisch schalen volwassen schaalt de bron die de gebruiker in de steek laat, niet degene die zich al in Grafana bevindt.