Metodtips för prestanda och skalning för stora arbetsbelastningar i Azure Kubernetes Service (AKS)

Kommentar

Den här artikeln fokuserar på allmänna metodtips för stora arbetsbelastningar. Metodtips som är specifika för små till medelstora arbetsbelastningar finns i Metodtips för prestanda och skalning för små till medelstora arbetsbelastningar i Azure Kubernetes Service (AKS).

När du distribuerar och underhåller kluster i AKS kan du använda följande metodtips för att optimera prestanda och skalning.

Tänk på att stor är en relativ term. Kubernetes har ett flerdimensionellt skalningskuvert och skalningskuvertet för din arbetsbelastning beror på vilka resurser du använder. Till exempel kan ett kluster med 100 noder och tusentals poddar eller CRD:er anses vara stora. Ett 1 000 nodkluster med 1 000 poddar och olika andra resurser kan betraktas som små ur kontrollplanets perspektiv. Den bästa signalen för skalning av ett Kubernetes-kontrollplan är API-serverns http-begärandefrekvens och svarstid, eftersom det är en proxy för mängden belastning på kontrollplanet.

I den här artikeln lär du dig mer om:

• AKS- och Kubernetes-kontrollplanets skalbarhet.
• Metodtips för Kubernetes-klienten, inklusive backoff, klockor och sidnumrering.
• Begränsningar för Azure API och plattformsbegränsning.
• Funktionsbegränsningar.
• Metodtips för nätverks- och nodpoolskalning.

AKS- och Kubernetes-kontrollplanets skalbarhet

I AKS består ett kluster av en uppsättning noder (fysiska eller virtuella datorer)) som kör Kubernetes-agenter och hanteras av Kubernetes-kontrollplanet som hanteras av AKS. AKS optimerar Kubernetes-kontrollplanet och dess komponenter för skalbarhet och prestanda, men det är fortfarande bundet av de överordnade projektgränserna.

Kubernetes har ett flerdimensionellt skalningskuvert där varje resurstyp representerar en dimension. Alla resurser är inte likadana. Till exempel anges klockor ofta på hemligheter, vilket resulterar i listanrop till kube-apiservern som lägger till kostnader och en oproportionerligt högre belastning på kontrollplanet jämfört med resurser utan klockor.

Kontrollplanet hanterar all resursskalning i klustret, så ju mer du skalar klustret inom en viss dimension, desto mindre kan du skala inom andra dimensioner. Om du till exempel kör hundratusentals poddar i ett AKS-kluster påverkas hur mycket poddomsättningshastighet (poddmutationer per sekund) som kontrollplanet kan stödja.

Kuvertets storlek är proportionell mot storleken på Kubernetes-kontrollplanet. AKS har stöd för tre kontrollplansnivåer som en del av bas-SKU:n: Kostnadsfri, Standard och Premium-nivå. Mer information finns i prisnivåerna Kostnadsfri, Standard och Premium för AKS-klusterhantering.

Viktigt!

Vi rekommenderar starkt att du använder Standard- eller Premium-nivån för produktions- eller skalningsarbetsbelastningar. AKS skalar automatiskt upp Kubernetes-kontrollplanet för att stödja följande skalningsgränser:

• Upp till 5 000 noder per AKS-kluster
• 200 000 poddar per AKS-kluster (med Azure CNI Overlay)

I de flesta fall resulterar överskridande av tröskelvärdet för skalningsgränsen i sämre prestanda, men det gör inte att klustret omedelbart redundansväxlar. Om du vill hantera belastningen på Kubernetes-kontrollplanet bör du överväga att skala i batchar på upp till 10–20 % av den aktuella skalan. För ett nodkluster på 5 000 skalar du till exempel i steg om 500–1 000 noder. Även om AKS autoskalar kontrollplanet sker det inte omedelbart.

Du kan använda API Priority and Fairness (APF) för att begränsa specifika klienter och begärandetyper för att skydda kontrollplanet vid hög omsättning och belastning.

Kubernetes-klienter

