Dela via

Metodtips för prestanda och skalning för små till medelstora arbetsbelastningar i Azure Kubernetes Service (AKS)

  • Artikel

Kommentar

Den här artikeln fokuserar på allmänna metodtips för små till medelstora arbetsbelastningar. Metodtips som är specifika för stora arbetsbelastningar finns i 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.

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

  • Kompromisser och rekommendationer för automatisk skalning av dina arbetsbelastningar.
  • Hantera nodskalning och effektivitet baserat på dina arbetsbelastningskrav.
  • Nätverksöverväganden för inkommande och utgående trafik.
  • Övervaka och felsöka kontrollplans- och nodprestanda.
  • Kapacitetsplanering, överspänningsscenarier och klusteruppgraderingar.
  • Överväganden för lagring och nätverk för prestanda för dataplanet.

Automatisk skalning av program jämfört med automatisk skalning av infrastruktur

Automatisk skalning av program

Automatisk skalning av program är användbart när du hanterar kostnadsoptimering eller infrastrukturbegränsningar. En välkonfigurerad autoskalning har hög tillgänglighet för ditt program samtidigt som kostnaderna minimeras. Du betalar bara för de resurser som krävs för att upprätthålla tillgängligheten, oavsett efterfrågan.

Om en befintlig nod till exempel har utrymme men inte tillräckligt med IP-adresser i undernätet kan den hoppa över skapandet av en ny nod och i stället omedelbart börja köra programmet på en ny podd.

Vågrät autoskalning av poddar

Implementering av horisontell autoskalning av poddar är användbart för program med en stadig och förutsägbar resursefterfrågan. HPA (Horizontal Pod Autoscaler) skalar dynamiskt antalet poddrepliker, vilket effektivt distribuerar belastningen över flera poddar och noder. Den här skalningsmekanismen är vanligtvis mest fördelaktig för program som kan delas upp i mindre, oberoende komponenter som kan köras parallellt.

HPA tillhandahåller som standard mått för resursanvändning. Du kan också integrera anpassade mått eller använda verktyg som Kubernetes Event-Driven Autoscaler (KEDA) (förhandsversion). Med dessa tillägg kan HPA fatta skalningsbeslut baserat på flera perspektiv och kriterier, vilket ger en mer holistisk vy över programmets prestanda. Detta är särskilt användbart för program med varierande komplexa skalningskrav.

Kommentar

Om det är högsta prioritet att upprätthålla hög tillgänglighet för ditt program rekommenderar vi att du lämnar en något högre buffert för det minsta poddnumret för hpa för att ta hänsyn till skalningstiden.

Autoskalning av lodrät podd

Implementering av vertikal poddautomatisk skalning är användbart för program med fluktuerande och oförutsägbara resurskrav. Med VPA (Vertical Pod Autoscaler) kan du finjustera resursbegäranden, inklusive PROCESSOR och minne, för enskilda poddar, vilket ger exakt kontroll över resursallokering. Den här kornigheten minimerar resursavfallet och förbättrar den övergripande effektiviteten i klusteranvändningen. VPA effektiviserar även programhanteringen genom att automatisera resursallokering, vilket frigör resurser för kritiska uppgifter.

Varning

Du bör inte använda VPA tillsammans med HPA på samma CPU- eller minnesmått. Den här kombinationen kan leda till konflikter, eftersom båda autoskalningsfunktionerna försöker svara på ändringar i efterfrågan med samma mått. Du kan dock använda VPA för CPU eller minne tillsammans med HPA för anpassade mått för att förhindra överlappning och se till att varje autoskalning fokuserar på olika aspekter av arbetsbelastningsskalning.

Kommentar

VPA fungerar baserat på historiska data. Vi rekommenderar att du väntar minst 24 timmar efter distributionen av VPA innan du tillämpar några ändringar för att ge den tid att samla in rekommendationsdata.

Automatisk skalning av infrastruktur

