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

Opmerking

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

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:

  • Knooppunt schalen.
  • Schaalbaarheid van AKS- en Kubernetes-besturingsvlak.
  • Aanbevolen procedures voor Kubernetes-clients, waaronder uitstel, horloges en paginering.
  • Azure API- en platformbeperkingslimieten.
  • Functiebeperkingen.
  • Aanbevolen procedures voor netwerken.

Knooppunten schalen

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

  • Wanneer u AKS-clusters op schaal uitvoert, gebruikt u waar mogelijk de automatische schaalaanpassing van clusters of knooppunten om dynamische schaalaanpassing van knooppunten te garanderen op basis van de vraag naar rekenresources.
  • 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 tot vijf minuten tussen de opschalingen hebben om Azure API-throttling te voorkomen. Zie API Management: Beleid voor caching en beperking voor meer informatie.
  • Voor systeemknooppuntgroepen gebruikt u de Standard_D16ds_v5 SKU of een equivalente VM-SKU voor kern-/geheugen-VM's 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.

Schaalbaarheid van AKS- en Kubernetes-besturingsvlak

In Kubernetes worden alle objecten die in een cluster worden uitgevoerd, beheerd door het besturingsvlak, dat wordt beheerd 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, waarbij elk resourcetype een dimensie vertegenwoordigt en niet alle resources gelijk zijn aan hun kosten. Geheimen worden bijvoorbeeld vaak bekeken door meerdere controllers en pods, die elk een eerste LIST-aanroep doen om de status te synchroniseren. Omdat secrets doorgaans groot en regelmatig worden bijgewerkt, leggen ze meer belasting op het besturingsvlak dan minder vaak bekeken bronnen.

Hoe meer u het cluster schaalt binnen een bepaalde dimensie, 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.

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

Gebruik de Standard- of Premium-laag voor productie- of schaalworkloads. 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 voor een cluster van 5.000 knooppunten in stappen van 500-1.000 knooppunten. Hoewel AKS uw controlevlak automatisch schaalt, gebeurt dit niet meteen.

Als u wilt controleren of uw besturingsvlak omhoog is geschaald, zoekt u naar de configuratiemap large-cluster-control-plane-scaling-status.

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

Overwegingen voor omvang en controlevlak bij het schalen van Kubernetes

Kubernetes-clients zijn toepassingsonderdelen, zoals operators of bewakingsagents, die worden uitgevoerd in het cluster en communiceren met de kube-apiserver om resources te lezen of te wijzigen. Het is belangrijk om te optimaliseren hoe deze clients zich gedragen om de belasting te verminderen die ze op de kube-apiserver en het Kubernetes-besturingsvlak plaatsen.

Het aantal aanvragen dat op een bepaald moment actief door de API-server wordt verwerkt, wordt bepaald door --max-requests-inflight en --max-mutating-requests-inflight vlaggen. AKS gebruikt de standaardwaarden van 400 en 200 aanvragen voor deze vlaggen, zodat er op een bepaald moment in totaal 600 aanvragen kunnen worden verzonden. Naarmate we de API-server schalen naar grotere grootten, vergroten we ook de aanvragen voor vluchten.

Twee Kubernetes-objecttypen, PriorityLevelConfiguration en FlowSchema (APF) bepalen hoe de API-server de totale aanvraagcapaciteit over aanvraagtypen verdeelt. AKS maakt gebruik van de standaardconfiguratie.

Aan elke PriorityLevelConfiguration wordt een share toegewezen van de totale toegestane aanvragen. Als u de PriorityLevelConfiguration-objecten in uw cluster en de toegewezen aanvraagshares wilt weergeven, voert u de volgende opdracht uit.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema wijst API-serveraanvragen toe aan een PriorityLevelConfiguration. Als meerdere FlowSchema-objecten overeenkomen met een aanvraag, selecteert de API-server het object met de laagste overeenkomende prioriteit.

De toewijzing van FlowSchemas aan PriorityLevelConfigurations kan worden weergegeven met behulp van deze opdracht:

kubectl get flowschemas

Voer de volgende opdracht uit om te controleren of er aanvragen worden verwijderd vanwege APF:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Best practices voor Kubernetes-clients

LIST-aanroepen die worden uitgegeven door niet-geoptimaliseerde clients zijn vaak een van de grootste factoren die de schaalbaarheid van een cluster beperken. 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 de grootte van het antwoord. Deze richtlijnen zijn van toepassing of de client een klein aantal LIST-aanvragen voor grote objecten of een groot aantal LIST-aanvragen voor kleinere objecten uitgeeft.

