Delen via

Best practices voor prestaties en schalen voor kleine tot middelgrote workloads in Azure Kubernetes Service (AKS)

  • Artikel

Notitie

Dit artikel is gericht op algemene aanbevolen procedures voor kleine tot middelgrote workloads. Zie best practices die specifiek zijn voor grote workloads, best practices voor prestaties en schalen voor grote workloads in Azure Kubernetes Service (AKS).

Wanneer u clusters in AKS implementeert en onderhoudt, kunt u de volgende aanbevolen procedures gebruiken om de prestaties en schaal te optimaliseren.

In dit artikel krijgt u meer informatie over:

  • Compromissen en aanbevelingen voor het automatisch schalen van uw workloads.
  • Knooppuntschalen en efficiëntie beheren op basis van uw workloadvereisten.
  • Netwerkoverwegingen voor inkomend en uitgaand verkeer.
  • Bewaking en probleemoplossing van het besturingsvlak en de prestaties van knooppunten.
  • Capaciteitsplanning, piekscenario's en clusterupgrades.
  • Overwegingen voor opslag en netwerken voor prestaties van gegevensvlakken.

Automatisch schalen van toepassingen versus automatisch schalen van infrastructuur

Automatisch schalen van toepassingen

Automatisch schalen van toepassingen is handig wanneer u te maken hebt met kostenoptimalisatie of infrastructuurbeperkingen. Een goed geconfigureerde automatische schaalaanpassing zorgt voor hoge beschikbaarheid voor uw toepassing, terwijl ook de kosten worden geminimaliseerd. U betaalt alleen voor de resources die nodig zijn om de beschikbaarheid te behouden, ongeacht de vraag.

Als een bestaand knooppunt bijvoorbeeld ruimte heeft, maar niet voldoende IP-adressen in het subnet, kan het mogelijk het maken van een nieuw knooppunt overslaan en in plaats daarvan onmiddellijk beginnen met het uitvoeren van de toepassing op een nieuwe pod.

Automatisch schalen van horizontale pods

Het implementeren van horizontale schaalaanpassing van pods is handig voor toepassingen met een stabiele en voorspelbare resourcevraag. Met de horizontale automatische schaalaanpassing van pods (HPA) wordt het aantal podreplica's dynamisch geschaald, waardoor de belasting effectief over meerdere pods en knooppunten wordt verdeeld. Dit schaalmechanisme is doorgaans het nuttigst voor toepassingen die kunnen worden opgesplitst in kleinere, onafhankelijke onderdelen die parallel kunnen worden uitgevoerd.

De HPA biedt standaard metrische gegevens over resourcegebruik. U kunt ook aangepaste metrische gegevens integreren of gebruikmaken van hulpprogramma's zoals de Kubernetes Event-Driven Autoscaler (KEDA) (preview). Met deze extensies kan de HPA schaalbeslissingen nemen op basis van meerdere perspectieven en criteria, waardoor een meer holistische weergave van de prestaties van uw toepassing wordt geboden. Dit is vooral handig voor toepassingen met verschillende complexe schaalvereisten.

Notitie

Als het handhaven van hoge beschikbaarheid voor uw toepassing de hoogste prioriteit heeft, raden we u aan een iets hogere buffer te laten voor het minimale podnummer voor uw HPA om rekening te houden met de schaaltijd.

Automatische schaalaanpassing van verticale pods

Het implementeren van automatische schaalaanpassing van verticale pods is handig voor toepassingen met fluctuerende en onvoorspelbare resourcevereisten. Met de verticale automatische schaalaanpassing van pods (VPA) kunt u resourceaanvragen, inclusief CPU en geheugen, verfijnen voor afzonderlijke pods, waardoor u nauwkeurige controle over resourcetoewijzing kunt inschakelen. Deze granulariteit minimaliseert resourceverspilling en verbetert de algehele efficiëntie van het clustergebruik. De VPA stroomlijnt ook toepassingsbeheer door resourcetoewijzing te automatiseren en resources vrij te maken voor kritieke taken.

