Aanbevolen procedures voor prestaties en schalen voor grote workloads in Azure Kubernetes Service (AKS)

Notitie

Dit artikel is gericht op algemene aanbevolen procedures voor grote workloads. Zie best practices die specifiek zijn voor kleine tot middelgrote workloads, best practices voor prestaties en schaalaanpassing voor kleine tot middelgrote 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.

Houd er rekening mee dat groot een relatieve term is. Kubernetes heeft een multidimensionale envelop en de schaalvelop voor uw workload is afhankelijk van de resources die u gebruikt. Een cluster met 100 knooppunten en duizenden pods of CRD's kan bijvoorbeeld worden beschouwd als groot. Een cluster met 1.000 knooppunten met 1.000 pods en verschillende andere resources kan vanuit het perspectief van het besturingsvlak als klein worden beschouwd. Het beste signaal voor de schaal van een Kubernetes-besturingsvlak is het succespercentage en de latentie van de API-serverserver, omdat dit een proxy is voor de hoeveelheid belasting op het besturingsvlak.

In dit artikel krijgt u meer informatie over:

• Schaalbaarheid van AKS- en Kubernetes-besturingsvlak.
• Aanbevolen procedures voor Kubernetes Client, waaronder uitstel, horloges en paginering.
• Beperkingslimieten voor Azure API en platform.
• Functiebeperkingen.
• Aanbevolen procedures voor schalen van netwerken en knooppuntgroepen.

Schaalbaarheid van AKS- en Kubernetes-besturingsvlak

