Om Kubernetes volledig onder de knie te krijgen, moet u verschillende manieren kennen om clusterbronnen te schalen: door , dit is een van de hoofdtaken van Kubernetes. We hebben een overzicht op hoog niveau gegeven van mechanismen voor horizontale en verticale automatische schaling en clustergrootte, evenals aanbevelingen over hoe u deze effectief kunt gebruiken.
Artikel vertaald door het team dat autoscaling heeft geïmplementeerd .
Waarom het belangrijk is om na te denken over schaalvergroting
- een hulpmiddel voor resourcebeheer en orkestratie. Natuurlijk is het leuk om te sleutelen aan de coole functies van het inzetten, monitoren en beheren van pods (een pod is een groep containers die worden gelanceerd als reactie op een verzoek).
U moet echter ook nadenken over de volgende vragen:
- Hoe modules en applicaties schalen?
- Hoe houden we containers operationeel en efficiënt?
- Hoe kunt u reageren op constante veranderingen in code en werklasten van gebruikers?
Het configureren van Kubernetes-clusters om resources en prestaties in evenwicht te brengen kan een uitdaging zijn en vereist deskundige kennis van de interne werking van Kubernetes. De werklast van uw applicatie of services kan gedurende de dag of zelfs in de loop van een uur fluctueren, dus het balanceren kan het beste worden gezien als een continu proces.
Kubernetes automatische schalingsniveaus
Effectieve automatische schaling vereist coördinatie tussen twee niveaus:
- Pod-niveau, inclusief horizontaal (Horizontal Pod Autoscaler, HPA) en verticale autoscaler (Vertical Pod Autoscaler, VPA). Hiermee schaalt u de beschikbare bronnen voor uw containers.
- Clusterniveau, dat wordt beheerd door de Cluster Autoscaler (CA), die het aantal knooppunten binnen het cluster verhoogt of verlaagt.
Horizontale Autoscaler (HPA)-module
Zoals de naam al doet vermoeden, schaalt HPA het aantal podreplica's. De meeste ontwikkelaars gebruiken CPU- en geheugenbelasting als triggers voor het wijzigen van het aantal replica's. Het is echter mogelijk om het systeem op te schalen op basis van , hen of .
HPA-bedrijfsdiagram op hoog niveau:
- De HPA controleert voortdurend de tijdens de installatie opgegeven metrische waarden met een standaardinterval van 30 seconden.
- De HPA probeert het aantal modules te vergroten als de opgegeven drempel wordt bereikt.
- De HPA werkt het aantal replica's binnen de implementatie-/replicatiecontroller bij.
- De implementatie-/replicatiecontroller implementeert vervolgens alle noodzakelijke aanvullende modules.
HPA start het module-implementatieproces wanneer een metrische drempel wordt bereikt
Houd bij het gebruik van HPA rekening met het volgende:
- Het standaard HPA-controle-interval is 30 seconden. Het wordt bepaald door de vlag horizontale-pod-autoscaler-synchronisatieperiode in de controllermanager.
- De standaard relatieve fout is 10%.
- Na de laatste toename van het aantal modules verwacht HPA dat de statistieken zich binnen drie minuten zullen stabiliseren. Dit interval wordt bepaald door de vlag horizontale-pod-autoscaler-upscale-vertraging.
- Na de laatste vermindering van het aantal modules wacht de HPA vijf minuten om zich te stabiliseren. Dit interval wordt bepaald door de vlag horizontale-pod-autoscaler-downscale-vertraging.
- HPA werkt het beste met implementatieobjecten in plaats van met replicatiecontrollers. Horizontale automatische schaling is incompatibel met rolling update, die replicatiecontrollers rechtstreeks manipuleert. Bij implementatie is het aantal replica's rechtstreeks afhankelijk van de implementatieobjecten.
Verticale automatische schaling van peulen
Verticale automatische schaling (VPA) wijst meer (of minder) CPU-tijd of geheugen toe aan bestaande pods. Geschikt voor stateful of stateless pods, maar vooral bedoeld voor stateful services. U kunt VPA echter ook gebruiken voor staatloze modules als u de hoeveelheid aanvankelijk toegewezen bronnen automatisch moet aanpassen.
VPA reageert ook op OOM-gebeurtenissen (onvoldoende geheugen). Als u de CPU-tijd en het geheugen wilt wijzigen, moet u de pods opnieuw opstarten. Bij heropstart respecteert de VPA het toewijzingsbudget () om het minimaal vereiste aantal modules te garanderen.
U kunt voor elke module de minimale en maximale bronnen instellen. U kunt dus de maximale hoeveelheid toegewezen geheugen beperken tot 8 GB. Dit is handig als de huidige knooppunten absoluut niet meer dan 8 GB geheugen per container kunnen toewijzen. Gedetailleerde specificaties en werkingsmechanisme worden beschreven in .
Daarnaast heeft VPA een interessante aanbevelingsfunctie (VPA Recommender). Het bewaakt het resourcegebruik en OOM-gebeurtenissen van alle modules om nieuwe geheugen- en CPU-tijdwaarden voor te stellen op basis van een intelligent algoritme op basis van historische statistieken. Er is ook een API die een pod-handle gebruikt en voorgestelde resourcewaarden retourneert.
Het is vermeldenswaard dat VPA Recommender de "limiet" van de bronnen niet bijhoudt. Dit kan ertoe leiden dat de module bronnen binnen knooppunten monopoliseert. Het is beter om de limiet op naamruimteniveau in te stellen om een groot geheugen- of CPU-verbruik te voorkomen.
VPA-operatieschema op hoog niveau:
- VPA controleert voortdurend de tijdens de installatie opgegeven metrische waarden met een standaardinterval van 10 seconden.
- Als de opgegeven drempel wordt bereikt, probeert de VPA de toegewezen hoeveelheid bronnen te wijzigen.
- De VPA werkt het aantal bronnen binnen de implementatie-/replicatiecontroller bij.
- Wanneer modules opnieuw worden opgestart, worden alle nieuwe bronnen toegepast op de gemaakte exemplaren.
VPA voegt de benodigde hoeveelheid middelen toe
Houd bij het gebruik van VPA rekening met de volgende punten:
- Voor het schalen is een verplichte herstart van de pod vereist. Dit is nodig om een onstabiele werking na het aanbrengen van wijzigingen te voorkomen. Voor de betrouwbaarheid worden modules opnieuw opgestart en over knooppunten verdeeld op basis van nieuw toegewezen bronnen.
- VPA en HPA zijn nog niet compatibel met elkaar en kunnen niet op dezelfde pods draaien. Als u beide schaalmechanismen in hetzelfde cluster gebruikt, zorg er dan voor dat uw instellingen voorkomen dat ze op dezelfde objecten worden geactiveerd.
- VPA stemt containeraanvragen voor bronnen alleen af op basis van vroeger en huidig gebruik. Er worden geen limieten voor het gebruik van bronnen ingesteld. Er kunnen problemen zijn met applicaties die niet correct werken en steeds meer bronnen beginnen over te nemen, dit zal ertoe leiden dat Kubernetes deze pod uitschakelt.
- VPA bevindt zich nog in een vroeg ontwikkelingsstadium. Houd er rekening mee dat het systeem in de nabije toekomst enkele wijzigingen kan ondergaan. Je kunt erover lezen и . Er zijn dus plannen om de gezamenlijke werking van VPA en HPA te implementeren, evenals de inzet van modules samen met een verticaal autoschalingsbeleid daarvoor (bijvoorbeeld een speciaal label 'vereist VPA').
Automatisch schalen van een Kubernetes-cluster
Cluster Autoscaler (CA) wijzigt het aantal knooppunten op basis van het aantal wachtende peulen. Het systeem controleert periodiek of er modules in behandeling zijn - en vergroot de clustergrootte als er meer bronnen nodig zijn en als het cluster de vastgestelde limieten niet overschrijdt. De CA communiceert met de cloudserviceprovider, vraagt extra knooppunten aan of geeft inactieve knooppunten vrij. De eerste algemeen beschikbare versie van CA werd geïntroduceerd in Kubernetes 1.8.
Schema van SA-operatie op hoog niveau:
- CA controleert of er modules in behandeling zijn met een standaardinterval van 10 seconden.
- Als een of meer peulen zich in de standby-status bevinden omdat het cluster niet over voldoende beschikbare bronnen beschikt om deze toe te wijzen, wordt geprobeerd een of meer extra knooppunten in te richten.
- Wanneer de cloudserviceprovider het vereiste knooppunt toewijst, wordt deze lid van het cluster en is hij klaar om de pods te bedienen.
- De Kubernetes-planner distribueert in behandeling zijnde peulen naar een nieuw knooppunt. Als hierna nog enkele modules in een wachtstatus blijven, wordt het proces herhaald en worden nieuwe knooppunten aan het cluster toegevoegd.
Automatische inrichting van clusterknooppunten in de cloud
Houd rekening met het volgende als u CA gebruikt:
- CA zorgt ervoor dat alle peulen in het cluster ruimte hebben om te worden uitgevoerd, ongeacht de CPU-belasting. Er wordt ook geprobeerd ervoor te zorgen dat er geen onnodige knooppunten in het cluster aanwezig zijn.
- CA registreert de noodzaak tot schalen na ongeveer 30 seconden.
- Zodra een knooppunt niet langer nodig is, wacht de CA standaard 10 minuten voordat het systeem wordt uitgeschaald.
- Het automatische schalingssysteem heeft het concept van expanders. Dit zijn verschillende strategieën voor het selecteren van een groep knooppunten waaraan nieuwe knooppunten worden toegevoegd.
- Gebruik de optie op verantwoorde wijze cluster-autoscaler.kubernetes.io/safe-to-evict (waar). Als u veel peulen installeert, of als er veel van deze verspreid zijn over alle knooppunten, verliest u grotendeels de mogelijkheid om het cluster uit te schalen.
- Gebruiken om te voorkomen dat pods worden verwijderd, waardoor delen van uw toepassing volledig kunnen mislukken.
Hoe Kubernetes-autoscalers met elkaar omgaan
Voor een perfecte harmonie moet automatisch schalen worden toegepast op zowel pod-niveau (HPA/VPA) als op clusterniveau. Ze communiceren relatief eenvoudig met elkaar:
- HPA's of VPA's werken podreplica's of bronnen bij die zijn toegewezen aan bestaande pods.
- Als er niet genoeg knooppunten zijn voor de geplande schaalvergroting, merkt de CA de aanwezigheid van pods in een wachtstatus op.
- De CA wijst nieuwe knooppunten toe.
- Modules worden gedistribueerd naar nieuwe knooppunten.
Collaboratief Kubernetes-schaaluitbreidingssysteem
Veelvoorkomende fouten bij het automatisch schalen van Kubernetes
Er zijn verschillende veelvoorkomende problemen waar ontwikkelaars tegenaan lopen bij het implementeren van autoscaling.
HPA en VPA zijn afhankelijk van statistieken en enkele historische gegevens. Als er onvoldoende middelen worden toegewezen, worden de modules geminimaliseerd en kunnen ze geen statistieken genereren. In dit geval zal automatisch schalen nooit plaatsvinden.
De schaalbewerking zelf is tijdgevoelig. We willen dat de modules en het cluster snel kunnen worden geschaald, voordat gebruikers problemen of storingen opmerken. Daarom moet rekening worden gehouden met de gemiddelde schaaltijd voor peulen en het cluster.
Ideaal scenario - 4 minuten:
- 30 seconden. Doelstatistieken bijwerken: 30-60 seconden.
- 30 seconden. HPA controleert metrische waarden: 30 seconden.
- Minder dan 2 seconden. Pods worden gemaakt en gaan in de wachtstatus: 1 seconde.
- Minder dan 2 seconden. CA ziet wachtende modules en stuurt oproepen naar voorzieningenknooppunten: 1 seconde.
- 3 minuten. De cloudprovider wijst knooppunten toe. K8s wacht tot ze klaar zijn: maximaal 10 minuten (afhankelijk van verschillende factoren).
Worst case (realistischer) scenario - 12 minuten:
- 30 seconden. Doelstatistieken bijwerken.
- 30 seconden. HPA controleert de metrische waarden.
- Minder dan 2 seconden. De pods worden gemaakt en gaan naar de stand-bystatus.
- Minder dan 2 seconden. De CA ziet de wachtende modules en voert oproepen uit om de knooppunten in te richten.
- 10 minuten. De cloudprovider wijst knooppunten toe. K8s wacht tot ze klaar zijn. De wachttijd is afhankelijk van verschillende factoren, zoals vertraging van de leverancier, vertraging van het besturingssysteem en ondersteuningstools.
Verwar de schaalmechanismen van cloudproviders niet met onze CA. Deze laatste draait binnen een Kubernetes-cluster, terwijl de engine van de cloudprovider op basis van knooppuntdistributie werkt. Het weet niet wat er aan de hand is met uw pods of applicatie. Deze systemen werken parallel.
Schalen in Kubernetes beheren
- Kubernetes is een tool voor resourcebeheer en orkestratie. Bewerkingen voor het beheren van pods en clusterbronnen zijn een belangrijke mijlpaal in het beheersen van Kubernetes.
- Begrijp de logica van de schaalbaarheid van pods, rekening houdend met HPA en VPA.
- CA mag alleen worden gebruikt als u een goed inzicht heeft in de behoeften van uw peulen en containers.
- Om een cluster optimaal te configureren, moet u begrijpen hoe verschillende schaalsystemen samenwerken.
- Houd bij het inschatten van de schaaltijd rekening met de worstcase- en bestcasescenario's.
Bron: www.habr.com