Waarschuwing

Gebruik de VPA niet in combinatie met de HPA op dezelfde CPU- of geheugengegevens. Deze combinatie kan leiden tot conflicten, omdat beide automatische schaalaanpassingen proberen te reageren op wijzigingen in de vraag met behulp van dezelfde metrische gegevens. U kunt de VPA echter gebruiken voor CPU of geheugen in combinatie met de HPA voor aangepaste metrische gegevens om overlapping te voorkomen en ervoor te zorgen dat elke automatische schaalaanpassing zich richt op verschillende aspecten van het schalen van workloads.

Notitie

De VPA werkt op basis van historische gegevens. We raden u aan ten minste 24 uur na de implementatie van de VPA te wachten voordat u wijzigingen toepast om deze tijd te geven voor het verzamelen van aanbevelingsgegevens.

Automatische schaalaanpassing van infrastructuur

Automatische schaalaanpassing van clusters

Het automatisch schalen van clusters is handig als uw bestaande knooppunten onvoldoende capaciteit hebben, omdat het helpt bij het omhoog schalen en inrichten van nieuwe knooppunten.

Wanneer u automatische schaalaanpassing van clusters overweegt, moet u bepalen wanneer een knooppunt moet worden verwijderd, een afweging maken tussen het optimaliseren van het resourcegebruik en het garanderen van de beschikbaarheid van resources. Het elimineren van onderbenutte knooppunten verbetert het clustergebruik, maar kan ertoe leiden dat nieuwe workloads moeten wachten tot resources moeten worden ingericht voordat ze kunnen worden geïmplementeerd. Het is belangrijk om een balans te vinden tussen deze twee factoren die overeenkomen met de vereisten voor uw cluster en werkbelasting en om de profielinstellingen voor automatische schaalaanpassing van clusters dienovereenkomstig te configureren.

De profielinstellingen voor automatische schaalaanpassing van clusters zijn universeel van toepassing op alle knooppuntgroepen met automatische schaalaanpassing in uw cluster. Dit betekent dat eventuele schaalacties die plaatsvinden in een knooppuntgroep met automatische schaalaanpassing mogelijk van invloed zijn op het gedrag van automatisch schalen in een andere knooppuntgroep. Het is belangrijk om consistente en gesynchroniseerde profielinstellingen toe te passen in alle relevante knooppuntgroepen om ervoor te zorgen dat de automatische schaalaanpassing werkt zoals verwacht.

Overprovisioning

Overprovisioning is een strategie waarmee het risico van toepassingsdruk wordt beperkt door ervoor te zorgen dat er een overschot aan direct beschikbare resources is. Deze aanpak is vooral handig voor toepassingen die zeer variabele belasting en clusterschaalpatronen ervaren die frequente schaalaanpassingen en omlaag schalen tonen.

Als u de optimale hoeveelheid overprovisioning wilt bepalen, kunt u de volgende formule gebruiken:

1-buffer/1+traffic

Stel dat u wilt voorkomen dat u 100% CPU-gebruik in uw cluster bereikt. U kunt kiezen voor een buffer van 30% om een veiligheidsmarge te behouden. Als u een gemiddelde verkeersgroei van 40% verwacht, kunt u overwegen om de inrichting met 50% te verhogen, zoals wordt berekend door de formule:

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

Een effectieve methode voor overprovisioning omvat het gebruik van pauzepods. Onderbrekingspods zijn implementaties met lage prioriteit die eenvoudig kunnen worden vervangen door implementaties met hoge prioriteit. U maakt pods met lage prioriteit die het enige doel hebben om bufferruimte te reserveren. Wanneer voor een pod met hoge prioriteit ruimte is vereist, worden de pauzepods verwijderd en opnieuw gepland op een ander knooppunt of een nieuw knooppunt voor de pod met hoge prioriteit.

In de volgende YAML ziet u een voorbeeld van een podmanifest onderbreken:

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