Kubernetes-klienter är programklienter, till exempel operatorer eller övervakningsagenter, som distribueras i Kubernetes-klustret som behöver kommunicera med kube-api-servern för att utföra läs- eller mutate-åtgärder. Det är viktigt att optimera beteendet för dessa klienter för att minimera belastningen de lägger till kube-api-servern och Kubernetes-kontrollplanet.

Du kan analysera API-servertrafik och klientbeteende via Kube-granskningsloggar. Mer information finns i Felsöka Kubernetes-kontrollplanet.

LISTbegäranden kan vara dyra. När du arbetar med listor som kan ha fler än några tusen små objekt eller fler än några hundra stora objekt bör du överväga följande riktlinjer:

• Tänk på hur många objekt (CR) som du förväntar dig så småningom finns när du definierar en ny resurstyp (CRD).
• Belastningen på etcd- och API-servern förlitar sig främst på antalet objekt som finns, inte antalet objekt som returneras. Även om du använder en fältväljare för att filtrera listan och bara hämta ett litet antal resultat gäller dessa riktlinjer fortfarande. Det enda undantaget är hämtning av ett enskilt objekt av metadata.name.
• Undvik upprepade LIST-anrop om möjligt om koden behöver underhålla en uppdaterad lista över objekt i minnet. Överväg i stället att använda de informeringsklasser som tillhandahålls i de flesta Kubernetes-bibliotek. Informatörer kombinerar automatiskt LIST- och WATCH-funktioner för att effektivt underhålla en minnesintern samling.
• Fundera på om du behöver stark konsekvens om informatörerna inte uppfyller dina behov. Behöver du se de senaste data, upp till exakt den tidpunkt då du utfärdade frågan? Om inte anger du ResourceVersion=0. Detta gör att API-servercachen hanterar din begäran i stället för etcd.
• Om du inte kan använda informatörer eller API-servercachen läser du stora listor i segment.
• Undvik att lista oftare än nödvändigt. Om du inte kan använda Informatörer bör du tänka på hur ofta ditt program listar resurserna. När du har läst det sista objektet i en stor lista ska du inte omedelbart fråga om samma lista. Du bör vänta en stund i stället.
• Överväg antalet instanser som körs i klientprogrammet. Det är stor skillnad mellan att ha en enda kontrollant som listar objekt jämfört med att ha poddar på varje nod som gör samma sak. Om du planerar att ha flera instanser av klientprogrammet som regelbundet visar ett stort antal objekt skalas inte lösningen till stora kluster.

Begränsning av Azure API och plattform

Belastningen på ett molnprogram kan variera över tid baserat på faktorer som antalet aktiva användare eller vilka typer av åtgärder som användarna utför. Om systemets bearbetningskrav överskrider kapaciteten för de tillgängliga resurserna kan systemet överbelastas och drabbas av dåliga prestanda och fel.

Om du vill hantera varierande belastningsstorlekar i ett molnprogram kan du tillåta att programmet använder resurser upp till en angiven gräns och sedan begränsa dem när gränsen nås. I Azure sker begränsning på två nivåer. Azure Resource Manager (ARM) begränsar begäranden för prenumerationen och klientorganisationen. Om begäran är under begränsningsgränserna för prenumerationen och klientorganisationen dirigerar ARM begäran till resursprovidern. Resursprovidern tillämpar sedan begränsningsgränser som är skräddarsydda för dess åtgärder. Mer information finns i ARM-begränsningsbegäranden.

Hantera begränsning i AKS

Azure API-gränser definieras vanligtvis på kombinationsnivå för prenumerationsregion. Till exempel alla klienter i en prenumeration i en viss region delar API-gränser för ett visst Azure API, till exempel PUT-API:er för VM-skalningsuppsättningar. Varje AKS-kluster har flera AKS-ägda klienter, till exempel molnleverantör eller autoskalning av kluster eller kundägda klienter, till exempel Datadog eller prometheus med egen värd, som anropar Azure-API:er. När du kör flera AKS-kluster i en prenumeration inom en viss region delar alla AKS-ägda och kundägda klienter i klustren en gemensam uppsättning API-gränser. Därför är antalet kluster som du kan distribuera i en prenumerationsregion en funktion av antalet klienter som distribueras, deras anropsmönster och klustrens övergripande skala och elasticitet.