Informanten gebruiken

  • Als uw code een bijgewerkte lijst met objecten in het geheugen moet onderhouden, krijgt u met behulp van een informant van de client-go-bibliotheek voordelen van het controleren op wijzigingen in de resources op basis van gebeurtenissen in plaats van te peilen naar wijzigingen. Dit is de beste methode om niet-geoptimaliseerde en herhaalde LIST's te voorkomen.

API-servercache gebruiken

  • Gebruik resourceVersion=0 dit om resultaten te retourneren uit de CACHE van de API-server. Dit kan voorkomen dat objecten worden opgehaald uit etcd, waardoor de etcd-belasting wordt verminderd, maar het biedt geen ondersteuning voor paginering.

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

Efficiënt kubernetes-API-gebruik

  • Het wordt aanbevolen om waar mogelijk het horlogeargument te gebruiken. Zonder argumenten is het standaardgedrag het weergeven van objecten. Raadpleeg het onderstaande voorbeeld.

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

    Gebruik de horloge met een resourceVersion die is ingesteld als de meest recente bekende waarde die is ontvangen van de voorgaande lijst of horloge. Dit wordt automatisch verwerkt in client-go. Controleer echter of u een Kubernetes-client in andere talen gebruikt.

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

  • Als controllers of operators gebruik moeten maken van LIST-aanroepen, moeten ze voorkomen dat ze clusterbrede resources opvragen zonder label- of veldselectors, vooral in grote clusters. In de volgende voorbeelden ziet u geoptimaliseerde en niet-geoptimaliseerde LIST-aanroepen.

    Geoptimaliseerde LIJST:

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

    Niet-geoptimaliseerde LIJST:

    /api/v1/pods

  • Gebruik paginering om de grootte van LIST-antwoorden te verkleinen als de client gegevens uit etcd moet ophalen. In het volgende voorbeeld wordt het limietargument gebruikt om het antwoord te beperken tot 100 objecten.

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

    Als u wilt dat de LIJST alle podobjecten in het bovenstaande voorbeeld blijft retourneren, gebruikt u het argument Doorgaan met een limiet.

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

    Als kubectl wordt gebruikt, --chunk-size kan het argument rechtstreeks worden toegepast op gepagineerde antwoorden.

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

  • Als uw controllers of operators lease-updates gebruiken voor leiderverkiezing, moet u ervoor zorgen dat ze bestand zijn tegen tijdelijke connectiviteitsproblemen door het afstemmen van leaseDuration, renewDeadline, en retryPeriod die optimaal zijn voor uw workloads. Gebruik de volgende formule voor Kubernetes-controllers die gebruikmaken van verkiezingen voor leider op basis van client-go:

    lease_duration > renew_deadline > retry_period

Daemonsets

  • Er is een significant verschil tussen een enkele controller die objecten opsomt en een DaemonSet die op elk knooppunt hetzelfde doet. Als meerdere exemplaren van uw clienttoepassing periodiek grote aantallen objecten vermelden, kan de oplossing niet goed worden geschaald in grote clusters.

  • Op clusters met duizenden knooppunten, het maken van een nieuwe DaemonSet, het bijwerken van een DaemonSet of het verhogen van het aantal knooppunten kan leiden tot een hoge belasting op het besturingsvlak. Als DaemonSet-pods dure API-serveraanvragen uitgeven bij het opstarten van pods, kunnen ze een hoog resourcegebruik op het besturingsvlak veroorzaken vanaf een groot aantal gelijktijdige aanvragen.

  • Gebruik een RollingUpdate-strategie om nieuwe DaemonSet-pods geleidelijk uit te rollen. Wanneer de DaemonSet-sjabloon wordt bijgewerkt, vervangt de controller oude pods door nieuwe pods op een gecontroleerde manier. Wanneer de strategie voor rolling update niet expliciet is geconfigureerd, wordt in Kubernetes standaard een RollingUpdate gemaakt met maxUnavailable als 1, maxSurge als 0 en minReadySeconds als 0s. Raadpleeg het volgende voorbeeld.

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

  • De RollingUpdate-strategie is alleen van toepassing op bestaande DaemonSet-pods. Het beperkt niet de impact van het toevoegen van nieuwe knooppunten, waardoor extra DaemonSet-pods worden gemaakt of volledig nieuwe DaemonSets worden geïmplementeerd.

  • Als u wilt voorkomen dat DaemonSets gelijktijdige LIST-aanvragen verzendt naar de API-server tijdens het opstarten na het uitschalen van knooppunten of nieuwe DaemonSet-implementaties, implementeert u opstart-jitter in het invoerpunt van de container en configureert u het juiste exponentieel uitstel en configureert u het beleid voor 5xx- of 429-antwoorden om herhaalde nieuwe pogingen van grote LIJST-aanvragen te voorkomen.

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