Knooppunt schalen en efficiëntie

Richtlijnen voor aanbevolen procedures:

Bewaak het resourcegebruik en het planningsbeleid zorgvuldig om ervoor te zorgen dat knooppunten efficiënt worden gebruikt.

Met knooppuntschalen kunt u het aantal knooppunten in uw cluster dynamisch aanpassen op basis van de workloadvereisten. Het is belangrijk om te begrijpen dat het toevoegen van meer knooppunten aan een cluster niet altijd de beste oplossing is voor het verbeteren van de prestaties. Om optimale prestaties te garanderen, moet u het resourcegebruik en het planningsbeleid zorgvuldig bewaken om ervoor te zorgen dat knooppunten efficiënt worden gebruikt.

Knooppuntinstallatiekopieën

Richtlijnen voor aanbevolen procedures:

Gebruik de meest recente versie van de installatiekopieën van knooppunten om ervoor te zorgen dat u over de nieuwste beveiligingspatches en oplossingen voor fouten beschikt.

Het gebruik van de nieuwste versie van de knooppuntinstallatiekopieën biedt de beste prestaties. AKS verzendt prestatieverbeteringen binnen de wekelijkse installatiekopieënreleases. De nieuwste daemonset-installatiekopieën worden opgeslagen in de cache op de meest recente VHD-installatiekopie, die lagere latentievoordelen bieden voor het inrichten en opstarten van knooppunten. Het kan een negatieve invloed hebben op de prestaties van updates, dus het is belangrijk om grote hiaten tussen versies te voorkomen.

Azure Linux

De Azure Linux-containerhost op AKS maakt gebruik van een systeemeigen AKS-installatiekopie en biedt één plek voor Linux-ontwikkeling. Elk pakket is gebouwd op basis van de bron en gevalideerd, zodat uw services worden uitgevoerd op bewezen onderdelen.

Azure Linux is lichtgewicht, met inbegrip van de benodigde set pakketten voor het uitvoeren van containerworkloads. Het biedt een verminderd aanvalsoppervlak en elimineert patching en onderhoud van onnodige pakketten. Op de basislaag heeft het een door Microsoft beperkte kernel die is afgestemd op Azure. Deze installatiekopie is ideaal voor prestatiegevoelige workloads en platformtechnici of operators die vloot van AKS-clusters beheren.

Ubuntu 2204

De Ubuntu 2204-installatiekopie is de standaardinstallatiekopie van het knooppunt voor AKS. Het is een lichtgewicht en efficiënt besturingssysteem dat is geoptimaliseerd voor het uitvoeren van workloads in containers. Dit betekent dat het kan helpen bij het verminderen van het resourcegebruik en het verbeteren van de algehele prestaties. De installatiekopieën bevatten de nieuwste beveiligingspatches en updates, waarmee u ervoor kunt zorgen dat uw workloads worden beschermd tegen beveiligingsproblemen.

De Installatiekopie van Ubuntu 2204 wordt volledig ondersteund door Microsoft, Canonical en de Ubuntu-community en kan u helpen betere prestaties en beveiliging te bereiken voor uw workloads in containers.