Med ovanstående överväganden i åtanke kan kunderna vanligtvis distribuera mellan 20–40 små till medelstora kluster per prenumerationsregion. Du kan maximera din prenumerationsskala med hjälp av följande metodtips:

Uppgradera alltid dina Kubernetes-kluster till den senaste versionen. Nyare versioner innehåller många förbättringar som hanterar prestanda- och begränsningsproblem. Om du använder en uppgraderad version av Kubernetes och fortfarande ser begränsningar på grund av den faktiska belastningen eller antalet klienter i prenumerationen kan du prova följande alternativ:

• Analysera fel med hjälp av AKS Diagnostisera och lösa problem: Du kan använda AKS Diagnostisera och lösa problem för att analysera fel, identifiera rotorsaken och få lösningsrekommendationer.
  • Öka genomsökningsintervallet för klusterautomatskalning: Om diagnostikrapporterna visar att begränsningen av kluster autoskalning har identifierats kan du öka genomsökningsintervallet för att minska antalet anrop till VM-skalningsuppsättningar från autoskalning av kluster.
  • Konfigurera om program från tredje part för att göra färre anrop: Om du filtrerar efter användaragenter i diagnostiken Visa begärandefrekvens och begränsningsinformation och ser att ett program från tredje part, till exempel ett övervakningsprogram, gör ett stort antal GET-begäranden, kan du ändra inställningarna för dessa program för att minska frekvensen för GET-anropen. Kontrollera att programklienterna använder exponentiell backoff när de anropar Azure-API:er.
• Dela upp klustren i olika prenumerationer eller regioner: Om du har ett stort antal kluster och nodpooler som använder Vm-skalningsuppsättningar kan du dela upp dem i olika prenumerationer eller regioner inom samma prenumeration. De flesta Azure API-gränser delas på prenumerationsregionnivå, så du kan flytta eller skala dina kluster till olika prenumerationer eller regioner för att avblockera azure API-begränsningen. Det här alternativet är särskilt användbart om du förväntar dig att dina kluster ska ha hög aktivitet. Det finns inga allmänna riktlinjer för dessa gränser. Om du vill ha specifik vägledning kan du skapa en supportbegäran.

Funktionsbegränsningar

När du skalar dina AKS-kluster till större skalningspunkter bör du tänka på följande funktionsbegränsningar:

• AKS stöder skalning av upp till 5 000 noder som standard för alla standardnivå-/LTS-kluster. AKS skalar ditt klusters kontrollplan vid körning baserat på klusterstorlek och resursanvändning för API-server. Om du inte kan skala upp till den gräns som stöds aktiverar du kontrollplansmått (förhandsversion) med Azure Monitor-hanterade tjänsten för Prometheus för att övervaka kontrollplanet. Information om hur du felsöker problem med skalningsprestanda eller tillförlitlighet finns i följande resurser:
  • Felsökningsguide för AKS i stor skala
  • Felsöka Kubernetes-kontrollplanet

Kommentar

Under åtgärden för att skala kontrollplanet kan det uppstå förhöjd API-serversvarstid eller tidsgränser i upp till 15 minuter. Om du fortfarande har problem med att skala till den gräns som stöds öppnar du ett supportärende.

• Azure Network Policy Manager (Azure npm) stöder endast upp till 250 noder.
• Vissa AKS-nodmått, inklusive användning av noddiskar, cpu-/minnesanvändning för noder och in-/ut-nätverk, kommer inte att vara tillgängliga i Azure Monitor-plattformsmått när kontrollplanet har skalats upp. Kontrollera om kontrollplanet har skalats upp genom att leta efter konfigurationskartan "control-plane-scaling-status"

kubectl describe configmap control-plane-scaling-status -n kube-system

• Du kan inte använda funktionen Stoppa och starta med kluster som har fler än 100 noder. Mer information finns i Stoppa och starta ett AKS-kluster.

Nätverk

När du skalar dina AKS-kluster till större skalningspunkter bör du tänka på följande metodtips för nätverk:

• Använd Hanterad NAT för klusterutgående med minst två offentliga IP-adresser på NAT-gatewayen. Mer information finns i Skapa en hanterad NAT-gateway för ditt AKS-kluster.
• Använd Azure CNI Overlay för att skala upp till 200 000 poddar och 5 000 noder per kluster. Mer information finns i Konfigurera Azure CNI Overlay-nätverk i AKS.
• Om ditt program behöver direkt podd-till-pod-kommunikation mellan kluster använder du Azure CNI med dynamisk IP-allokering och skalar upp till 50 000 programpoddar per kluster med en dirigerbar IP-adress per podd. Mer information finns i Konfigurera Azure CNI-nätverk för dynamisk IP-allokering i AKS.
• När du använder interna Kubernetes-tjänster bakom en intern lastbalanserare rekommenderar vi att du skapar en intern lastbalanserare eller tjänst under en 750-nodskala för optimal skalningsprestanda och elasticitet för lastbalanserare.
• Azure npm stöder endast upp till 250 noder. Om du vill tillämpa nätverksprinciper för större kluster bör du överväga att använda Azure CNI som drivs av Cilium, som kombinerar det robusta kontrollplanet i Azure CNI med Cilium-dataplanet för att tillhandahålla nätverk och säkerhet med höga prestanda.

Skalning av nodpool

När du skalar dina AKS-kluster till större skalningspunkter bör du tänka på följande metodtips för skalning av nodpooler:

• För systemnodpooler använder du Standard_D16ds_v5 SKU eller en motsvarande SKU för kärn-/minnes-VM med tillfälliga OS-diskar för att tillhandahålla tillräckligt med beräkningsresurser för kube-systempoddar.
• Eftersom AKS har en gräns på 1 000 noder per nodpool rekommenderar vi att du skapar minst fem användarnodpooler för att skala upp till 5 000 noder.
• När du kör AKS-kluster i stor skala använder du autoskalning av klustret när det är möjligt för att säkerställa dynamisk skalning av nodpooler baserat på efterfrågan på beräkningsresurser. Mer information finns i Skala ett AKS-kluster automatiskt för att uppfylla programkraven.
• Om du skalar över 1 000 noder och inte använder autoskalning av kluster rekommenderar vi att du skalar i batchar med 500–700 noder i taget. Skalningsåtgärderna bör ha en väntetid på två minuter till fem minuter mellan uppskalningsåtgärder för att förhindra Azure API-begränsning. Mer information finns i API-hantering: Principer för cachelagring och begränsning.

Överväganden och metodtips för klusteruppgradering

• När ett kluster når gränsen på 5 000 noder blockeras klusteruppgraderingar. Den här gränsen förhindrar en uppgradering eftersom det inte finns någon tillgänglig nodkapacitet för att utföra löpande uppdateringar inom maxgränsen för överspänningsegenskap. Om du har ett kluster med den här gränsen rekommenderar vi att du skalar ned klustret under 3 000 noder innan du försöker uppgradera klustret. Detta ger extra kapacitet för nodomsättning och minimerar belastningen på kontrollplanet.
• När du uppgraderar kluster med fler än 500 noder rekommenderar vi att du använder en maximal överspänningskonfiguration på 10–20 % av nodpoolens kapacitet. AKS konfigurerar uppgraderingar med ett standardvärde på 10 % för maximal ökning. Du kan anpassa maxinställningarna för överbelastning per nodpool för att möjliggöra en kompromiss mellan uppgraderingshastighet och arbetsbelastningsstörningar. När du ökar maxinställningarna för överspänning slutförs uppgraderingsprocessen snabbare, men du kan uppleva störningar under uppgraderingsprocessen. Mer information finns i Anpassa uppgradering av nodtoppar.
• Mer information om klusteruppgradering finns i Uppgradera ett AKS-kluster.