In AKS bestaat een cluster uit een set knooppunten (fysieke of virtuele machines (VM's) waarop Kubernetes-agents worden uitgevoerd en die worden beheerd door het Kubernetes-besturingsvlak dat wordt gehost door AKS. Hoewel AKS het Kubernetes-besturingsvlak en de bijbehorende onderdelen voor schaalbaarheid en prestaties optimaliseert, is het nog steeds gebonden aan de upstream-projectlimieten.

Kubernetes heeft een multidimensionale schaalvelop met elk resourcetype dat een dimensie vertegenwoordigt. Niet alle resources zijn gelijk. Horloges zijn bijvoorbeeld vaak ingesteld op geheimen, wat resulteert in lijstoproepen naar de kube-apiserver die kosten toevoegen en een onevenredig hogere belasting op het besturingsvlak in vergelijking met resources zonder horloges.

Het besturingsvlak beheert alle schaalaanpassing van resources in het cluster, dus hoe meer u het cluster in een bepaalde dimensie schaalt, hoe minder u binnen andere dimensies kunt schalen. Het uitvoeren van honderdduizenden pods in een AKS-cluster heeft bijvoorbeeld invloed op het aantal podverlooppercentages (podmutaties per seconde) dat het besturingsvlak kan ondersteunen.

De grootte van de envelop is evenredig met de grootte van het Kubernetes-besturingsvlak. AKS ondersteunt drie besturingsvlaklagen als onderdeel van de Basis-SKU: Gratis, Standard en Premium-laag. Zie de prijscategorieën Gratis, Standard en Premium voor AKS-clusterbeheer voor meer informatie.

Belangrijk

We raden u ten zeerste aan om de Standard- of Premium-laag te gebruiken voor productie- of workloads op schaal. AKS schaalt automatisch het Kubernetes-besturingsvlak op om de volgende schaallimieten te ondersteunen:

• Maximaal 5000 knooppunten per AKS-cluster
• 200.000 pods per AKS-cluster (met Azure CNI-overlay)

In de meeste gevallen leidt het overschrijden van de drempelwaarde voor schaallimiet tot verminderde prestaties, maar zorgt er niet voor dat het cluster onmiddellijk een failover uitvoert. Als u de belasting op het Kubernetes-besturingsvlak wilt beheren, kunt u overwegen om in batches van maximaal 10-20% van de huidige schaal te schalen. Schaal bijvoorbeeld in stappen van 500-1000 knooppunten in stappen van 500-1.000 knooppunten. Hoewel AKS uw besturingsvlak automatisch schaalt, gebeurt dit niet onmiddellijk.

U kunt gebruikmaken van API Priority and Fairness (APF) om specifieke clients en aanvraagtypen te beperken om het besturingsvlak tijdens hoog verloop en belasting te beveiligen.

Kubernetes-clients

Kubernetes-clients zijn de toepassingenclients, zoals operators of bewakingsagents, die zijn geïmplementeerd in het Kubernetes-cluster die moeten communiceren met de kube-API-server om lees- of mutatiebewerkingen uit te voeren. Het is belangrijk om het gedrag van deze clients te optimaliseren om de belasting te minimaliseren die ze toevoegen aan de kube-api-server en het Kubernetes-besturingsvlak.

U kunt het verkeer en het clientgedrag van de API-server analyseren via Kube-auditlogboeken. Zie Problemen met het Kubernetes-besturingsvlak oplossen voor meer informatie.

LIST-aanvragen kunnen duur zijn. Wanneer u werkt met lijsten met meer dan een paar duizend kleine objecten of meer dan een paar honderd grote objecten, moet u rekening houden met de volgende richtlijnen:

• Houd rekening met het aantal objecten (CR's) dat u verwacht uiteindelijk te hebben bij het definiëren van een nieuw resourcetype (CRD).
• De belasting van etcd en API-server is voornamelijk afhankelijk van het aantal objecten dat bestaat, niet het aantal objecten dat wordt geretourneerd. Zelfs als u een veldkiezer gebruikt om de lijst te filteren en slechts een klein aantal resultaten op te halen, zijn deze richtlijnen nog steeds van toepassing. De enige uitzondering is het ophalen van één object door metadata.name.
• Vermijd indien mogelijk herhaalde LIST-aanroepen als uw code een bijgewerkte lijst met objecten in het geheugen moet onderhouden. In plaats daarvan kunt u overwegen de Informer-klassen in de meeste Kubernetes-bibliotheken te gebruiken. Informers combineren automatisch LIST- en WATCH-functies om een in-memory verzameling efficiënt te onderhouden.
• Overweeg of u sterke consistentie nodig hebt als Informers niet aan uw behoeften voldoen. Moet u de meest recente gegevens zien, tot op het exacte moment dat u de query hebt uitgegeven? Als dat niet het is, stelt u het ResourceVersion=0in. Dit zorgt ervoor dat de API-servercache uw aanvraag verwerkt in plaats van enzovoort.
• Als u Informers of de CACHE van de API-server niet kunt gebruiken, leest u grote lijsten in segmenten.
• Vermijd vermeldingen vaker dan nodig is. Als u Informers niet kunt gebruiken, kunt u overwegen hoe vaak uw toepassing de resources vermeldt. Nadat u het laatste object in een grote lijst hebt gelezen, moet u niet onmiddellijk dezelfde lijst opnieuw opvragen. In plaats daarvan moet u even wachten.
• Houd rekening met het aantal actieve exemplaren van uw clienttoepassing. Er is een groot verschil tussen het hebben van één controller met objecten versus het hebben van pods op elk knooppunt dat hetzelfde doet. Als u van plan bent om meerdere exemplaren van uw clienttoepassing regelmatig grote aantallen objecten weer te geven, wordt uw oplossing niet geschaald naar grote clusters.

Beperking van Azure API en platform

De belasting van een cloudtoepassing kan in de loop van de tijd variëren op basis van factoren zoals het aantal actieve gebruikers of de typen acties die gebruikers uitvoeren. Als de verwerkingsvereisten van het systeem de capaciteit van de beschikbare resources overschrijden, kan het systeem overbelast raken en lijden aan slechte prestaties en storingen.

Als u verschillende belastingsgrootten in een cloudtoepassing wilt verwerken, kunt u toestaan dat de toepassing resources tot een opgegeven limiet gebruikt en deze vervolgens beperkt wanneer de limiet is bereikt. In Azure vindt beperking plaats op twee niveaus. Azure Resource Manager (ARM) beperkt aanvragen voor het abonnement en de tenant. Als de aanvraag onder de beperkingslimieten voor het abonnement en de tenant valt, stuurt ARM de aanvraag naar de resourceprovider. De resourceprovider past vervolgens beperkingslimieten toe die zijn afgestemd op de bewerkingen. Zie ARM-beperkingsaanvragen voor meer informatie.

Beperking beheren in AKS

Azure API-limieten worden meestal gedefinieerd op een combinatieniveau van een abonnementsregio. Zo delen alle clients binnen een abonnement in een bepaalde regio API-limieten voor een bepaalde Azure-API, zoals PUT-API's voor virtuele-machineschaalsets. Elk AKS-cluster heeft verschillende AKS-clients, zoals cloudprovider of automatische schaalaanpassing van clusters, of clients die eigendom zijn van de klant, zoals Datadog of zelf-hostende Prometheus, die Azure-API's aanroepen. Wanneer u meerdere AKS-clusters uitvoert in een abonnement binnen een bepaalde regio, delen alle AKS-clients en klanten in de clusters een gemeenschappelijke set API-limieten. Daarom is het aantal clusters dat u in een abonnementsregio kunt implementeren een functie van het aantal geïmplementeerde clients, hun oproeppatronen en de algehele schaal en elasticiteit van de clusters.

Houd rekening met de bovenstaande overwegingen, klanten kunnen doorgaans tussen 20-40 kleine tot middelgrote clusters per abonnementsregio implementeren. U kunt de schaal van uw abonnement maximaliseren met behulp van de volgende aanbevolen procedures:

Werk uw Kubernetes-clusters altijd bij naar de nieuwste versie. Nieuwere versies bevatten veel verbeteringen waarmee prestatie- en beperkingsproblemen worden opgelost. Als u een bijgewerkte versie van Kubernetes gebruikt en nog steeds beperking ziet vanwege de werkelijke belasting of het aantal clients in het abonnement, kunt u de volgende opties proberen:

• Fouten analyseren met behulp van AKS Diagnose en Problemen oplossen: U kunt AKS-diagnoses en problemen oplossen gebruiken om fouten te analyseren, de hoofdoorzaak te identificeren en aanbevelingen voor de oplossing op te halen.
  • Verhoog het scaninterval voor automatische schaalaanpassing van clusters: als in de diagnostische rapporten wordt aangegeven dat automatische schaalaanpassing van clusters is gedetecteerd, kunt u het scaninterval verhogen om het aantal aanroepen naar virtuele-machineschaalsets te verminderen vanuit de automatische schaalaanpassing van clusters.
  • Configureer toepassingen van derden opnieuw om minder aanroepen te doen: als u filtert op gebruikersagenten in de aanvraagfrequentie weergeven en details diagnosticeren en zien dat een toepassing van derden, zoals een bewakingstoepassing, een groot aantal GET-aanvragen maakt, kunt u de instellingen van deze toepassingen wijzigen om de frequentie van de GET-aanroepen te verminderen. Zorg ervoor dat de toepassingsclients exponentieel uitstel gebruiken bij het aanroepen van Azure-API's.
• Splits uw clusters in verschillende abonnementen of regio's: als u een groot aantal clusters en knooppuntgroepen hebt die gebruikmaken van Virtuele-machineschaalsets, kunt u deze splitsen in verschillende abonnementen of regio's binnen hetzelfde abonnement. De meeste Azure API-limieten worden gedeeld op abonnementsregioniveau, zodat u uw clusters kunt verplaatsen of schalen naar verschillende abonnementen of regio's om de blokkering op azure-API-beperking op te heffen. Deze optie is vooral handig als u verwacht dat uw clusters een hoge activiteit hebben. Er zijn geen algemene richtlijnen voor deze limieten. Als u specifieke richtlijnen wilt, kunt u een ondersteuningsticket maken.

Functiebeperkingen

Houd rekening met de volgende functiebeperkingen wanneer u uw AKS-clusters schaalt naar grotere schaalpunten:

• AKS ondersteunt het schalen van maximaal 5000 knooppunten standaard voor alle Standard-laag-/LTS-clusters. AKS schaalt het besturingsvlak van uw cluster tijdens runtime op basis van clustergrootte en resourcegebruik van API-servers. Als u niet naar de ondersteunde limiet kunt schalen, schakelt u metrische gegevens van het besturingsvlak (preview) in met de beheerde Azure Monitor-service voor Prometheus om het besturingsvlak te bewaken. Raadpleeg de volgende bronnen om problemen met schaalprestaties of betrouwbaarheid op te lossen:
  • Probleemoplossingsgids voor AKS op schaal
  • Problemen met het Kubernetes-besturingsvlak oplossen

Notitie

Tijdens de bewerking om het besturingsvlak te schalen, kan er een verhoogde latentie of time-outs van de API-server optreden gedurende maximaal 15 minuten. Als u problemen ondervindt bij het schalen naar de ondersteunde limiet, opent u een ondersteuningsticket.

• Azure Network Policy Manager (Azure npm) ondersteunt alleen maximaal 250 knooppunten.
• Sommige metrische gegevens van AKS-knooppunten, waaronder schijfgebruik van knooppunten, CPU-/geheugengebruik en netwerk in/uit, zijn niet toegankelijk in metrische gegevens van het Azure Monitor-platform nadat het besturingsvlak is opgeschaald. Als u wilt controleren of uw besturingsvlak omhoog is geschaald, zoekt u naar de configuratiemap 'control-plane-scaling-status'

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

• U kunt de functie Stoppen en Starten niet gebruiken met clusters met meer dan 100 knooppunten. Zie Een AKS-cluster stoppen en starten voor meer informatie.

Netwerken

Wanneer u uw AKS-clusters schaalt naar grotere schaalpunten, moet u rekening houden met de volgende aanbevolen netwerkprocedures:

• Beheerde NAT gebruiken voor uitgaand clusterverkeer met ten minste twee openbare IP-adressen op de NAT-gateway. Zie Een beheerde NAT-gateway voor uw AKS-cluster maken voor meer informatie.
• Gebruik Azure CNI Overlay om maximaal 200.000 pods en 5000 knooppunten per cluster te schalen. Zie Azure CNI Overlay-netwerken configureren in AKS voor meer informatie.
• Als uw toepassing directe pod-naar-pod-communicatie tussen clusters nodig heeft, gebruikt u Azure CNI met dynamische IP-toewijzing en schaalt u maximaal 50.000 toepassingspods per cluster met één routeerbaar IP-adres per pod. Zie Azure CNI-netwerken configureren voor dynamische IP-toewijzing in AKS voor meer informatie.
• Wanneer u interne Kubernetes-services achter een interne load balancer gebruikt, raden we u aan een interne load balancer of service onder een schaal van 750 knooppunten te maken voor optimale schaalprestaties en elasticiteit van load balancer.
• Azure npm ondersteunt alleen maximaal 250 knooppunten. Als u netwerkbeleid wilt afdwingen voor grotere clusters, kunt u overwegen Om Azure CNI te gebruiken die wordt aangedreven door Cilium, waarmee het robuuste besturingsvlak van Azure CNI wordt gecombineerd met het Cilium-gegevensvlak om netwerken en beveiliging met hoge prestaties te bieden.

Schalen van knooppuntgroep

Wanneer u uw AKS-clusters schaalt naar grotere schaalpunten, moet u rekening houden met de volgende aanbevolen procedures voor schalen van knooppuntgroepen:

• Gebruik voor systeemknooppuntgroepen de Standard_D16ds_v5 SKU of een equivalente VM-SKU met tijdelijke besturingssysteemschijven om voldoende rekenresources te bieden voor kube-systeempods.
• Omdat AKS een limiet van 1000 knooppunten per knooppuntgroep heeft, raden we u aan ten minste vijf gebruikersknooppuntgroepen te maken om maximaal 5000 knooppunten te schalen.
• Wanneer u AKS-clusters op schaal uitvoert, gebruikt u de automatische schaalaanpassing van clusters indien mogelijk om dynamische schaalaanpassing van knooppuntgroepen te garanderen op basis van de vraag naar rekenresources. Zie Automatisch een AKS-cluster schalen om te voldoen aan de toepassingsvereisten voor meer informatie.
• Als u meer dan 1000 knooppunten schaalt en de automatische schaalaanpassing van clusters niet gebruikt, raden we u aan om in batches van 500-700 knooppunten tegelijk te schalen. De schaalbewerkingen moeten een wachttijd van twee minuten tot vijf minuten hebben tussen omhoog schalen om beperking van De Azure-API te voorkomen. Zie API Management: Beleid voor caching en beperking voor meer informatie.

Overwegingen en aanbevolen procedures voor clusterupgrades

• Wanneer een cluster de limiet van 5000 knooppunten bereikt, worden clusterupgrades geblokkeerd. Deze limieten voorkomt een upgrade omdat er geen capaciteit beschikbaar is voor knooppunten om rolling updates uit te voeren binnen de maximale limiet voor piekeigenschappen. Als u een cluster met deze limiet hebt, raden we u aan om het cluster onder 3000 knooppunten omlaag te schalen voordat u een clusterupgrade uitvoert. Dit biedt extra capaciteit voor knooppuntverloop en minimaliseert de belasting op het besturingsvlak.
• Wanneer u clusters met meer dan 500 knooppunten bijwerken, is het raadzaam om een maximale piekconfiguratie van 10-20% van de capaciteit van de knooppuntgroep te gebruiken. AKS configureert upgrades met een standaardwaarde van 10% voor maximale piek. U kunt de maximale piekinstellingen per knooppuntgroep aanpassen om een afweging te maken tussen upgradesnelheid en werkbelastingonderbreking. Wanneer u de maximale piekinstellingen verhoogt, wordt het upgradeproces sneller voltooid, maar kunnen er onderbrekingen optreden tijdens het upgradeproces. Zie Piekupgrade van knooppunten aanpassen voor meer informatie.
• Zie Een AKS-cluster upgraden voor meer informatie over clusterupgrades.