Autoskalning av kluster

Implementering av automatisk skalning av kluster är användbart om dina befintliga noder saknar tillräcklig kapacitet, eftersom det hjälper till med att skala upp och etablera nya noder.

När du överväger automatisk skalning av kluster innebär beslutet om när du ska ta bort en nod en kompromiss mellan att optimera resursanvändningen och säkerställa resurstillgänglighet. Att eliminera underutnyttjade noder förbättrar klusteranvändningen, men kan leda till att nya arbetsbelastningar måste vänta på att resurser etableras innan de kan distribueras. Det är viktigt att hitta en balans mellan dessa två faktorer som överensstämmer med dina kluster- och arbetsbelastningskrav och konfigurera profilinställningarna för autoskalning av kluster i enlighet med detta.

Profilinställningarna för autoskalning av kluster gäller universellt för alla autoskalningsaktiverade nodpooler i klustret. Det innebär att alla skalningsåtgärder som inträffar i en autoskalningsaktiverad nodpool kan påverka autoskalningsbeteendet i en annan nodpool. Det är viktigt att tillämpa konsekventa och synkroniserade profilinställningar i alla relevanta nodpooler för att säkerställa att autoskalningen fungerar som förväntat.

Överetablering

Överetablering är en strategi som hjälper till att minska risken för programtryck genom att säkerställa att det finns ett överskott av lättillgängliga resurser. Den här metoden är särskilt användbar för program som har mycket varierande belastningar och klusterskalningsmönster som visar frekventa uppskalningar och nedskalningar.

Om du vill fastställa den optimala mängden överetablering kan du använda följande formel:

1-buffer/1+traffic

Anta till exempel att du vill undvika att uppnå 100 % cpu-användning i klustret. Du kan välja en buffert på 30 % för att upprätthålla en säkerhetsmarginal. Om du förväntar dig en genomsnittlig trafiktillväxt på 40 %, kan du överväga överetablering med 50 %, enligt formeln:

1-30%/1+40%=50%

En effektiv överetableringsmetod innebär att pausa poddar. Pausa poddar är lågprioriterade distributioner som enkelt kan ersättas av högprioriterade distributioner. Du skapar poddar med låg prioritet som tjänar det enda syftet med att reservera buffertutrymme. När en podd med hög prioritet kräver utrymme tas pauspoddarna bort och schemaläggs om på en annan nod eller en ny nod för att hantera podden med hög prioritet.

Följande YAML visar ett exempel på paus poddmanifest:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Skalning och effektivitet för noder

Vägledning för bästa praxis:

Övervaka noggrant resursutnyttjande och schemaläggningsprinciper för att säkerställa att noder används effektivt.

Med nodskalning kan du dynamiskt justera antalet noder i klustret baserat på arbetsbelastningskrav. Det är viktigt att förstå att lägga till fler noder i ett kluster inte alltid är den bästa lösningen för att förbättra prestanda. För att säkerställa optimala prestanda bör du noggrant övervaka principer för resursanvändning och schemaläggning för att säkerställa att noder används effektivt.

Nodbilder

Vägledning för bästa praxis:

Använd den senaste nodbildversionen för att säkerställa att du har de senaste säkerhetskorrigeringarna och felkorrigeringarna.

Med den senaste nodbildversionen får du bästa möjliga prestanda. AKS levererar prestandaförbättringar i de veckovisa avbildningsversionerna. De senaste daemonset-avbildningarna cachelagras på den senaste VHD-avbildningen, vilket ger lägre svarstidsfördelar för nodetablering och bootstrapping. Att hamna på efterkälken vid uppdateringar kan ha en negativ inverkan på prestandan, så det är viktigt att undvika stora luckor mellan versioner.

Azure Linux

Azure Linux Container Host på AKS använder en inbyggd AKS-avbildning och tillhandahåller en enda plats för Linux-utveckling. Varje paket skapas från källan och verifieras, vilket säkerställer att dina tjänster körs på beprövade komponenter.