Opmerking

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.

etcd-optimalisaties

  • Houd de totale etcd-grootte klein en gebruik etcd niet als een database voor algemeen gebruik. AKS biedt standaard 8 GB etcd-opslag, maar grotere etcd-databases verhogen de fragmentatietijd, wat kan leiden tot prestatieproblemen met lezen en schrijven. Grotere etcd-databases kunnen ook de kans verhogen dat API-server- en etcd-betrouwbaarheidsproblemen optreden als een niet-geoptimaliseerde client vaak grote aantallen objecten ophaalt uit etcd. Als de grootte van uw etcd-database groter is dan 2 GB, kunt u overwegen de onderstaande technieken voor objectgroottevermindering te gebruiken.
  • Als u de grootte van podspecificaties wilt verminderen, verplaatst u omgevingsvariabelen van podspecificaties naar ConfigMaps.
  • Splits grote geheime gegevens of ConfigMaps in kleinere, beter beheerbare onderdelen.
  • Sla geheimen op in Azure Key Vault in plaats van Kubernetes Secrets, indien mogelijk om het aantal geheimen te verminderen dat is opgeslagen in etcd.
  • Ongebruikte objecten opschonen
    • Verouderde Jobs en voltooide Pods verwijderen. Gebruik ttlSecondsAfterFinished bij Jobs, zodat voltooide objecten automatisch worden verwijderd.
    • Zorg ervoor dat controllers ownerReferences instellen. Hierdoor kan kubernetes garbagecollection afhankelijke objecten automatisch verwijderen wanneer de bovenliggende resource wordt verwijderd.
    • Beperk CronJob-geschiedenis door de successfulJobsHistoryLimit en failedJobsHistoryLimit in te stellen om slechts een klein aantal voltooide Job-records te bewaren.
    • Implementatie-uitrolgeschiedenis reduceren. Oude ReplicaSets worden ook opgeslagen als API-objecten. De standaardwaarde is 10.
  • Verminder de Helm-revisiegeschiedenis met het --history-max argument. Houd deze in grote clusters onder de 5.

Metrische gegevens en logboeken van het AKS-controlevlak bewaken

Het bewaken van metrische gegevens van het besturingsvlak in grote AKS-clusters is van cruciaal belang voor de stabiliteit en prestaties van Kubernetes-workloads. Deze metrische gegevens bieden inzicht in de status en het gedrag van kritieke onderdelen, zoals de API-server, enzovoort, controllerbeheer en scheduler. In grootschalige omgevingen, waar resourceconflicten en hoge API-aanroepvolumes vaak voorkomen, helpt het monitoren van controlestructuurniveaumetingen bij het identificeren van knelpunten, het detecteren van afwijkingen en het optimaliseren van het resourcegebruik. Door deze metrische gegevens te analyseren, kunnen operators proactief problemen oplossen, zoals latentie van API-servers, hoge etcd-objecten of overmatig verbruik van beheervlakresources, waardoor een efficiënte clusterbewerking wordt gegarandeerd en downtime wordt geminimaliseerd.

Azure Monitor biedt uitgebreide metrische gegevens en logboeken over de status van het besturingsvlak via Azure Managed Prometheus en Diagnostische instellingen.

Metrische gegevens van het platform voor het besturingsvlak

AKS maakt de volgende metrische platformgegevens beschikbaar in Azure Monitor voor het bewaken van de API-server en enzovoortsstatus. Deze metrische gegevens zijn beschikbaar zonder Beheerde Prometheus in te schakelen en kunnen rechtstreeks worden weergegeven in de Azure-portal onder Metrics voor uw AKS-cluster.

Metrische gegevens van API Server:

Metric Beschrijving
apiserver_cpu_usage_percentage Maximale CPU-percentage (gebaseerd op de huidige limiet) die door de API-server pod wordt gebruikt over instanties heen.
apiserver_memory_usage_percentage Maximaal geheugenpercentage (op basis van de huidige limiet) dat wordt gebruikt door de API-serverpod bij verschillende instanties.
apiserver_current_inflight_requests (voorbeeld) Maximum aantal momenteel actieve verzoeken in verwerking op de API-server, per aanvraagtype.

Etcd-metrische gegevens:

Metric Beschrijving
etcd_cpu_usage_percentage Maximum CPU-gebruik (gebaseerd op de huidige limiet) dat wordt gebruikt door de etcd-pod in verschillende exemplaren.
etcd_memory_usage_percentage Maximumgeheugenpercentage (op basis van huidige limiet) dat wordt gebruikt door de etcd-pod in verschillende exemplaren.
etcd_database_usage_percentage Maximaal gebruik van de etcd-database in meerdere exemplaren. Bewaak dit nauwkeurig om te voorkomen dat de opslaglimiet voor etcd wordt overschreden.