Virtuele machines (VM's)

Richtlijnen voor aanbevolen procedures:

Wanneer u een VIRTUELE machine selecteert, moet u ervoor zorgen dat de grootte en prestaties van de besturingssysteemschijf en de VM-SKU geen grote discrepantie hebben. Een discrepantie in grootte of prestaties kan prestatieproblemen en resourceconflicten veroorzaken.

Toepassingsprestaties zijn nauw gekoppeld aan de VM-SKU's die u in uw workloads gebruikt. Grotere en krachtigere VM's bieden over het algemeen betere prestaties. Voor bedrijfskritieke workloads of productworkloads raden we u aan vm's met ten minste een CPU van 8 kernen te gebruiken. VM's met nieuwere hardwaregeneraties, zoals v4 en v5, kunnen ook helpen de prestaties te verbeteren. Houd er rekening mee dat het maken en schalen van latentie kan variëren, afhankelijk van de VM-SKU's die u gebruikt.

Toegewezen systeemknooppuntgroepen gebruiken

Voor het schalen van prestaties en betrouwbaarheid raden we u aan een toegewezen systeemknooppuntgroep te gebruiken. Met deze configuratie behoudt de toegewezen systeemknooppuntgroep ruimte voor kritieke systeemresources, zoals systeembesturingssysteem-daemons. Uw toepassingsworkload kan vervolgens worden uitgevoerd in een gebruikersknooppuntgroep om de beschikbaarheid van alle resources voor uw toepassing te verhogen. Deze configuratie helpt ook het risico op resourceconcurrentie tussen het systeem en de toepassing te beperken.

Maakbewerkingen

Controleer de extensies en invoegtoepassingen die u hebt ingeschakeld tijdens het maken van de inrichting. Extensies en invoegtoepassingen kunnen latentie toevoegen aan de totale duur van het maken van bewerkingen. Als u geen extensie of invoegtoepassing nodig hebt, wordt u aangeraden deze te verwijderen om de latentie te verbeteren.

U kunt ook beschikbaarheidszones gebruiken om een hoger beschikbaarheidsniveau te bieden om te beschermen tegen mogelijke hardwarefouten of geplande onderhoudsgebeurtenissen. AKS-clusters distribueren resources over logische secties van de onderliggende Azure-infrastructuur. Beschikbaarheidszones scheiden fysiek van andere knooppunten om ervoor te zorgen dat één fout geen invloed heeft op de beschikbaarheid van uw toepassing. Beschikbaarheidszones zijn alleen beschikbaar in bepaalde regio's. Zie Beschikbaarheidszones in Azure voor meer informatie.

Kubernetes API-server

LIST- en WATCH-bewerkingen

Kubernetes maakt gebruik van de LIST- en WATCH-bewerkingen om te communiceren met de Kubernetes-API-server en om informatie over clusterresources te bewaken. Deze bewerkingen zijn essentieel voor de wijze waarop Kubernetes resourcebeheer uitvoert.

De LIST-bewerking haalt een lijst met resources op die binnen bepaalde criteria passen, zoals alle pods in een specifieke naamruimte of alle services in het cluster. Deze bewerking is handig als u een overzicht wilt krijgen van uw clusterresources of als u meerdere resources tegelijk moet operatoren.

De LIST-bewerking kan grote hoeveelheden gegevens ophalen, met name in grote clusters met meerdere resources. Houd er rekening mee dat het maken van niet-gebonden of frequente LIST-aanroepen een aanzienlijke belasting op de API-server plaatst en de reactietijden kan afsluiten.

De WATCH-bewerking voert realtime resourcebewaking uit. Wanneer u een WATCH instelt voor een resource, stuurt de API-server u updates wanneer er wijzigingen in die resource zijn. Dit is belangrijk voor controllers, zoals de ReplicaSet-controller, die afhankelijk zijn van WATCH om de gewenste status van resources te behouden.

Houd er rekening mee dat het controleren van te veel veranderlijke resources of het maken van te veel gelijktijdige WATCH-aanvragen de API-server kan overweldigen en overmatig resourceverbruik kan veroorzaken.

Als u potentiële problemen wilt voorkomen en de stabiliteit van het Kubernetes-besturingsvlak wilt waarborgen, kunt u de volgende strategieën gebruiken:

Resourcequota

Implementeer resourcequota om het aantal resources te beperken dat door een bepaalde gebruiker of naamruimte kan worden weergegeven of bekeken om overmatige aanroepen te voorkomen.

API-prioriteit en -billijkheid

Kubernetes heeft het concept API Priority and Fairness (APF) geïntroduceerd om API-aanvragen te prioriteren en beheren. U kunt APF in Kubernetes gebruiken om de API-server van het cluster te beveiligen en het aantal reacties dat HTTP 429 Too Many Requests wordt gezien door clienttoepassingen te verminderen.

Aangepaste resource Belangrijkste functies
PriorityLevelConfigurations • Verschillende prioriteitsniveaus definiëren voor API-aanvragen.
• Hiermee geeft u een unieke naam op en wijst u een geheel getal toe dat het prioriteitsniveau vertegenwoordigt. Hogere prioriteitsniveaus hebben lagere gehele getallen, wat aangeeft dat ze belangrijker zijn.
• Kan meerdere gebruiken om aanvragen in verschillende prioriteitsniveaus te categoriseren op basis van hun belang.
• Hiermee kunt u opgeven of aanvragen op een bepaald prioriteitsniveau moeten worden onderworpen aan frequentielimieten.
Stroomschema's • Definieer hoe API-aanvragen moeten worden doorgestuurd naar verschillende prioriteitsniveaus op basis van aanvraagkenmerken.
• Geef regels op die overeenkomen met aanvragen op basis van criteria zoals API-groepen, versies en resources.
• Wanneer een aanvraag overeenkomt met een bepaalde regel, wordt de aanvraag omgeleid naar het prioriteitsniveau dat is opgegeven in de bijbehorende PriorityLevelConfiguration.
• Kan de volgorde van de evaluatie instellen wanneer meerdere FlowSchema's overeenkomen met een aanvraag om ervoor te zorgen dat bepaalde regels voorrang krijgen.

Het configureren van API met PriorityLevelConfigurations en FlowSchemas maakt het prioriteren van kritieke API-aanvragen mogelijk voor minder belangrijke aanvragen. Dit zorgt ervoor dat essentiële bewerkingen niet uitsterven of vertragingen ondervinden vanwege aanvragen met een lagere prioriteit.

Labelen en selectors optimaliseren

Wanneer u LIST-bewerkingen gebruikt, optimaliseert u labelkiezers om het bereik te beperken van de resources waarop u een query wilt uitvoeren om de hoeveelheid geretourneerde gegevens en de belasting op de API-server te verminderen.

In Kubernetes CREATE- en UPDATE-bewerkingen verwijst u naar acties die clusterresources beheren en wijzigen.

BEWERKINGEN VOOR MAKEN en BIJWERKEN

Met de bewerking CREATE worden nieuwe resources gemaakt in het Kubernetes-cluster, zoals pods, services, implementaties, configuratiekaarten en geheimen. Tijdens een CREATE-bewerking verzendt een client, zoals kubectl of een controller, een aanvraag naar de Kubernetes-API-server om de nieuwe resource te maken. De API-server valideert de aanvraag, zorgt ervoor dat de toegangscontrollerbeleid wordt nageleefd en maakt vervolgens de resource in de gewenste status van het cluster.

De UPDATE-bewerking wijzigt bestaande resources in het Kubernetes-cluster, inclusief wijzigingen in de specificaties van resources, zoals het aantal replica's, containerinstallatiekopieën, omgevingsvariabelen of labels. Tijdens een UPDATE-bewerking verzendt een client een aanvraag naar de API-server om een bestaande resource bij te werken. De API-server valideert de aanvraag, past de wijzigingen toe op de resourcedefinitie en werkt de clusterresource bij.

CREATE- en UPDATE-bewerkingen kunnen van invloed zijn op de prestaties van de Kubernetes-API-server onder de volgende omstandigheden:

  • Hoge gelijktijdigheid: wanneer meerdere gebruikers of toepassingen gelijktijdige CREATE- of UPDATE-aanvragen maken, kan dit leiden tot een piek in API-aanvragen die op hetzelfde moment op de server binnenkomen. Dit kan de verwerkingscapaciteit van de API-server benadrukken en prestatieproblemen veroorzaken.
  • Complexe resourcedefinities: Resourcedefinities die te complex zijn of waarbij meerdere geneste objecten betrokken zijn, kunnen de tijd die nodig is voordat de API-server CREATE- en UPDATE-aanvragen valideert en verwerkt, wat kan leiden tot prestatievermindering.
  • Resourcevalidatie en toegangsbeheer: Kubernetes dwingt verschillende beleidsregels voor toegangsbeheer en validatie af op binnenkomende CREATE- en UPDATE-aanvragen. Voor grote resourcedefinities, zoals definities met uitgebreide aantekeningen of configuraties, is mogelijk meer verwerkingstijd vereist.
  • Aangepaste controllers: aangepaste controllers die controleren op wijzigingen in resources, zoals Implementaties of StatefulSet-controllers, kunnen een aanzienlijk aantal updates genereren bij het schalen of implementeren van wijzigingen. Deze updates kunnen de resources van de API-server belasten.

Zie Problemen met de API-server en etcd in AKS oplossen voor meer informatie.

Prestaties van gegevensvlak

Het Kubernetes-gegevensvlak is verantwoordelijk voor het beheren van netwerkverkeer tussen containers en services. Problemen met het gegevensvlak kunnen leiden tot trage reactietijden, verminderde prestaties en downtime van toepassingen. Het is belangrijk om configuraties van gegevensvlakken zorgvuldig te bewaken en optimaliseren, zoals netwerklatentie, resourcetoewijzing, containerdichtheid en netwerkbeleid, om ervoor te zorgen dat uw containertoepassingen soepel en efficiënt worden uitgevoerd.

Opslagtypen

AKS raadt aan en standaardwaarden voor het gebruik van tijdelijke besturingssysteemschijven. Tijdelijke besturingssysteemschijven worden gemaakt op lokale VM-opslag en worden niet opgeslagen in externe Azure-opslag, zoals beheerde besturingssysteemschijven. Ze hebben snellere herstart- en opstarttijden, waardoor snellere clusterbewerkingen mogelijk zijn en ze bieden een lagere latentie voor lezen/schrijven op de besturingssysteemschijf van AKS-agentknooppunten. Tijdelijke besturingssysteemschijven werken goed voor staatloze werkbelastingen, waarbij toepassingen tolerant zijn voor afzonderlijke VM-fouten, maar niet van vm-implementatietijd of afzonderlijke instanties van VM-implementatie. Alleen bepaalde VM-SKU's ondersteunen tijdelijke besturingssysteemschijven, dus u moet ervoor zorgen dat de gewenste SKU-generatie en -grootte compatibel is. Zie kortstondige besturingssysteemschijven in Azure Kubernetes Service (AKS) voor meer informatie.

Als uw werkbelasting geen tijdelijke besturingssysteemschijven kan gebruiken, wordt standaard gebruikgemaakt van Premium SSD OS-schijven. Als Premium SSD-besturingssysteemschijven niet compatibel zijn met uw workload, wordt AKS standaard ingesteld op Standard SSD-schijven. Momenteel is het enige andere beschikbare besturingssysteemschijftype Standard HDD. Zie Opslagopties in Azure Kubernetes Service (AKS) voor meer informatie.

De volgende tabel bevat een uitsplitsing van voorgestelde gebruiksvoorbeelden voor besturingssysteemschijven die worden ondersteund in AKS:

Type besturingssysteemschijf Belangrijkste functies Voorgestelde gebruiksvoorbeelden
Kortstondige besturingssysteemschijven • Snellere herstart en opstarttijden.
• Lagere lees-/schrijflatentie op besturingssysteemschijf van AKS-agentknooppunten.
• Hoge prestaties en beschikbaarheid.		 • Veeleisende bedrijfsworkloads, zoals SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite, enzovoort.
• Stateless productieworkloads die hoge beschikbaarheid en lage latentie vereisen.
Premium SSD-besturingssysteemschijven • Consistente prestaties en lage latentie.
• Hoge beschikbaarheid.		 • Veeleisende bedrijfsworkloads, zoals SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite, enzovoort.
• Invoer-/uitvoerintensieve bedrijfsworkloads (IO).
Standard SSD OS-schijven • Consistente prestaties.
• Betere beschikbaarheid en latentie vergeleken met Standard HDD-schijven.		 • Webservers.
• Lage invoer-/uitvoerbewerkingen per seconde (IOPS) toepassingsservers.
• Licht gebruikte bedrijfstoepassingen.
• Ontwikkel-/testworkloads.
Standard HDD-schijven • Lage kosten.
• Vertoont variabiliteit in prestaties en latentie.		 • Back-upopslag.
• Massaopslag met onregelmatige toegang.

IOPS en doorvoer

Invoer-/uitvoerbewerkingen per seconde (IOPS) verwijst naar het aantal lees- en schrijfbewerkingen die een schijf in een seconde kan uitvoeren. Doorvoer verwijst naar de hoeveelheid gegevens die in een bepaalde periode kan worden overgedragen.

Besturingssysteemschijven zijn verantwoordelijk voor het opslaan van het besturingssysteem en de bijbehorende bestanden, en de VM's zijn verantwoordelijk voor het uitvoeren van de toepassingen. Wanneer u een VIRTUELE machine selecteert, moet u ervoor zorgen dat de grootte en prestaties van de besturingssysteemschijf en de VM-SKU geen grote discrepantie hebben. Een discrepantie in grootte of prestaties kan prestatieproblemen en resourceconflicten veroorzaken. Als de besturingssysteemschijf bijvoorbeeld aanzienlijk kleiner is dan de vm's, kan de hoeveelheid ruimte die beschikbaar is voor toepassingsgegevens beperken en ervoor zorgen dat het systeem onvoldoende schijfruimte heeft. Als de besturingssysteemschijf lagere prestaties heeft dan de VM's, kan dit een knelpunt worden en de algehele prestaties van het systeem beperken. Zorg ervoor dat de grootte en prestaties zijn verdeeld om optimale prestaties in Kubernetes te garanderen.

U kunt de volgende stappen gebruiken om IOPS en bandbreedtemeters op besturingssysteemschijven te bewaken in Azure Portal:

  1. Ga naar de Azure Portal.
  2. Zoek naar virtuele-machineschaalsets en selecteer uw virtuele-machineschaalset.
  3. Selecteer Metrische gegevens onder Bewaking.

Tijdelijke besturingssysteemschijven kunnen dynamische IOPS en doorvoer bieden voor uw toepassing, terwijl beheerde schijven IOPS en doorvoer hebben beperkt. Zie kortstondige besturingssysteemschijven voor Virtuele Azure-machines voor meer informatie.

Azure Premium SSD v2 is ontworpen voor IO-intensieve bedrijfsworkloads waarvoor een latentie van een schijf van minder dan milliseconden en hoge IOPS en doorvoer tegen lage kosten is vereist. Het is geschikt voor een breed scala aan workloads, zoals SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data/analytics, gaming en meer. Dit schijftype is de meest presterende optie die momenteel beschikbaar is voor permanente volumes.

Podplanning

Het geheugen en de CPU-resources die aan een VIRTUELE machine zijn toegewezen, hebben een directe invloed op de prestaties van de pods die op de VIRTUELE machine worden uitgevoerd. Wanneer een pod wordt gemaakt, wordt een bepaalde hoeveelheid geheugen en CPU-resources toegewezen die worden gebruikt om de toepassing uit te voeren. Als de VM onvoldoende geheugen of CPU-resources beschikbaar heeft, kan dit ertoe leiden dat de pods vertragen of zelfs crashen. Als de VM te veel geheugen of CPU-resources beschikbaar heeft, kan dit ertoe leiden dat de pods efficiënt worden uitgevoerd, resources verspillen en de kosten verhogen. We raden u aan om de totale podaanvragen voor uw workloads te bewaken op basis van de totale beschikbare resources voor de beste plannings voorspelbaarheid en prestaties. U kunt ook de maximale pods per knooppunt instellen op basis van uw capaciteitsplanning met behulp van --max-pods.