Azure Linux är enkelt, inklusive endast den nödvändiga uppsättningen paket för att köra containerarbetsbelastningar. Det ger en reducerad attackyta och eliminerar korrigering och underhåll av onödiga paket. I basskiktet har den en Microsoft-härdad kernel som är finjusterad för Azure. Den här avbildningen är perfekt för prestandakänsliga arbetsbelastningar och plattformstekniker eller operatörer som hanterar flottar av AKS-kluster.

Ubuntu 2204

Ubuntu 2204-avbildningen är standardnodbilden för AKS. Det är ett enkelt och effektivt operativsystem som är optimerat för att köra containerbaserade arbetsbelastningar. Det innebär att det kan bidra till att minska resursanvändningen och förbättra den övergripande prestandan. Avbildningen innehåller de senaste säkerhetskorrigeringarna och uppdateringarna, som hjälper till att säkerställa att dina arbetsbelastningar skyddas mot säkerhetsrisker.

Ubuntu 2204-avbildningen stöds fullt ut av Microsoft, Canonical och Ubuntu-communityn och kan hjälpa dig att uppnå bättre prestanda och säkerhet för dina containerbaserade arbetsbelastningar.

Virtuella datorer (VM)

Vägledning för bästa praxis:

När du väljer en virtuell dator kontrollerar du att storleken och prestandan för OS-disken och VM SKU:n inte har någon stor avvikelse. En avvikelse i storlek eller prestanda kan orsaka prestandaproblem och resurskonkurrering.

Programprestanda är nära knutna till de VM-SKU:er som du använder i dina arbetsbelastningar. Större och kraftfullare virtuella datorer ger i allmänhet bättre prestanda. För verksamhetskritiska arbetsbelastningar eller produktarbetsbelastningar rekommenderar vi att du använder virtuella datorer med minst en processor med 8 kärnor. Virtuella datorer med nyare maskinvarugenerationer, som v4 och v5, kan också hjälpa till att förbättra prestandan. Tänk på att svarstiden för att skapa och skala kan variera beroende på vilka VM-SKU:er du använder.

Använda dedikerade systemnodpooler

För att skala prestanda och tillförlitlighet rekommenderar vi att du använder en dedikerad systemnodpool. Med den här konfigurationen reserverar den dedikerade systemnodpoolen utrymme för kritiska systemresurser, till exempel system-OS-daemoner. Programarbetsbelastningen kan sedan köras i en användarnodpool för att öka tillgängligheten för allokerbara resurser för ditt program. Den här konfigurationen bidrar också till att minska risken för resurskonkurrens mellan systemet och programmet.

Skapa åtgärder

Granska de tillägg och tillägg som du har aktiverat under etableringen. Tillägg och tillägg kan ge svarstid till den totala varaktigheten för skapandeåtgärder. Om du inte behöver ett tillägg eller tillägg rekommenderar vi att du tar bort det för att förbättra svarstiden för att skapa.

Du kan också använda tillgänglighetszoner för att ge en högre tillgänglighetsnivå för att skydda mot potentiella maskinvarufel eller planerade underhållshändelser. AKS-kluster distribuerar resurser över logiska delar av den underliggande Azure-infrastrukturen. Tillgänglighetszoner separerar noder fysiskt från andra noder för att säkerställa att ett enskilt fel inte påverkar programmets tillgänglighet. Tillgänglighetszoner är endast tillgängliga i vissa regioner. Mer information finns i Tillgänglighetszoner i Azure.

Kubernetes API-server

LIST- och WATCH-åtgärder

Kubernetes använder åtgärderna LIST och WATCH för att interagera med Kubernetes API-servern och övervaka information om klusterresurser. Dessa åtgärder är grundläggande för hur Kubernetes utför resurshantering.