Bewaak apiserver_cpu_usage_percentage consistent en apiserver_memory_usage_percentage detecteer resourcedruk op de API-server. Als etcd_database_usage_percentage consistent hoger is dan 50%, kunt u de sectie Etcd Optimizations raadplegen om de databasegrootte te verkleinen. Zie AKS-referentie voor bewakingsgegevens voor de volledige lijst met beschikbare metrische gegevens.

Functiebeperkingen

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

Azure API en platformbeperking

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. Op Azure vindt 'throttling' plaats op twee niveaus. Azure Resource Manager (ARM) limiteert verzoeken 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 throttling-limieten toe die specifiek zijn afgestemd op zijn operaties. Zie ARM-beperkingsaanvragen voor meer informatie.

Throttling beheren in AKS

Azure API-limieten worden meestal gedefinieerd op een combinatieniveau van een abonnementsregio. Bijvoorbeeld: alle clients binnen een abonnement in een bepaalde regio delen API-limieten voor een bepaalde Azure-API, zoals Virtual Machine Scale Sets PUT-API's. 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 regio, delen alle AKS-clientsystemen en klantensystemen 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 limitatieproblemen worden opgelost. Als u een geüpgradede versie van Kubernetes gebruikt en nog steeds throttling ziet vanwege de feitelijke 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 om fouten te analyseren, de hoofdoorzaak te identificeren en aanbevelingen voor oplossingen op te halen.
  • Splits uw clusters in verschillende abonnementen of regio's: Als u een groot aantal clusters en knooppuntgroepen hebt die gebruikmaken van Virtual Machine Scale Sets, 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.

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.

  • Als u Azure Standard Load Balancer gebruikt, gebruikt u ten minste 2 uitgaande openbare IP-adressen. Overweeg bij het plannen van grote clusters ook de limieten voor de backendregels van de LoadBalancer-service. Azure Standard Load Balancers ondersteunen maximaal 10.000 back-end-IP-configuraties per front-end-IP. Elk type: De LoadBalancer-service maakt één taakverdelingsregel per weergegeven poort en koppelt alle clusterknooppunten aan de back-endpool van de load balancer. Als u bijvoorbeeld vijf poorten beschikbaar stelt voor één service, wordt deze limiet bereikt op 2000 knooppunten.

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

  • Gebruik Azure CNI Overlay om maximaal 200.000 pods en 5000 knooppunten per cluster te schalen. Zie Configure Azure CNI Overlay networking 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 Network Policy Manager (NPM) ondersteunt alleen maximaal 250 knooppunten. Als u netwerkbeleid wilt afdwingen voor grotere clusters, kunt u overwegen om Azure CNI mogelijk te maken met Cilium, waarmee het robuuste besturingsvlak van Azure CNI wordt gecombineerd met het Cilium-gegevensvlak om netwerken en beveiliging met hoge prestaties te bieden.

  • Schakel LocalDNS in op uw knooppuntgroepen om de latentie van DNS-resolutie te verminderen en gecentraliseerde CoreDNS-pods te offloaden. In grote clusters met hoge DNS-queryvolumes kan gecentraliseerde DNS-omzetting een knelpunt worden. LocalDNS implementeert een DNS-proxy als een systemd service op elk knooppunt, lost query's lokaal op, elimineert conntrack tabeldruk en upgradet verbindingen naar TCP om racevoorwaarden te voorkomen conntrack . LocalDNS biedt ook ondersteuning voor het aanbieden van verouderde cache-reacties wanneer upstream-DNS niet beschikbaar is, waardoor de tolerantie van de workload tijdens tijdelijke storingen wordt verbeterd. Zie DNS-resolutie in AKS voor meer informatie.

Overwegingen en aanbevolen procedures voor clusterupgrades

  • Wanneer een cluster de limiet van 5000 knooppunten bereikt, worden clusterupgrades geblokkeerd. Deze limiet voorkomt een upgrade omdat er geen knooppuntcapaciteit beschikbaar is voor het uitvoeren van rolling updates binnen de maximale piekeigenschappenlimiet. 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 surge-instellingen verhoogt, wordt het upgradeproces sneller afgerond, maar kunnen er onderbrekingen optreden tijdens het upgradeproces. Voor meer informatie, zie Nodepiekupgrade aanpassen.
  • Zie Een AKS-cluster upgraden voor meer informatie over clusterupgrades.
  • Last updated on