For fuldt ud at mestre Kubernetes skal du kende forskellige måder at skalere klyngressourcer på: ved , dette er en af Kubernetes' hovedopgaver. Vi har givet et overblik på højt niveau over horisontal og lodret autoskalering og klyngeændringsmekanismer samt anbefalinger til, hvordan man bruger dem effektivt.
Artikel oversat af det team, der implementerede autoskalering .
Hvorfor det er vigtigt at tænke på skalering
- et værktøj til ressourcestyring og orkestrering. Det er selvfølgelig rart at pille ved de fede funktioner ved at implementere, overvåge og administrere pods (en pod er en gruppe containere, der lanceres som svar på en anmodning).
Du bør dog også tænke over følgende spørgsmål:
- Hvordan skalerer man moduler og applikationer?
- Hvordan holder man containere operationelle og effektive?
- Hvordan reagerer man på konstante ændringer i kode og arbejdsbelastninger fra brugere?
Konfiguration af Kubernetes-klynger til at balancere ressourcer og ydeevne kan være udfordrende og kræver ekspertviden om Kubernetes' indre funktion. Arbejdsbyrden for din applikation eller tjenester kan svinge i løbet af dagen eller endda i løbet af en time, så balancering opfattes bedst som en løbende proces.
Kubernetes autoskaleringsniveauer
Effektiv autoskalering kræver koordinering mellem to niveauer:
- Pod-niveau, herunder vandret (Horizontal Pod Autoscaler, HPA) og vertikal autoscaler (Vertical Pod Autoscaler, VPA). Dette skalerer de tilgængelige ressourcer til dine containere.
- Cluster-niveau, som administreres af Cluster Autoscaler (CA), som øger eller mindsker antallet af noder i klyngen.
Horisontal Autoscaler (HPA) modul
Som navnet antyder, skalerer HPA antallet af pod-replikaer. De fleste devops bruger CPU og hukommelsesbelastning som triggere til at ændre antallet af replikaer. Det er dog muligt at skalere systemet ud fra deres eller .
Driftsdiagram over HPA på højt niveau:
- HPA kontrollerer løbende de metriske værdier, der er angivet under installationen med et standardinterval på 30 sekunder.
- HPA'en forsøger at øge antallet af moduler, hvis den angivne tærskel er nået.
- HPA'en opdaterer antallet af replikaer i installations-/replikeringscontrolleren.
- Implementerings-/replikeringscontrolleren implementerer derefter eventuelle nødvendige yderligere moduler.
HPA starter modulimplementeringsprocessen, når en metrisk tærskel er nået
Når du bruger HPA, skal du overveje følgende:
- Standard HPA-tjekinterval er 30 sekunder. Det er sat af flaget horisontal-pod-autoscaler-sync-periode i controller manageren.
- Standard relativ fejl er 10 %.
- Efter den sidste stigning i antallet af moduler forventer HPA, at metrikken stabiliserer sig inden for tre minutter. Dette interval er sat af flaget horisontal-pod-autoscaler-upscale-delay.
- Efter den sidste reduktion i antallet af moduler venter HPA i fem minutter på at stabilisere sig. Dette interval er sat af flaget horisontal-pod-autoscaler-downscale-delay.
- HPA fungerer bedst med implementeringsobjekter frem for replikeringscontrollere. Horisontal autoskalering er inkompatibel med rullende opdatering, som direkte manipulerer replikeringscontrollere. Med implementering afhænger antallet af replikaer direkte af implementeringsobjekterne.
Lodret autoskalering af pods
Vertikal autoskalering (VPA) tildeler mere (eller mindre) CPU-tid eller hukommelse til eksisterende pods. Velegnet til stateful eller stateless pods, men primært beregnet til stateful services. Du kan dog også bruge VPA til statsløse moduler, hvis du automatisk skal justere mængden af oprindeligt allokerede ressourcer.
VPA reagerer også på OOM-hændelser (out of memory). Ændring af CPU-tid og -hukommelse kræver genstart af pods. Ved genstart respekterer VPA tildelingsbudgettet () for at garantere det mindst nødvendige antal moduler.
Du kan indstille minimum og maksimum ressourcer for hvert modul. Således kan du begrænse den maksimale mængde tildelt hukommelse til 8 GB. Dette er nyttigt, hvis de nuværende noder bestemt ikke kan allokere mere end 8 GB hukommelse pr. Detaljerede specifikationer og betjeningsmekanisme er beskrevet i .
Derudover har VPA en interessant anbefalingsfunktion (VPA Recommender). Den overvåger ressourceforbrug og OOM-hændelser for alle moduler for at foreslå nye hukommelses- og CPU-tidsværdier baseret på en intelligent algoritme baseret på historiske metrikker. Der er også en API, der tager et pod-håndtag og returnerer foreslåede ressourceværdier.
Det er værd at bemærke, at VPA Recommender ikke sporer ressource "grænse". Dette kan resultere i, at modulet monopoliserer ressourcer i knudepunkter. Det er bedre at sætte grænsen på navnerumsniveauet for at undgå stort hukommelses- eller CPU-forbrug.
VPA-driftsskema på højt niveau:
- VPA kontrollerer løbende de metriske værdier, der er angivet under installationen med et standardinterval på 10 sekunder.
- Hvis den specificerede tærskel er nået, forsøger VPA at ændre den tildelte mængde ressourcer.
- VPA'en opdaterer antallet af ressourcer i installations-/replikeringscontrolleren.
- Når moduler genstartes, anvendes alle nye ressourcer på de oprettede forekomster.
VPA tilføjer den nødvendige mængde ressourcer
Vær venligst opmærksom på følgende punkter, når du bruger VPA:
- Skalering kræver en obligatorisk genstart af poden. Dette er nødvendigt for at undgå ustabil drift efter ændringer. For pålidelighed genstartes moduler og fordeles på tværs af noder baseret på nyligt allokerede ressourcer.
- VPA og HPA er endnu ikke kompatible med hinanden og kan ikke køre på de samme pods. Hvis du bruger begge skaleringsmekanismer i den samme klynge, skal du sørge for, at dine indstillinger forhindrer dem i at blive aktiveret på de samme objekter.
- VPA tuner containeranmodninger om ressourcer kun baseret på tidligere og nuværende brug. Den sætter ikke grænser for ressourceforbrug. Der kan være problemer med applikationer, der ikke fungerer korrekt og begynder at overtage flere og flere ressourcer, dette vil føre til, at Kubernetes slår denne pod fra.
- VPA er stadig på et tidligt udviklingsstadium. Vær forberedt på, at systemet kan undergå nogle ændringer i den nærmeste fremtid. Du kan læse om и . Der er således planer om at implementere den fælles drift af VPA og HPA, samt udrulning af moduler sammen med en vertikal autoskaleringspolitik for dem (f.eks. et særligt mærke "kræver VPA").
Autoskalering af en Kubernetes-klynge
Cluster Autoscaler (CA) ændrer antallet af noder baseret på antallet af ventende pods. Systemet tjekker periodisk for ventende moduler - og øger klyngestørrelsen, hvis der er behov for flere ressourcer, og hvis klyngen ikke overskrider de fastsatte grænser. CA'en kommunikerer med cloud-tjenesteudbyderen, anmoder om yderligere noder fra den eller frigiver inaktive. Den første almindeligt tilgængelige version af CA blev introduceret i Kubernetes 1.8.
System på højt niveau for SA-drift:
- CA kontrollerer for ventende moduler med et standardinterval på 10 sekunder.
- Hvis en eller flere pods er i standbytilstand, fordi klyngen ikke har nok tilgængelige ressourcer til at allokere dem, forsøger den at klargøre en eller flere yderligere noder.
- Når cloud-tjenesteudbyderen tildeler den nødvendige node, slutter den sig til klyngen og er klar til at betjene pods.
- Kubernetes-planlæggeren distribuerer ventende pods til en ny node. Hvis nogle moduler efter dette stadig forbliver i en ventetilstand, gentages processen, og nye noder tilføjes til klyngen.
Automatisk levering af klynge noder i skyen
Overvej følgende, når du bruger CA:
- CA sikrer, at alle pods i klyngen har plads til at køre, uanset CPU-belastning. Den forsøger også at sikre, at der ikke er unødvendige noder i klyngen.
- CA registrerer behovet for skalering efter ca. 30 sekunder.
- Når en node ikke længere er nødvendig, vil CA som standard vente 10 minutter, før systemet skaleres ud.
- Autoskaleringssystemet har konceptet ekspandere. Dette er forskellige strategier til at vælge en gruppe af noder, som nye noder vil blive tilføjet.
- Brug muligheden ansvarligt cluster-autoscaler.kubernetes.io/safe-to-evict (true). Hvis du installerer mange pods, eller hvis mange af dem er spredt ud over alle noderne, vil du stort set miste evnen til at skalere klyngen ud.
- brug for at forhindre pods i at blive slettet, hvilket kan få dele af din applikation til at gå helt i stykker.
Hvordan Kubernetes autoscalere interagerer med hinanden
For perfekt harmoni bør autoskalering anvendes på både pod-niveau (HPA/VPA) og klyngeniveau. De interagerer relativt enkelt med hinanden:
- HPA'er eller VPA'er opdaterer pod-replikaer eller ressourcer, der er allokeret til eksisterende pods.
- Hvis der ikke er nok noder til den planlagte skalering, bemærker CA tilstedeværelsen af pods i en ventetilstand.
- CA'en tildeler nye knudepunkter.
- Moduler distribueres til nye noder.
Samarbejdsbaseret Kubernetes-udskaleringssystem
Almindelige fejl i Kubernetes autoskalering
Der er flere almindelige problemer, som devops støder på, når du forsøger at implementere autoskalering.
HPA og VPA afhænger af metrikker og nogle historiske data. Hvis der ikke allokeres tilstrækkelige ressourcer, vil modulerne blive minimeret og vil ikke være i stand til at generere metrics. I dette tilfælde vil autoskalering aldrig ske.
Selve skaleringsoperationen er tidsfølsom. Vi ønsker, at modulerne og klyngen skal skaleres hurtigt - før brugerne opdager problemer eller fejl. Derfor bør den gennemsnitlige skaleringstid for pods og klyngen tages i betragtning.
Ideelt scenario - 4 minutter:
- 30 sekunder. Opdater målmålinger: 30-60 sekunder.
- 30 sekunder. HPA kontrollerer metriske værdier: 30 sekunder.
- Mindre end 2 sekunder. Pods oprettes og går i ventetilstand: 1 sekund.
- Mindre end 2 sekunder. CA ser ventemoduler og sender opkald til klargøringsnoder: 1 sekund.
- 3 minutter. Skyudbyderen tildeler noder. K8s venter, indtil de er klar: op til 10 minutter (afhængigt af flere faktorer).
Worst case (mere realistisk) scenarie - 12 minutter:
- 30 sekunder. Opdater mål-metrics.
- 30 sekunder. HPA kontrollerer de metriske værdier.
- Mindre end 2 sekunder. Poderne oprettes og går i standbytilstand.
- Mindre end 2 sekunder. CA'en ser de ventende moduler og foretager opkald til klargøring af noderne.
- 10 minutter. Skyudbyderen tildeler noder. K8s venter, indtil de er klar. Ventetiden afhænger af flere faktorer, såsom leverandørforsinkelse, OS-forsinkelse og supportværktøjer.
Du må ikke forveksle cloud-udbyderes skaleringsmekanismer med vores CA. Sidstnævnte kører inde i en Kubernetes-klynge, mens cloud-udbydermotoren fungerer på nodedistributionsbasis. Den ved ikke, hvad der sker med dine pods eller applikation. Disse systemer fungerer parallelt.
Sådan administrerer du skalering i Kubernetes
- Kubernetes er et ressourcestyrings- og orkestreringsværktøj. Operationer til styring af pods og klyngressourcer er en vigtig milepæl i at mestre Kubernetes.
- Forstå logikken bag pod-skalerbarhed under hensyntagen til HPA og VPA.
- CA bør kun bruges, hvis du har en god forståelse af behovene for dine pods og beholdere.
- For at konfigurere en klynge optimalt skal du forstå, hvordan forskellige skaleringssystemer arbejder sammen.
- Når du estimerer skaleringstid, skal du huske worst-case og best-case scenarier.
Kilde: www.habr.com