Åtgärden LIST hämtar en lista över resurser som passar inom vissa villkor, till exempel alla poddar i ett specifikt namnområde eller alla tjänster i klustret. Den här åtgärden är användbar när du vill få en översikt över dina klusterresurser eller om du behöver operatorn på flera resurser samtidigt.

Åtgärden LIST kan hämta stora mängder data, särskilt i stora kluster med flera resurser. Tänk på att om du gör obundna eller frekventa LIST-anrop läggs en betydande belastning på API-servern och kan stänga svarstiderna.

WATCH-åtgärden utför resursövervakning i realtid. När du konfigurerar en WATCH på en resurs skickar API-servern uppdateringar när det sker ändringar i resursen. Detta är viktigt för kontrollanter, till exempel ReplicaSet-kontrollanten, som förlitar sig på WATCH för att upprätthålla det önskade tillståndet för resurser.

Tänk på att om du tittar på för många föränderliga resurser eller gör för många samtidiga WATCH-begäranden kan DU överbelasta API-servern och orsaka överdriven resursförbrukning.

För att undvika potentiella problem och säkerställa stabiliteten i Kubernetes-kontrollplanet kan du använda följande strategier:

Resurskvoter

Implementera resurskvoter för att begränsa antalet resurser som kan visas eller övervakas av en viss användare eller ett visst namnområde för att förhindra för höga anrop.

API-prioritet och rättvisa

Kubernetes introducerade begreppet API Priority and Fairness (APF) för att prioritera och hantera API-begäranden. Du kan använda APF i Kubernetes för att skydda klustrets API-server och minska antalet HTTP 429 Too Many Requests svar som visas av klientprogram.

Anpassad resurs Nyckelfunktioner
PriorityLevelConfigurations • Definiera olika prioritetsnivåer för API-begäranden.
• Anger ett unikt namn och tilldelar ett heltalsvärde som representerar prioritetsnivån. Högre prioritetsnivåer har lägre heltalsvärden, vilket indikerar att de är mer kritiska.
• Kan använda flera för att kategorisera begäranden i olika prioritetsnivåer baserat på deras betydelse.
• Gör att du kan ange om begäranden på en viss prioritetsnivå ska omfattas av hastighetsbegränsningar.
FlowSchemas • Definiera hur API-begäranden ska dirigeras till olika prioritetsnivåer baserat på begärandeattribut.
• Ange regler som matchar begäranden baserat på kriterier som API-grupper, versioner och resurser.
• När en begäran matchar en viss regel dirigeras begäran till den prioritetsnivå som anges i den associerade PriorityLevelConfiguration.
• Kan använda för att ange utvärderingsordningen när flera FlowSchemas matchar en begäran för att säkerställa att vissa regler har företräde.

Genom att konfigurera API med PriorityLevelConfigurations och FlowSchemas kan viktiga API-begäranden prioriteras framför mindre viktiga begäranden. Detta säkerställer att viktiga åtgärder inte svälter eller drabbas av fördröjningar på grund av begäranden med lägre prioritet.

Optimera etikettering och väljare

När du använder LIST-åtgärder optimerar du etikettväljare för att begränsa omfånget för de resurser som du vill köra frågor mot för att minska mängden data som returneras och belastningen på API-servern.

I Kubernetes CREATE- och UPDATE-åtgärder refererar du till åtgärder som hanterar och ändrar klusterresurser.

CREATE- och UPDATE-åtgärder

Åtgärden CREATE skapar nya resurser i Kubernetes-klustret, till exempel poddar, tjänster, distributioner, konfigurationskartor och hemligheter. Under en CREATE-åtgärd skickar en klient, till exempel kubectl eller en kontrollant, en begäran till Kubernetes API-servern för att skapa den nya resursen. API-servern verifierar begäran, säkerställer kompatibilitet med alla principer för antagningskontrollanter och skapar sedan resursen i klustrets önskade tillstånd.

