Skalningsalternativ för program i Azure Kubernetes Service
När du kör program i Azure Kubernetes service (AKS) kan du behöva öka eller minska mängden beräknings resurser. Antalet underliggande Kubernetes-noder kan också behöva ändras som antalet program instanser som du behöver ändra. Du kan också behöva etablera ett stort antal ytterligare program instanser.
Den här artikeln beskriver de viktigaste begreppen som hjälper dig att skala program i AKS:
- Skala manuellt
- Horisontell Pod autoskalning (HPA)
- Autoskalning av kluster
- Azure Container instance-integrering (ACI) med AKS
Skala poddar eller noder manuellt
Du kan skala repliker (poddar) och noder manuellt för att testa hur programmet svarar på en ändring i tillgängliga resurser och tillstånd. Genom att skala resurser manuellt kan du också definiera en uppsättning resurser som ska användas för att upprätthålla en fast kostnad, till exempel antalet noder. Om du vill skala manuellt definierar du repliken eller antalet noder. Kubernetes-API: et schemalägger sedan att skapa ytterligare poddar eller tömma noder baserat på replikering eller antal noder.
Vid skalning av noder anropar Kubernetes-API: t det relevanta Azure Compute-API: et som är kopplat till den beräknings typ som används av klustret. Exempel: för kluster som bygger på VM Scale Sets logiken för att välja vilka noder som ska tas bort bestäms av VM Scale Sets-API: et. Mer information om hur noder väljs för borttagning vid nedskalning finns i vanliga frågor och svar om VMSS.
För att komma igång med manuell skalning av poddar och noder, se skala program i AKS.
Horisontell autoskalning av poddar
Kubernetes använder den vågräta Pod autoskalning (HPA) för att övervaka resurs behovet och skalar automatiskt antalet repliker. Som standard kontrollerar autoskalning i horisontella Pod mått-API var 30: e sekund för alla nödvändiga ändringar i replik antalet. När ändringar krävs ökas eller minskas antalet repliker i enlighet med detta. Horisontell Pod autoskalning fungerar med AKS-kluster som har distribuerat mått servern för Kubernetes 1.8 +.
När du konfigurerar den horisontella Pod autoskalning för en specifik distribution definierar du det lägsta och högsta antalet repliker som kan köras. Du definierar också måttet för att övervaka och basera eventuella skalnings beslut, till exempel processor användning.
För att komma igång med den vågräta Pod-autoskalning i AKS, se AutoScale-poddar i AKS.
Cooldown för skalnings händelser
I takt med att den vågräta Pod-autoskalning kontrollerar Metrics API var 30: e sekund kanske tidigare skalnings händelser inte har slutförts innan en annan kontroll görs. Det här problemet kan orsaka att den vågräta Pod automatiskt skalar för att ändra antalet repliker innan föregående skalnings händelse kan ta emot program arbets belastning och resurs kraven för att justera detta.
För att minimera tävlings händelser anges ett fördröjnings värde. Det här värdet anger hur länge det vågräta Pod måste vänta efter en skalnings händelse innan en annan skalnings händelse kan utlösas. Detta innebär att det nya replik antalet börjar gälla och att API: et för att avspegla den distribuerade arbets belastningen. Det finns ingen fördröjning för att skala upp händelser från och med Kubernetes 1,12, men fördröjningen för att skala ned händelser är standardvärdet 5 minuter.
För närvarande kan du inte finjustera dessa cooldown-värden från standardvärdet.
Autoskalning av kluster
För att svara på ändring av Pod-krav har Kubernetes en kluster autoskalning som justerar antalet noder baserat på de begärda beräknings resurserna i Node-poolen. Som standard kontrollerar kluster autoskalning den metriska API-servern var 10: e sekund för alla nödvändiga ändringar i antalet noder. Om klustrets autoskalning avgör att en ändring krävs, ökar eller minskar du antalet noder i ditt AKS-kluster. Kluster autoskalning fungerar med Kubernetes RBAC-aktiverade AKS-kluster som kör Kubernetes 1.10. x eller senare.
Kluster autoskalning används vanligt vis tillsammans med den horisontella Pod autoskalning. När den vågräta Pod används ökas eller minskas antalet poddar baserat på program efter frågan och klustrets autoskalning justerar antalet noder som behövs för att köra ytterligare poddar.
För att komma igång med klustrets autoskalning i AKS, se kluster autoskalning på AKS.
Skala ut händelser
Om en nod inte har tillräckligt med beräknings resurser för att köra en begärd pod, kan Pod inte passera genom schemaläggnings processen. Pod kan inte startas om inte ytterligare beräknings resurser är tillgängliga i Node-poolen.
När poddar i klustret inte kan schemaläggas på grund av resurs begränsningar för en resurspool, ökar antalet noder i noden för att tillhandahålla ytterligare beräknings resurser. När de ytterligare noderna har distribuerats och är tillgängliga för användning i Node-poolen, schemaläggs poddar sedan att köras på dem.
Om ditt program behöver skala snabbt kan vissa poddar finnas kvar i ett tillstånd som väntar på att schemaläggas tills de ytterligare noder som distribueras av klustret autoskalning kan godkänna den schemalagda poddar. För program som har höga burst-krav kan du skala med virtuella noder och Azure Container Instances.
Skala i händelser
Klustrets autoskalning övervakar också Pod schemaläggnings status för noder som inte nyligen har tagit emot nya tids planerings begär Anden. Det här scenariot indikerar att Node-poolen har fler beräknings resurser än vad som krävs och antalet noder kan minskas.
En nod som skickar ett tröskelvärde som inte längre behövs i 10 minuter är schemalagd för borttagning. När den här situationen inträffar är poddar schemalagda att köras på andra noder i Node-poolen och klustrets autoskalning minskar antalet noder.
Dina program kan drabbas av vissa avbrott när poddar är schemalagda för olika noder när den automatiska skalnings tjänsten för klustret minskar antalet noder. Undvik avbrott genom att undvika program som använder en enda Pod-instans.
Burst till Azure Container Instances
Om du snabbt vill skala ditt AKS-kluster kan du integrera med Azure Container Instances (ACI). Kubernetes har inbyggda komponenter för skalning av antalet repliker och noder. Men om ditt program behöver skala snabbt, kan den horisontella Pod autoskalning schemalägga mer poddar än vad som finns i de befintliga beräknings resurserna i Node-poolen. Om det här scenariot har kon figurer ATS utlöses det här scenariot för att distribuera ytterligare noder i Node-poolen, men det kan ta några minuter för noderna att etablera och tillåta Kubernetes Scheduler att köra poddar på dem.
Med ACI kan du snabbt distribuera behållar instanser utan ytterligare infrastruktur belastning. När du ansluter med AKS blir ACI ett säkert, logiskt tillägg för ditt AKS-kluster. Komponenten virtuella noder , som baseras på Virtual Kubelet, installeras i ditt AKS-kluster som presenterar ACI som en virtuell Kubernetes-nod. Kubernetes kan sedan schemalägga poddar som körs som ACI-instanser via virtuella noder, inte som poddar på VM-noder direkt i ditt AKS-kluster.
Programmet kräver ingen ändring för att använda virtuella noder. Distributioner kan skalas över AKS och ACI och utan fördröjning som kluster autoskalning distribuerar nya noder i ditt AKS-kluster.
Virtuella noder distribueras till ett extra undernät i samma virtuella nätverk som ditt AKS-kluster. Med den här virtuella nätverks konfigurationen kan trafiken mellan ACI och AKS skyddas. Precis som ett AKS-kluster är en ACI-instans en säker, logisk beräknings resurs som är isolerad från andra användare.
Nästa steg
För att komma igång med skalnings program, följ först snabb starten för att skapa ett AKS-kluster med Azure CLI. Du kan sedan starta manuellt eller automatiskt skala program i ditt AKS-kluster:
- Skala poddar eller noder manuellt
- Använd den vågräta Pod autoskalning
- Använd kluster autoskalning
Mer information om kärn Kubernetes-och AKS-koncept finns i följande artiklar: