Metodtips för prestanda och skalning för stora 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:

Skalning av noder

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

• När du kör AKS-kluster i stor skala använder du autoskalning av kluster eller automatisk nodetablering när det är möjligt för att säkerställa dynamisk skalning av noder baserat på efterfrågan på beräkningsresurser.
• 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.
• För systemnodpooler använder du Standard_D16ds_v5 SKU eller en motsvarande kärna/minne VM SKU med tillfälliga OS-diskar för att tillhandahålla tillräckliga beräkningsresurser till 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.

AKS- och Kubernetes-kontrollplanets skalbarhet

I Kubernetes hanteras alla objekt som körs i ett kluster av 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, och inte alla resurser är likadana i kostnaden. Till exempel övervakas hemligheter ofta av flera kontrollers och poddar, där var och en gör ett första LIST-anrop för att synka tillståndet. Eftersom hemligheter vanligtvis är stora och uppdateras ofta, lägger de mer belastning på kontrollplanet än mindre ofta bevakade resurser.

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.

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.

I de flesta fall resulterar överskridande av tröskelvärdet för skalningsgränsen i sämre prestanda, men det orsakar inte att klustret omedelbart fäller över. 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.

Kontrollera om kontrollplanet har skalats upp genom att leta efter konfigurationskartan large-cluster-control-plane-scaling-status.

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

Överväganden för Kubernetes-skalningsomfång och kontrollplanen

Kubernetes-klienter är programkomponenter, till exempel operatorer eller övervakningsagenter, som körs i klustret och kommunicerar med kube-apiservern för att läsa eller ändra resurser. Det är viktigt att optimera hur dessa klienter beter sig för att minska belastningen de placerar på kube-apiservern och Kubernetes-kontrollplanet.

Antalet begäranden som aktivt bearbetas av API-servern vid ett visst tillfälle bestäms av --max-requests-inflight flaggorna och .--max-mutating-requests-inflight AKS använder standardvärdena 400 och 200 begäranden för dessa flaggor, vilket gör att totalt 600 begäranden kan skickas vid en viss tidpunkt. När vi skalar API-servern till större storlekar ökar vi även inflight-begäranden.

Två Kubernetes-objekttyper, PriorityLevelConfiguration och FlowSchema (APF), avgör hur API-servern delar upp den totala begärandekapaciteten mellan begärandetyper. AKS använder standardkonfigurationen.

Varje PriorityLevelConfiguration tilldelas en resurs av det totala antalet tillåtna begäranden. Om du vill visa PriorityLevelConfiguration-objekten i klustret och deras allokerade begäranderesurser kör du följande kommando.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema mappar API-serverbegäranden till en PriorityLevelConfiguration. Om flera FlowSchema-objekt matchar en begäran väljer API-servern den som har lägst matchande prioritet.

Mappningen av FlowSchemas till PriorityLevelConfigurations kan visas med det här kommandot:

kubectl get flowschemas

Kontrollera om några begäranden tas bort på grund av APF genom att köra följande kommando:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Metodtips för Kubernetes-klienten

LISTanrop som utfärdas av ooptimerade klienter är ofta en av de största faktorerna som begränsar ett klusters skalbarhet. 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 är främst beroende av svarets storlek. Den här vägledningen gäller om klienten utfärdar ett litet antal LIST-begäranden för stora objekt eller ett stort antal LIST-begäranden för mindre objekt.

Använd informationsverktyg

• Om koden behöver underhålla en uppdaterad lista över objekt i minnet kan du använda en informatör från klient-go-biblioteket för att se efter ändringar i resurserna baserat på händelser i stället för att söka efter ändringar. Det här är den bästa metoden för att undvika ooptimerade och upprepade LIST:er.

Använda API-servercache

• Använd resourceVersion=0 för att returnera resultat från API-servercachen. Detta kan förhindra att objekt hämtas från etcd vilket minskar etcd-belastningen, men det stöder inte sidnumrering.

  /api/v1/namespaces/default/pods?resourceVersion=0
  

Effektiv Kubernetes API-användning

• Vi rekommenderar att du använder klockargumentet när det är möjligt. Utan argument är standardbeteendet att lista objekt. Se exemplet nedan.

  /api/v1/namespaces/default/pods?watch=true
  

  Använd bevakning med en resourceVersion konfigurerad för att vara det senaste kända värdet som tagits emot från föregående lista eller bevakning. Detta hanteras automatiskt i klient-go. Kontrollera dock om du använder en Kubernetes-klient på andra språk.

  /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>
  

• Om kontrollanter eller operatorer måste använda LIST-anrop bör de undvika att avsöka klusteromfattande resurser utan etikett- eller fältväljare, särskilt i stora kluster. I följande exempel visas optimerade och ooptimerade LIST-anrop.

  Optimerad LISTA:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

  Ooptimerad LISTA:

  /api/v1/pods
  

• Använd sidnumrering för att minska storleken på LIST-svar om klienten måste hämta data från etcd. I följande exempel används gränsargumentet för att begränsa svaret till 100 objekt.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100
  

  Om du vill att LISTAN ska fortsätta att returnera alla poddobjekt i exemplet ovan använder du argumentet fortsätt med gräns.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>
  

  Om kubectl används --chunk-size kan argumentet tillämpas direkt på paginate-svar.

  kubectl get pods -n default --chunk-size=100
  

• Om dina kontrollerar eller operatörer använder leasinguppdateringar för val av ledare, ska du se till att de är motståndskraftiga mot tillfälliga anslutningsproblem genom att justera leaseDuration, renewDeadline och retryPeriod som är optimala för dina arbetsbelastningar. För Kubernetes controllers som använder client-go för val av ledare, använd följande formel:

  lease_duration > renew_deadline > retry_period
  

Daemonsets

• Det finns en betydande skillnad mellan en enskild kontrollant som listar objekt och en DaemonSet som körs på varje nod som gör samma sak. Om flera instanser av klientprogrammet regelbundet visar ett stort antal objekt skalas inte lösningen bra i stora kluster.

• Om du skapar en ny DaemonSet i kluster med tusentals noder, uppdaterar en DaemonSet eller ökar antalet noder kan det leda till hög belastning på kontrollplanet. Om DaemonSet-poddar utfärdar dyra API-serverbegäranden vid poddstart kan de orsaka hög resursanvändning på kontrollplanet från ett stort antal samtidiga begäranden.

• Använd en RollingUpdate-strategi för att distribuera nya DaemonSet-poddar gradvis. När DaemonSet-mallen uppdateras ersätter kontrollanten gamla poddar med nya på ett kontrollerat sätt. När den löpande uppdateringsstrategin inte uttryckligen har konfigurerats skapar Kubernetes som standard en RollingUpdate med maxUnavailable som 1, maxSurge som 0 och minReadySeconds som 0s. Se följande exempel.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• RollingUpdate-strategin gäller endast för befintliga DaemonSet-poddar. Det begränsar inte effekten av att lägga till nya noder, vilket skapar ytterligare DaemonSet-poddar eller distribuerar helt nya DaemonSets.

• För att förhindra att DaemonSets skickar samtidiga LIST-begäranden till API-servern vid start efter nodskalning eller nya DaemonSet-distributioner implementerar du start jitter i containerns startpunkt och konfigurerar lämpliga exponentiella backoff - och återförsöksprinciper för 5xx- eller 429-svar för att förhindra upprepade återförsök av stora LIST-begäranden.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

etcd-optimeringar

• Håll den totala etcd-storleken liten och använd inte etcd som en allmän databas. AKS tillhandahåller 8 GB etcd-lagring som standard, men större databaser etc. ökar defragmenteringstiden, vilket kan leda till problem med läs- och skrivprestanda. Större etcd-databaser kan också öka sannolikheten för API-server och etcd-tillförlitlighetsproblem om en ooptimerad klient hämtar ett stort antal objekt från etcd ofta. Om din etcd-databasstorlek överskrider 2 GB bör du överväga att använda de metoder för minskning av objektstorleken som anges nedan.
• Om du vill minska poddspecifikationsstorlekarna flyttar du miljövariabler från poddspecifikationer till ConfigMaps.
• Dela upp stora hemligheter eller ConfigMaps i mindre, mer hanterbara delar.
• Lagra hemligheter i Azure Key Vault i stället för Kubernetes-hemligheter när det är möjligt för att minska antalet hemligheter som lagras i etcd.
• Rensa oanvända objekt
  • Ta bort inaktuella jobb och slutförda poddar. Använd ttlSecondsAfterFinished på Jobb så att färdiga objekt tas bort automatiskt.
  • Se till att kontrollanter anger ownerReferences. På så sätt kan Kubernetes skräpinsamling ta bort beroende objekt automatiskt när den överordnade resursen tas bort.
  • Begränsa CronJob-historiken genom att ange successfulJobsHistoryLimit och failedJobsHistoryLimit så att endast ett litet antal slutförda jobbposter behålls.
  • Begränsa utplaceringshistoriken. Gamla ReplicaSets lagras också som API-objekt. Standardvärdet är 10.
• Minska Helm-revisionshistoriken med argumentet --history-max. Håll den under 5 i stora kluster.

Övervaka metrik och loggar för styrplan för AKS

Övervakning av kontrollplansmått i stora AKS-kluster är avgörande för att säkerställa stabiliteten och prestandan för Kubernetes-arbetsbelastningar. Dessa mått ger insyn i hälsotillståndet och beteendet för kritiska komponenter som API-servern, etcd, kontrollanthanteraren och schemaläggaren. I storskaliga miljöer, där resurskonkurration och höga API-anropsvolymer är vanliga, hjälper övervakning av kontrollplansmått till att identifiera flaskhalsar, identifiera avvikelser och optimera resursanvändningen. Genom att analysera dessa mått kan operatörer proaktivt åtgärda problem som svarstid för API-server, höga etcd-objekt eller överdriven kontrollplansresursförbrukning, vilket säkerställer effektiv klusterdrift och minimerar stilleståndstid.

Azure Monitor erbjuder omfattande mått och loggar på kontrollplanets hälsotillstånd via Azure Managed Prometheus och Diagnostic-inställningar.

• En lista över aviseringar som ska konfigureras för kontrollplanets hälsotillstånd finns i Metodtips för övervakning av AKS-kontrollplan
• Om du vill hämta listan över användaragenter som har den högsta svarstiden kan du använda kontrollplanets loggar/diagnostikinställningar

Plattformsmått för nyckelkontrollplan

AKS visar följande plattformsmått i Azure Monitor för övervakning av API-server och etcd-hälsa. Dessa mått är tillgängliga utan att aktivera Managed Prometheus och kan visas direkt i Azure portalen under Metrics för ditt AKS-kluster.

API Server-metrik:

Etcd-mått:

Övervaka apiserver_cpu_usage_percentage och apiserver_memory_usage_percentage konsekvent för att identifiera resursbelastning på API-servern. Om etcd_database_usage_percentage är konsekvent över 50%, granska avsnittet Etcd-optimeringar för att minska databasens storlek. En fullständig lista över tillgängliga mått finns i REFERENS för AKS-övervakningsdata.

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 gränsen som stöds aktiverar du kontrollplansmått (förhandsversion) med Azure Monitor hanterad tjänst 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

  Note

  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 nå den stödda gränsen, öppna en supportbiljett.

• Azure Network Policy Manager (Azure npm) stöder endast upp till 250 noder.

• Vissa AKS-nodmått, inklusive användning av noddiskar, användning av nod-CPU/minne och användning av nätverkstrafik in/ut, kommer inte att vara tillgängliga i Azure Monitor-plattformsmetrik efter att kontrollplanet har skalats upp.

• 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.

Azure API och plattformsbegränsning

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. På 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 resursleverantören. Sedan tillämpar resursprovidern strypningsgränser som är skräddarsydda för dess verksamhet. Mer information finns i ARM-begränsningsbegäranden.

Hantera resursbegrä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 en viss Azure API, till exempel Virtual Machine Scale Sets PUT-API:er. Varje AKS-kluster har flera AKS-ägda klienter, till exempel molnleverantörer eller klusterautoskalare, samt kundägda klienter, som Datadog eller egenvärd Prometheus, vilka 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 utgåvor innehåller många förbättringar som löser prestanda- och strypproblem. 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 klusterautoskalerns skanningsintervall: Om diagnosrapporterna visar att strypning av klusterautoskalern har upptäckts, kan du öka skanningsintervallet för att minska antalet anrop till Virtual Machine Scale Sets från klusterautoskalern.
  • 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.
• Split dina kluster i olika prenumerationer eller regioner: Om du har ett stort antal kluster och nodpooler som använder Virtual Machine Scale Sets kan du dela upp dem i olika prenumerationer eller regioner inom samma prenumeration. De flesta Azure API-gränser delas på prenumerations- och regionnivå, så du kan flytta eller skala dina kluster till olika prenumerationer eller regioner för att undvika begränsning av Azure API. 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.

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.

• Om du använder Azure Standard Load Balancer använder du minst 2 Utgående offentliga IP-adresser. Tänk också på begränsningar för LoadBalancer-tjänstens backend-regel när man planerar för stora kluster. Azure Standard Load Balancers stöder upp till 10 000 IP-konfigurationer för serverdelen per klientdels-IP. Varje typ: LoadBalancer-tjänsten skapar en belastningsutjämningsregel per exponerad port och associerar alla klusternoder med lastbalanserarens serverdelspool. Om du till exempel exponerar 5 portar för en enda tjänst når du den här gränsen på 2 000 noder.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• Använd Azure CNI-överlägg 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 skala 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 (Network Policy Manager) 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 för Azure CNI med Cilium-dataplanet för att tillhandahålla nätverk och säkerhet med höga prestanda.

• Aktivera LocalDNS i dina nodpooler för att minska svarstiden för DNS-matchning och avlasta centraliserade CoreDNS-poddar. I stora kluster med höga DNS-frågevolymer kan centraliserad DNS-matchning bli en flaskhals. LocalDNS distribuerar en DNS-proxy som en systemd tjänst på varje nod, löser frågor lokalt, eliminerar conntrack tabelltryck och uppgraderar anslutningar till TCP för att undvika conntrack konkurrensförhållanden. LocalDNS har också stöd för att leverera föråldrade cachelagrade svar när överliggande DNS inte är tillgängligt, vilket förbättrar systemets motståndskraft vid tillfälliga fel. För mer information, se DNS-upplösning i AKS.

Ö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 ökad kapacitet för nodfluktuation och minimerar belastningen på styrplanet.
• 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 standardvärdet 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. För mer information, se Anpassa uppgradering av nodökning.
• Mer information om klusteruppgradering finns i Uppgradera ett AKS-kluster.