UPDATE-åtgärden ändrar befintliga resurser i Kubernetes-klustret, inklusive ändringar av resursspecifikationer, till exempel antal repliker, containeravbildningar, miljövariabler eller etiketter. Under en UPPDATERING-åtgärd skickar en klient en begäran till API-servern om att uppdatera en befintlig resurs. API-servern verifierar begäran, tillämpar ändringarna i resursdefinitionen och uppdaterar klusterresursen.

ÅTGÄRDERNA CREATE och UPDATE kan påverka kubernetes API-serverns prestanda under följande villkor:

  • Hög samtidighet: När flera användare eller program gör samtidiga CREATE- eller UPDATE-begäranden kan det leda till en ökning av API-begäranden som anländer till servern samtidigt. Detta kan betona API-serverns bearbetningskapacitet och orsaka prestandaproblem.
  • Komplexa resursdefinitioner: Resursdefinitioner som är alltför komplexa eller omfattar flera kapslade objekt kan öka den tid det tar för API-servern att verifiera och bearbeta CREATE- och UPDATE-begäranden, vilket kan leda till prestandaförsämring.
  • Resursvalidering och antagningskontroll: Kubernetes tillämpar olika principer för antagningskontroll och valideringskontroller på inkommande CREATE- och UPDATE-begäranden. Stora resursdefinitioner, till exempel de med omfattande anteckningar eller konfigurationer, kan kräva mer bearbetningstid.
  • Anpassade kontrollanter: Anpassade kontrollanter som bevakar ändringar i resurser, till exempel Distributioner eller StatefulSet-kontrollanter, kan generera ett stort antal uppdateringar vid skalning eller distribution av ändringar. Dessa uppdateringar kan belasta API-serverns resurser.

Mer information finns i Felsöka API-server- och etcd-problem i AKS.

Prestanda för dataplan

Kubernetes-dataplanet ansvarar för att hantera nätverkstrafik mellan containrar och tjänster. Problem med dataplanet kan leda till långsamma svarstider, försämrad prestanda och programavbrott. Det är viktigt att noggrant övervaka och optimera konfigurationer av dataplan, till exempel nätverksfördröjning, resursallokering, containerdensitet och nätverksprinciper, för att säkerställa att dina containerbaserade program körs smidigt och effektivt.

Lagringstyper

AKS rekommenderar och standard använder tillfälliga OS-diskar. Tillfälliga OS-diskar skapas på lokal VM-lagring och sparas inte på fjärransluten Azure-lagring som hanterade OS-diskar. De har snabbare återimerings- och starttider, vilket möjliggör snabbare klusteråtgärder, och de ger lägre svarstid för läsning/skrivning på OS-disken för AKS-agentnoder. Tillfälliga OS-diskar fungerar bra för tillståndslösa arbetsbelastningar, där program är toleranta mot enskilda VM-fel men inte för vm-distributionstid eller enskilda vm-omimeringsinstanser. Endast vissa VM-SKU:er stöder tillfälliga OS-diskar, så du måste se till att din önskade SKU-generering och storlek är kompatibel. Mer information finns i Tillfälliga OS-diskar i Azure Kubernetes Service (AKS).

Om din arbetsbelastning inte kan använda tillfälliga OS-diskar använder AKS som standard Premium SSD OS-diskar. Om Premium SSD OS-diskar inte är kompatibla med din arbetsbelastning, är AKS standard för Standard SSD-diskar. För närvarande är den enda andra tillgängliga os-disktypen Standard HDD. Mer information finns i Lagringsalternativ i Azure Kubernetes Service (AKS).

Följande tabell innehåller en uppdelning av föreslagna användningsfall för OS-diskar som stöds i AKS:

Typ av OS-disk Nyckelfunktioner Föreslagna användningsfall
Tillfälliga operativsystemdiskar • Snabbare återimerings- och starttider.
• Lägre svarstid för läsning/skrivning på OS-disken för AKS-agentnoder.
• Hög prestanda och tillgänglighet.		 • Krävande företagsarbetsbelastningar, till exempel SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite osv.
• Tillståndslösa produktionsarbetsbelastningar som kräver hög tillgänglighet och låg svarstid.
Premium SSD OS-diskar • Konsekvent prestanda och låg svarstid.
• Hög tillgänglighet.		 • Krävande företagsarbetsbelastningar, till exempel SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite osv.
• I/O-intensiva företagsarbetsbelastningar.
Standard SSD OS-diskar • Konsekvent prestanda.
• Bättre tillgänglighet och svarstid jämfört med Standard HDD-diskar.		 • Webbservrar.
• Låg in-/utdataåtgärder per sekund (IOPS) programservrar.
• Lätt använda företagsprogram.
• Dev/test-arbetsbelastningar.
Standard HDD-diskar • Låg kostnad.
• Uppvisar variabilitet i prestanda och svarstid.		 • Lagring av säkerhetskopior.
• Masslagring med sällan förekommande åtkomst.

IOPS och dataflöde

Indata-/utdataåtgärder per sekund (IOPS) refererar till antalet läs- och skrivåtgärder som en disk kan utföra på en sekund. Dataflöde refererar till mängden data som kan överföras under en viss tidsperiod.

OS-diskar ansvarar för att lagra operativsystemet och dess associerade filer, och de virtuella datorerna ansvarar för att köra programmen. När du väljer en virtuell dator kontrollerar du att storleken och prestandan för OS-disken och VM SKU:n inte har någon stor avvikelse. En avvikelse i storlek eller prestanda kan orsaka prestandaproblem och resurskonkurrering. Om os-disken till exempel är betydligt mindre än de virtuella datorerna kan den begränsa mängden tillgängligt utrymme för programdata och få systemet att få slut på diskutrymme. Om OS-disken har lägre prestanda än de virtuella datorerna kan det bli en flaskhals och begränsa systemets övergripande prestanda. Kontrollera att storleken och prestandan är balanserade för att säkerställa optimala prestanda i Kubernetes.

Du kan använda följande steg för att övervaka IOPS- och bandbreddsmätare på OS-diskar i Azure Portal:

  1. Navigera till Azure-portalen.
  2. Sök efter VM-skalningsuppsättningar och välj vm-skalningsuppsättningen.
  3. Gå till Övervakning och välj Mått.

Tillfälliga OS-diskar kan ge dynamisk IOPS och dataflöde för ditt program, medan hanterade diskar har begränsat IOPS och dataflöde. Mer information finns i Tillfälliga OS-diskar för virtuella Azure-datorer.

Azure Premium SSD v2 är utformat för IO-intensiva företagsarbetsbelastningar som kräver diskfördröjning under millisekunder och hög IOPS och dataflöde till en låg kostnad. Den passar för ett brett utbud av arbetsbelastningar, till exempel SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, stordata/analys, spel med mera. Den här disktypen är det alternativ med högst prestanda som för närvarande är tillgängligt för beständiga volymer.

Poddschemaläggning

De minnes- och CPU-resurser som allokeras till en virtuell dator har en direkt inverkan på prestanda för poddarna som körs på den virtuella datorn. När en podd skapas tilldelas den en viss mängd minne och CPU-resurser som används för att köra programmet. Om den virtuella datorn inte har tillräckligt med minne eller cpu-resurser kan det leda till att poddarna saktar ner eller till och med kraschar. Om den virtuella datorn har för mycket minne eller tillgängliga CPU-resurser kan det leda till att poddarna körs ineffektivt, slösar resurser och ökar kostnaderna. Vi rekommenderar att du övervakar de totala poddförfrågningarna i dina arbetsbelastningar mot de totala allokerbara resurserna för bästa möjliga förutsägbarhet och prestanda för schemaläggning. Du kan också ange maximalt antal poddar per nod baserat på kapacitetsplaneringen med hjälp av --max-pods.