Bewerken

Delen via

Beheer van Kubernetes-knooppunten en -knooppuntgroepen

Azure Kubernetes Service (AKS)
Azure Virtual Machines

Kubernetes-architectuur is gebaseerd op twee lagen: het besturingsvlak en een of meer knooppunten in knooppuntgroepen. In dit artikel wordt beschreven en vergeleken hoe Amazon Elastic Kubernetes Service (Amazon EKS) en Azure Kubernetes Service (AKS) agent- of werkknooppunten beheren.

Notitie

Dit artikel maakt deel uit van een reeks artikelen die professionals helpen die bekend zijn met Amazon EKS om inzicht te krijgen in Azure Kubernetes Service (AKS).

In zowel Amazon EKS als AKS biedt en beheert het cloudplatform de laag van het besturingsvlak en beheert de klant de knooppuntlaag. In het volgende diagram ziet u de relatie tussen het besturingsvlak en de knooppunten in de AKS Kubernetes-architectuur.

Diagram met het besturingsvlak en de knooppunten in de AKS-architectuur.

Door Amazon EKS beheerde knooppuntgroepen

Door Amazon EKS beheerde knooppuntgroepen automatiseren het inrichten en levenscyclusbeheer van EC2-werkknooppunten (Amazon Elastic Compute Cloud) voor Amazon EKS-clusters. Gebruikers van Amazon Web Services (AWS) kunnen het opdrachtregelprogramma eksctl gebruiken om knooppunten voor hun EKS-clusters te maken, bij te werken of te beëindigen. Updates en beëindiging van knooppunten worden automatisch cordon- en drain-knooppunten om ervoor te zorgen dat toepassingen beschikbaar blijven.

Elk beheerd knooppunt wordt ingericht als onderdeel van een Amazon EC2 Auto Scaling-groep die Amazon EKS beheert en beheert. De automatische schaalaanpassing van Kubernetes-clusters past automatisch het aantal werkknooppunten in een cluster aan wanneer pods mislukken of opnieuw worden gepland op andere knooppunten. Elke knooppuntgroep kan worden geconfigureerd voor uitvoering op meerdere Beschikbaarheidszones binnen een regio.

Zie Een beheerde knooppuntgroep maken en een beheerde knooppuntgroep bijwerken voor meer informatie over door Amazon EKS beheerde knooppunten.

U kunt ook Kubernetes-pods uitvoeren op AWS Fargate. Fargate biedt on-demand rekencapaciteit op aanvraag voor containers. Zie AWS Fargate voor meer informatie over het gebruik van Fargate met Amazon EKS.

Karpenter

Karpenter- is een opensource-project dat is ontworpen om het levenscyclusbeheer van knooppunten binnen Kubernetes-clusters te verbeteren. Het automatiseert het inrichten en ongedaan maken van de inrichting van knooppunten op basis van de specifieke planningsbehoeften van pods, waardoor efficiënt schalen en kostenoptimalisatie mogelijk is. De belangrijkste functies zijn:

  • Bewaak pods die de Kubernetes-planner niet kan plannen vanwege resourcebeperkingen.
  • Evalueer de planningsvereisten (resourceaanvragen, knooppuntkiezers, affiniteiten, toleranties, enzovoort) van de niet-geplande pods.
  • Richt nieuwe knooppunten in die voldoen aan de vereisten van deze pods.
  • Verwijder knooppunten wanneer ze niet meer nodig zijn.

Met Karpenter definieert u NodePools met beperkingen voor het inrichten van knooppunten, zoals taints, labels, vereisten (instantietypen, zones, enzovoort) en limieten voor het totale aantal ingerichte resources. Bij het implementeren van workloads geeft u verschillende planningsbeperkingen op in de podspecificaties, zoals resourceaanvragen/limieten, knooppuntkiezers, affiniteiten met knooppunten, toleranties en topologiespreidingsbeperkingen. Karpenter richt vervolgens de juiste grootte van knooppunten in op basis van deze specificaties.

Vóór de lancering van Karpenter waren Amazon EKS-gebruikers voornamelijk afhankelijk van Amazon EC2 Auto Scaling-groepen en de Kubernetes Cluster Autoscaler (CAS) om de rekencapaciteit van hun clusters dynamisch aan te passen. U hoeft niet tientallen knooppuntgroepen te maken om de flexibiliteit en diversiteit te bereiken die u krijgt met Karpenter. In tegenstelling tot de automatische schaalaanpassing van Kubernetes-clusters is Karpenter niet zo nauw gekoppeld aan Kubernetes-versies en hoeft u niet tussen AWS- en Kubernetes-API's te springen.

Karpenter consolideert instantieindelingsverantwoordelijkheden binnen één systeem, wat eenvoudiger, stabieler en clusterbewuster is. Karpenter is ontworpen om een aantal van de uitdagingen van cluster automatisch schalen te overwinnen door vereenvoudigde manieren te bieden om:

  • Knooppunten inrichten op basis van workloadvereisten.
  • Maak diverse knooppuntconfiguraties op exemplaartype, met behulp van flexibele Opties voor NodePool. In plaats van veel specifieke aangepaste knooppuntgroepen te beheren, kunt u met Karpenter diverse workloadcapaciteit beheren met één flexibele NodePool.
  • Maak een verbeterde podplanning op schaal door snel knooppunten te starten en pods te plannen.

Ga naar de karpenter.sh site voor informatie en documentatie over het gebruik van Karpenter.

Karpenter brengt schaalbeheer dichter bij systeemeigen Kubernetes-API's dan groepen voor automatisch schalen (ASG's) en beheerde knooppuntgroepen (MNG's). ASG's en MNG's zijn AWS-systeemeigen abstracties waarbij schalen wordt geactiveerd op basis van metrische gegevens op AWS-niveau, zoals EC2 CPU-belasting. Automatische schaalaanpassing van clusters de Kubernetes-abstracties overbrugt in AWS-abstracties, maar hierdoor verliest u enige flexibiliteit, zoals het plannen van een specifieke beschikbaarheidszone.

Karpenter verwijdert een laag AWS-abstractie om een deel van de flexibiliteit rechtstreeks in Kubernetes te brengen. Karpenter wordt het beste gebruikt voor clusters met workloads die perioden van hoge, stekelige vraag ondervinden of diverse rekenvereisten hebben. MNG's en ASG's zijn geschikt voor clusters met workloads die vaak statischer en consistenter zijn. U kunt een combinatie van dynamisch en statisch beheerde knooppunten gebruiken, afhankelijk van uw vereisten.

Kata-containers

Kata Containers is een opensource-project dat een beveiligde containerruntime biedt die de lichtgewicht aard van containers combineert met de beveiligingsvoordelen van virtuele machines. Het voorziet in de noodzaak van sterkere isolatie van werkbelastingen en beveiliging door elke container met een ander gastbesturingssysteem op te starten, in tegenstelling tot traditionele containers die dezelfde Linux-kernel delen tussen workloads. Kata-containers voeren containers uit op een virtuele machine die compatibel is met OCI en bieden strikte isolatie tussen containers op dezelfde hostmachine. Kata Containers de volgende functies bieden:

  • Verbeterde isolatie van werkbelastingen: elke container wordt uitgevoerd in een eigen lichtgewicht VM, waardoor isolatie op hardwareniveau wordt gegarandeerd.
  • Verbeterde beveiliging: het gebruik van VM-technologie biedt een extra beveiligingslaag, waardoor het risico op containeronderbrekingen wordt verminderd.
  • Compatibiliteit met industriestandaarden: Kata Containers kunnen worden geïntegreerd met industriestandaardhulpprogramma's zoals de OCI-containerindeling en de Kubernetes CRI-interface.
  • Ondersteuning voor meerdere architecturen en hypervisors: Kata Containers ondersteunt AMD64- en ARM-architecturen en kan worden gebruikt met hypervisors zoals Cloud-Hypervisor en Firecracker.
  • Eenvoudige implementatie en beheer: Kata Containers abstraheren de complexiteit van het organiseren van workloads door gebruik te maken van het Kubernetes-indelingssysteem.

AWS-klanten kunnen Kata Containers op AWS instellen en uitvoeren door een Amazon Elastic Kubernetes Service (EKS)-cluster te configureren voor het gebruik van Firecracker-, een opensource-virtualisatietechnologie die is ontwikkeld door Amazon voor het maken en beheren van veilige, multitenantcontainer- en functieservices. Met Firecracker kunnen klanten workloads implementeren in lichtgewicht virtuele machines, microVM's genoemd, die een verbeterde isolatie van beveiliging en workload bieden ten opzichte van traditionele virtuele machines, terwijl de snelheid en resource-efficiëntie van containers worden ingeschakeld. Het inschakelen van Kata Containers op AWS EKS vereist een reeks handmatige stappen die worden beschreven in Isolatie en beveiliging van Kubernetes-werkbelasting verbeteren met kata-containers.

Toegewezen hosts

Wanneer u Amazon Elastic Kubernetes Service (EKS) gebruikt om containers te implementeren en uit te voeren, is het mogelijk om ze uit te voeren op toegewezen Amazon EC2-hosts. Het is echter belangrijk om te weten dat deze functie alleen beschikbaar is voor zelfbeheerde knooppuntgroepen. Dit betekent dat klanten handmatig een -startsjabloon moeten maken, groepen voor automatisch schalenen ze moeten registreren bij het EKS-cluster. Het aanmaakproces voor deze resources is hetzelfde als voor het automatisch schalen van EC2.

Raadpleeg de volgende documentatie voor gedetailleerde informatie over het uitvoeren van containers op toegewezen EC2-hosts met AWS EKS:

AKS-knooppunten en -knooppuntgroepen

Als u een AKS-cluster maakt en configureert, wordt automatisch een besturingsvlak gemaakt en geconfigureerd. Dit biedt de belangrijkste Kubernetes-services en indeling van toepassingsworkloads. Het Azure-platform biedt het AKS-besturingsvlak zonder kosten als een beheerde Azure-resource. Het besturingsvlak en de bijbehorende resources bestaan alleen in de regio waar u het cluster hebt gemaakt.

De knooppunten, ook wel agentknooppunten of werkknooppunten genoemd, hosten de workloads en toepassingen. Klanten in AKS beheren en betalen volledig voor de agentknooppunten die zijn gekoppeld aan het AKS-cluster.

Voor het uitvoeren van toepassingen en ondersteunende services heeft een AKS-cluster ten minste één knooppunt nodig: een virtuele Azure-machine (VM) om de Kubernetes-knooppuntonderdelen en containerruntime uit te voeren. Elk AKS-cluster moet ten minste één systeemknooppuntgroep met ten minste één knooppunt bevatten.

AKS groept knooppunten van dezelfde configuratie in knooppuntgroepen van VM's waarop AKS-workloads worden uitgevoerd. Systeemknooppuntgroepen dienen het primaire doel van het hosten van kritieke systeempods, zoals CoreDNS. Gebruikersknooppuntgroepen dienen het primaire doel van het hosten van workloadpods. Als u slechts één knooppuntgroep in uw AKS-cluster wilt hebben, bijvoorbeeld in een ontwikkelomgeving, kunt u toepassingspods in de systeemknooppuntgroep plannen.

Diagram met één Kubernetes-knooppunt.

U kunt ook meerdere gebruikersknooppuntgroepen maken om verschillende workloads op verschillende knooppunten te scheiden om het probleem met lawaaierige buren te voorkomen of om toepassingen met verschillende reken- of opslagvereisten te ondersteunen.

Elk agentknooppunt van een systeem- of gebruikersknooppuntgroep is een VM die is ingericht als onderdeel van Azure Virtual Machine Scale Sets en wordt beheerd door het AKS-cluster. Zie Knooppunten en knooppuntgroepen voor meer informatie.

U kunt het eerste aantal en de grootte voor werkknooppunten definiëren wanneer u een AKS-cluster maakt of wanneer u nieuwe knooppunten en knooppuntgroepen toevoegt aan een bestaand AKS-cluster. Als u geen VM-grootte opgeeft, wordt de standaardgrootte Standard_D2s_v3 voor Windows-knooppuntgroepen en Standard_DS2_v2 voor Linux-knooppuntgroepen.

Belangrijk

Als u een betere latentie wilt bieden voor aanroepen binnen knooppunten en communicatie met platformservices, selecteert u een VM-serie die ondersteuning biedt voor versneld netwerken.

Knooppuntgroep maken

U kunt een knooppuntgroep toevoegen aan een nieuw of bestaand AKS-cluster met behulp van Azure Portal, Azure CLI, de AKS REST API of hulpprogramma's voor infrastructuur als code (IaC), zoals Bicep, Azure Resource Manager-sjablonen of Terraform. Zie Meerdere knooppuntgroepen maken en beheren voor een cluster in Azure Kubernetes Service (AKS) voor meer informatie over het toevoegen van knooppuntgroepen aan een bestaand AKS-cluster.

Wanneer u een nieuwe knooppuntgroep maakt, wordt de gekoppelde virtuele-machineschaalset gemaakt in de knooppuntresourcegroep, een Azure-resourcegroep die alle infrastructuurresources voor het AKS-cluster bevat. Deze resources omvatten de Kubernetes-knooppunten, virtuele netwerkresources, beheerde identiteiten en opslag.

De knooppuntresourcegroep heeft standaard een naam zoals MC_<resourcegroupname>_<clustername>_<location>. AKS verwijdert automatisch de knooppuntresourcegroep bij het verwijderen van een cluster. Gebruik deze resourcegroep dus alleen voor resources die de levenscyclus van het cluster delen.

Een knooppuntgroep toevoegen

In het volgende codevoorbeeld wordt de azure CLI az aks nodepool add command gebruikt om een knooppuntgroep met de naam mynodepool drie knooppunten toe te voegen aan een bestaand AKS-cluster dat in de myAKSCluster resourcegroep wordt aangeroepenmyResourceGroup.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Spot-knooppuntgroepen

Een spot-knooppuntgroep is een knooppuntgroep die wordt ondersteund door een virtuele-machineschaalset ter plaatse. Als u spot-VM's gebruikt voor knooppunten met uw AKS-cluster, profiteert u van niet-gebruikte Azure-capaciteit tegen aanzienlijke kostenbesparingen. De hoeveelheid beschikbare niet-gebruikte capaciteit varieert op basis van veel factoren, waaronder de grootte van het knooppunt, de regio en het tijdstip van de dag.

Bij het implementeren van een spot-knooppuntgroep wijst Azure de spot-knooppunten toe als er capaciteit beschikbaar is. Er is echter geen SLA (Service Level Agreement) voor de spot-knooppunten. Een spot-schaalset die de spot-knooppuntgroep terugstuurt, wordt geïmplementeerd in één foutdomein en biedt geen garanties voor hoge beschikbaarheid. Wanneer Azure de capaciteit terug nodig heeft, verwijdert de Azure-infrastructuur spot-knooppunten en krijgt u maximaal een kennisgeving van 30 seconden voordat u deze verwijdert. Houd er rekening mee dat een spot-knooppuntgroep niet de standaardknooppuntgroep van het cluster kan zijn. Een spot-knooppuntgroep kan alleen worden gebruikt voor een secundaire pool.

Spot-knooppunten zijn bedoeld voor workloads die onderbrekingen, vroegtijdige beëindigingen of verwijderingen kunnen afhandelen. Batchverwerkingstaken, ontwikkel- en testomgevingen en grote rekenworkloads zijn bijvoorbeeld goede kandidaten voor het plannen van een spot-knooppuntgroep. Zie de beperkingen van het spot-exemplaar voor meer informatie.

Met de volgende az aks nodepool add opdracht wordt een spot-knooppuntgroep toegevoegd aan een bestaand cluster waarvoor automatisch schalen is ingeschakeld.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Zie Een spot-knooppuntgroep toevoegen aan een AKS-cluster (Azure Kubernetes Service) voor meer informatie over spot-knooppuntgroepen.

Kortstondige besturingssysteemschijven

Standaard repliceert Azure de besturingssysteemschijf (OS) van het VM-besturingssysteem automatisch naar Azure Storage om gegevensverlies te voorkomen als de VIRTUELE machine naar een andere host moet worden verplaatst. Maar omdat containers niet zijn ontworpen om de lokale status te behouden, biedt het behouden van de besturingssysteemschijf in de opslag een beperkte waarde voor AKS. Er zijn enkele nadelen, zoals tragere inrichting van knooppunten en een hogere latentie voor lezen/schrijven.

Tijdelijke besturingssysteemschijven worden daarentegen alleen opgeslagen op de hostcomputer, zoals een tijdelijke schijf, en bieden lagere lees-/schrijflatentie en snellere schaalaanpassing van knooppunten en clusterupgrades. Net als een tijdelijke schijf is een tijdelijke besturingssysteemschijf inbegrepen in de prijs van de VIRTUELE machine, zodat er geen extra opslagkosten in rekening worden gebracht.

Belangrijk

Als u niet expliciet beheerde schijven voor het besturingssysteem aanvraagt, wordt AKS standaard ingesteld op een kortstondig besturingssysteem, indien mogelijk voor een configuratie van een bepaalde knooppuntgroep.

Als u kortstondig besturingssysteem wilt gebruiken, moet de besturingssysteemschijf in de VM-cache passen. Azure VM-documentatie toont de grootte van de VM-cache tussen haakjes naast IO-doorvoer als cachegrootte in gibibytes (GiB).a0>

De standaard AKS-Standard_DS2_v2 VM-grootte met de standaardschijfgrootte van 100 GB ondersteunt tijdelijke besturingssysteemgrootte, maar heeft slechts 86 GB cachegrootte. Deze configuratie wordt standaard ingesteld op beheerde schijf als u anders niet expliciet opgeeft. Als u een kortstondig besturingssysteem voor deze grootte aanvraagt, krijgt u een validatiefout.

Als u dezelfde Standard_DS2_v2 VM aanvraagt met een besturingssysteemschijf van 60 GB, krijgt u standaard een kortstondig besturingssysteem. De aangevraagde grootte van het besturingssysteem van 60 GB is kleiner dan de maximale cachegrootte van 86 GB.

Standard_D8s_v3 met een besturingssysteemschijf van 100 GB ondersteunt kortstondige besturingssystemen en heeft 200 GB cacheruimte. Als een gebruiker het type besturingssysteemschijf niet opgeeft, krijgt een knooppuntgroep standaard een kortstondig besturingssysteem.

De volgende az aks nodepool add opdracht laat zien hoe u een nieuwe knooppuntgroep toevoegt aan een bestaand cluster met een tijdelijke besturingssysteemschijf. De --node-osdisk-type parameter stelt het type Ephemeralbesturingssysteemschijf in op en de --node-osdisk-size parameter definieert de schijfgrootte van het besturingssysteem.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Zie Kortstondige besturingssysteemschijven voor meer informatie over tijdelijke besturingssysteemschijven.

Virtual Machines Node Pools in Azure Kubernetes Service (AKS)

Elke beheerde knooppuntgroep in EKS wordt ondersteund door een Amazon EC2-groep voor automatisch schalen, die wordt beheerd door Amazon EKS. Met deze integratie kan EKS automatisch het inrichten en schalen van EC2-exemplaren binnen de knooppuntgroep afhandelen. Hoewel groepen voor automatisch schalen kunnen worden geconfigureerd ter ondersteuning van meerdere EC2-exemplaartypen, bieden ze niet de mogelijkheid om op te geven hoeveel knooppunten moeten worden gemaakt of geschaald voor elk exemplaartype. In plaats daarvan beheert EKS het schalen van de knooppuntgroep op basis van de gewenste configuratie en beleidsregels die door de gebruiker zijn gedefinieerd. Dit zorgt voor een vereenvoudigd en geautomatiseerd beheerproces voor de knooppuntgroep en biedt flexibiliteit bij het selecteren van de EC2-exemplaartypen die aansluiten bij uw workloadvereisten. AWS-klanten kunnen echter zelfbeheerde Amazon Linux-knooppunten starten met eksctl of de AWS-beheerconsole.

Met Virtual Machines-knooppuntgroepenbeheert Azure Kubernetes Service (AKS) het inrichten en opstarten van elk agentknooppunt. Voor knooppuntgroepen van virtuele-machineschaalsets beheert AKS het model van de virtuele-machineschaalsets en gebruikt deze om consistentie te bereiken tussen alle agentknooppunten in de knooppuntgroep. In plaats daarvan kunt u met Virtual Machines-knooppuntgroepen uw cluster organiseren met virtuele machines die het beste passen bij uw afzonderlijke workloads en opgeven hoeveel knooppunten u wilt maken of schalen voor elke virtuele-machinegrootte.

Een knooppuntgroep bestaat uit een set virtuele machines, met verschillende grootten (SKU's) die zijn aangewezen ter ondersteuning van verschillende typen workloads. Deze grootten van virtuele machines, ook wel SKU's genoemd, worden onderverdeeld in verschillende families die zijn geoptimaliseerd voor specifieke doeleinden. Zie het overzicht van VM-SKU'svoor meer informatie over VM-SKU's.

Als u het schalen van meerdere grootten van virtuele machines wilt inschakelen, gebruikt het knooppuntgroeptype virtuele machines een ScaleProfile die configureert hoe de knooppuntgroep wordt geschaald, met name de gewenste lijst met de grootte en het aantal virtuele machines. Een ManualScaleProfile is een schaalprofiel dat de gewenste grootte en telling van de virtuele machine aangeeft. Er is slechts één grootte van een virtuele machine toegestaan in een ManualScaleProfile. U moet een afzonderlijke ManualScaleProfile maken voor elke grootte van de virtuele machine in uw knooppuntgroep.

Wanneer u een nieuwe knooppuntgroep voor virtuele machines maakt, hebt u ten minste één ManualScaleProfile in de ScaleProfilenodig. Er kunnen meerdere handmatige schaalprofielen worden gemaakt voor één knooppuntgroep voor virtuele machines.

Voordelen van knooppuntgroepen voor virtuele machines zijn onder andere:

  • Flexibiliteit: Knooppuntspecificaties kunnen worden bijgewerkt voor uw workloads en behoeften.
  • nauwkeurig afgestemde besturingselementen: besturingselementen op één knooppuntniveau maken het opgeven en combineren van knooppunten van verschillende specificaties mogelijk om de consistentie te verbeteren.
  • Efficiëntie: u kunt de knooppuntvoetafdruk voor uw cluster verminderen, waardoor uw operationele vereisten worden vereenvoudigd.

Virtual Machines-knooppuntgroepen bieden een betere ervaring voor dynamische workloads en vereisten voor hoge beschikbaarheid. Hiermee kunt u meerdere virtuele machines van dezelfde familie instellen in één knooppuntgroep, waarbij uw workload automatisch wordt gepland op de beschikbare resources die u configureert.

In de volgende tabel worden knooppuntgroepen van virtuele machines vergeleken met standaard schaalset knooppuntgroepen.

Type knooppuntgroep Mogelijkheden
Knooppuntgroep van virtuele machines U kunt knooppunten toevoegen, verwijderen of bijwerken in een knooppuntgroep. Typen virtuele machines kunnen elke virtuele machine van hetzelfde familietype zijn (bijvoorbeeld D-serie, A-serie, enzovoort).
Knooppuntgroep op basis van virtuele-machineschaalset U kunt knooppunten van dezelfde grootte toevoegen of verwijderen en een knooppuntgroep typen. Als u een nieuwe grootte van een virtuele machine aan het cluster toevoegt, moet u een nieuwe knooppuntgroep maken.

Pools voor virtuele-machineknooppunten hebben de volgende beperkingen:

  • automatische schaalaanpassing van clusters wordt niet ondersteund.
  • InfiniBand- is niet beschikbaar.
  • Windows-knooppuntgroepen worden niet ondersteund.
  • Deze functie is niet beschikbaar in Azure Portal. Gebruik Azure CLI of REST API's om CRUD-bewerkingen uit te voeren of de pool te beheren.
  • momentopname van knooppuntgroepen wordt niet ondersteund.
  • Alle VM-grootten die in een knooppuntgroep zijn geselecteerd, moeten afkomstig zijn van dezelfde virtuele-machinefamilie. U kunt bijvoorbeeld geen type virtuele machine uit de N-serie combineren met een type virtuele machine uit de D-serie in dezelfde knooppuntgroep.
  • Met knooppuntgroepen voor virtuele machines kunnen maximaal vijf verschillende grootten van virtuele machines per knooppuntgroep worden gebruikt.

Virtuele knooppunten

U kunt virtuele knooppunten gebruiken om toepassingsworkloads snel uit te schalen in een AKS-cluster. Virtuele knooppunten bieden u snelle inrichting van pods en u betaalt alleen per seconde voor uitvoeringstijd. U hoeft niet te wachten tot de automatische schaalaanpassing van clusters nieuwe werkknooppunten implementeert om meer podreplica's uit te voeren. Virtuele knooppunten worden alleen ondersteund met Linux-pods en -knooppunten. De invoegtoepassing voor virtuele knooppunten voor AKS is gebaseerd op het opensource Virtual Kubelet-project .

De functionaliteit van virtuele knooppunten is afhankelijk van Azure Container Instances. Zie Een AKS-cluster (Azure Kubernetes Services) maken en configureren voor het gebruik van virtuele knooppunten voor meer informatie over virtuele knooppunten.

Taints, labels en tags

Wanneer u een knooppuntgroep maakt, kunt u Kubernetes taints en labels, en Azure-tags, toevoegen aan die knooppuntgroep. Wanneer u een taint, label of tag toevoegt, krijgen alle knooppunten in die knooppuntgroep die taint, label of tag.

Als u een knooppuntgroep wilt maken met een taint, kunt u de az aks nodepool add opdracht gebruiken met de --node-taints parameter. Als u de knooppunten in een knooppuntgroep wilt labelen, kunt u de --labels parameter gebruiken en een lijst met labels opgeven, zoals wordt weergegeven in de volgende code:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Zie Een taint, label of tag opgeven voor een knooppuntgroep voor meer informatie.

Gereserveerde systeemlabels

Amazon EKS voegt geautomatiseerde Kubernetes-labels toe aan alle knooppunten in een beheerde knooppuntgroep, zoals eks.amazonaws.com/capacityType, waarmee het capaciteitstype wordt opgegeven. AKS voegt ook automatisch systeemlabels toe aan agentknooppunten.

De volgende voorvoegsels zijn gereserveerd voor AKS-gebruik en kunnen niet worden gebruikt voor een knooppunt:

  • kubernetes.azure.com/
  • kubernetes.io/

Zie Kubernetes-bekende labels, aantekeningen en taints voor andere gereserveerde voorvoegsels.

De volgende tabel bevat labels die zijn gereserveerd voor AKS-gebruik en kunnen niet worden gebruikt voor een knooppunt. In de tabel geeft de kolom Virtueel knooppuntgebruik aan of het label wordt ondersteund op virtuele knooppunten.

In de kolom Gebruik van virtuele knooppunten:

  • N.v.t . betekent dat de eigenschap niet van toepassing is op virtuele knooppunten, omdat hiervoor de host moet worden gewijzigd.
  • Hetzelfde betekent dat de verwachte waarden hetzelfde zijn voor een virtuele knooppuntgroep als voor een standaardknooppuntgroep.
  • Virtuele machine vervangt SKU-waarden, omdat virtuele-knooppuntpods geen onderliggende VM beschikbaar maken.
  • De versie van het virtuele knooppunt verwijst naar de huidige versie van de virtuele Kubelet-ACI-connectorrelease.
  • De naam van het subnet van het virtuele knooppunt is het subnet dat virtuele knooppuntpods implementeert in Azure Container Instances.
  • Virtueel knooppunt virtueel netwerk is het virtuele netwerk dat het subnet van het virtuele knooppunt bevat.
Etiket Weergegeven als Voorbeeld, opties Gebruik van virtuele knooppunten
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Zelfde
kubernetes.io/arch amd64 runtime.GOARCH N.v.t.
kubernetes.io/os <OS Type> Linux of Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Zelfde
topology.kubernetes.io/zone <Azure zone> 0 Zelfde
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Zelfde
kubernetes.azure.com/mode <mode> User of System User
kubernetes.azure.com/role agent Agent Zelfde
kubernetes.azure.com/scalesetpriority <scale set priority> Spot of Regular N.v.t.
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Zelfde
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N.v.t.
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N.v.t.
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Versie van virtueel knooppunt
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Naam van subnet van virtueel knooppunt
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Virtueel knooppunt virtueel netwerk
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N.v.t.
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N.v.t.
kubernetes.azure.com/accelerator <accelerator> Nvidia N.v.t.
kubernetes.azure.com/fips_enabled <fips enabled> True N.v.t.
kubernetes.azure.com/os-sku <os/sku> Zie Besturingssysteem-SKU maken of bijwerken Linux-SKU

Windows-knooppuntgroepen

AKS biedt ondersteuning voor het maken en gebruiken van Pools voor Windows Server-containerknooppunten via de netwerkinvoegtoepassing azure-containernetwerkinterface (CNI ). Zie Azure CNI-netwerken configureren om de vereiste subnetbereiken en netwerkoverwegingen te plannen.

Met de volgende az aks nodepool add opdracht wordt een knooppuntgroep toegevoegd waarop Windows Server-containers worden uitgevoerd.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

De voorgaande opdracht maakt gebruik van het standaardsubnet in het virtuele AKS-clusternetwerk. Zie Een Windows Server-container maken in AKS voor meer informatie over het bouwen van een AKS-cluster met een Windows-knooppuntgroep.

Overwegingen voor knooppuntgroepen

De volgende overwegingen en beperkingen zijn van toepassing wanneer u knooppuntgroepen en meerdere knooppuntgroepen maakt en beheert:

  • Quota, VM-groottebeperkingen en beschikbaarheid van regio's zijn van toepassing op AKS-knooppuntgroepen.
  • Systeemgroepen moeten ten minste één knooppunt bevatten. U kunt een systeemknooppuntgroep verwijderen als u een andere systeemknooppuntgroep hebt om deze in het AKS-cluster te plaatsen. Gebruikersknooppuntgroepen kunnen nul of meer knooppunten bevatten.
  • U kunt de VM-grootte van een knooppuntgroep niet wijzigen nadat u deze hebt gemaakt.
  • Voor meerdere knooppuntgroepen moet het AKS-cluster gebruikmaken van de Standard SKU-load balancers. Basic SKU-load balancers bieden geen ondersteuning voor meerdere knooppuntgroepen.
  • Alle clusterknooppuntgroepen moeten zich in hetzelfde virtuele netwerk bevinden en alle subnetten die zijn toegewezen aan een knooppuntgroep, moeten zich in hetzelfde virtuele netwerk bevinden.
  • Als u tijdens het maken van clusters meerdere knooppuntgroepen maakt, moeten de Kubernetes-versies voor alle knooppuntgroepen overeenkomen met de versie van het besturingsvlak. U kunt versies bijwerken nadat het cluster is ingericht met behulp van bewerkingen per knooppuntgroep.

Schalen van knooppuntgroep

Wanneer uw toepassingsworkload verandert, moet u mogelijk het aantal knooppunten in een knooppuntgroep wijzigen. U kunt het aantal knooppunten handmatig omhoog of omlaag schalen met behulp van de opdracht az aks nodepool scale . In het volgende voorbeeld wordt het aantal knooppunten in mynodepool vijf geschaald:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Knooppuntgroepen automatisch schalen met behulp van de automatische schaalaanpassing van clusters

AKS biedt ondersteuning voor het automatisch schalen van knooppuntgroepen met de automatische schaalaanpassing van clusters. U schakelt deze functie in voor elke knooppuntgroep en definieert een minimum- en maximumaantal knooppunten.

Met de volgende az aks nodepool add opdracht wordt een nieuwe knooppuntgroep aangeroepen mynodepool aan een bestaand cluster toegevoegd. Met --enable-cluster-autoscaler de parameter kan de automatische schaalaanpassing van clusters in de nieuwe knooppuntgroep worden ingeschakeld. --min-count De parameters geven --max-count het minimum- en maximum aantal knooppunten in de pool op.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Met de volgende az aks nodepool update command wordt het minimum aantal knooppunten bijgewerkt van één tot drie voor de mynewnodepool knooppuntgroep.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

U kunt de automatische schaalaanpassing van clusters uitschakelen az aks nodepool update door de parameter door te --disable-cluster-autoscaler geven.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Als u de automatische schaalaanpassing van clusters op een bestaand cluster opnieuw wilt inschakelen, gebruikt az aks nodepool updateu , geeft u de --enable-cluster-autoscaler--min-counten parameters op--max-count.

Zie Automatisch een cluster schalen om te voldoen aan de toepassingsvereisten op Azure Kubernetes Service (AKS) voor meer informatie over het gebruik van de automatische schaalaanpassing van clusters voor afzonderlijke knooppuntgroepen.

Pod-sandboxing

AKS-klanten kunnen op een volledig beheerde manier eenvoudig Kata Containers instellen en uitvoeren op AKS. Dit wordt mogelijk gemaakt door gebruik te maken van Pod Sandboxing, een functie die een isolatiegrens maakt tussen de containertoepassing en de gedeelde kernel en rekenresources van de containerhost.

AKS bevat een mechanisme met de naam Pod Sandboxing dat een isolatiegrens biedt tussen de containertoepassing en de gedeelde kernel en rekenresources van de containerhost, zoals CPU, geheugen en netwerken. Pod Sandboxing vormt een aanvulling op andere beveiligingsmaatregelen of besturingselementen voor gegevensbescherming om tenantworkloads te helpen gevoelige informatie te beveiligen en te voldoen aan wettelijke, branche- of governancenalevingsvereisten, zoals PCI DSS (Payment Card Industry Data Security Standard), International Organization for Standardization (ISO) 27001 en Health Insurance Portability and Accountability Act (HIPAA).

Door toepassingen te implementeren op afzonderlijke clusters of knooppuntgroepen, kunt u de tenantworkloads van verschillende teams of klanten sterk isoleren. Het gebruik van meerdere clusters en knooppuntgroepen is mogelijk geschikt voor de isolatievereisten van veel organisaties en SaaS-oplossingen, maar er zijn scenario's waarin één cluster met gedeelde VM-knooppuntgroepen efficiënter is. U kunt bijvoorbeeld één cluster gebruiken wanneer u niet-vertrouwde en vertrouwde pods op hetzelfde knooppunt uitvoert of DaemonSets en bevoegde containers op hetzelfde knooppunt uitvoert voor snellere lokale communicatie en functionele groepering. Pod Sandboxing kunt u tenanttoepassingen op dezelfde clusterknooppunten sterk isoleren zonder dat u deze workloads hoeft uit te voeren in afzonderlijke clusters of knooppuntgroepen. Voor andere methoden moet u uw code opnieuw compileren of andere compatibiliteitsproblemen veroorzaken, maar pod-sandboxing in AKS kan elke container ongewijzigd uitvoeren binnen een verbeterde beveiligings-VM-grens.

Pod Sandboxing op AKS is gebaseerd op Kata Containers die worden uitgevoerd op de Azure Linux-containerhost voor AKS stack om hardware afgedwongen isolatie te bieden. Kata Containers op AKS zijn gebouwd op een door beveiliging beveiligde Azure-hypervisor. Het bereikt isolatie per pod via een geneste, lichtgewicht Kata-VM die gebruikmaakt van resources van een bovenliggend VM-knooppunt. In dit model krijgt elke Kata-pod een eigen kernel in een geneste Kata-gast-VM. Gebruik dit model om veel Kata-containers in één gast-VM te plaatsen terwijl u containers in de bovenliggende VM blijft uitvoeren. Dit model biedt een sterke isolatiegrens in een gedeeld AKS-cluster.

Zie voor meer informatie:

Azure Dedicated Host

Azure Dedicated Host is een service die fysieke servers biedt die zijn toegewezen aan één Azure-abonnement en hardware-isolatie op fysieke serverniveau biedt. U kunt deze toegewezen hosts inrichten binnen een regio, beschikbaarheidszone en foutdomein en u kunt VM's rechtstreeks in de ingerichte hosts plaatsen.

Er zijn verschillende voordelen voor het gebruik van Azure Dedicated Host met AKS, waaronder:

  • Hardware-isolatie zorgt ervoor dat er geen andere VM's op de toegewezen hosts worden geplaatst, wat een extra isolatielaag biedt voor tenantworkloads. Toegewezen hosts worden geïmplementeerd in dezelfde datacenters en delen dezelfde netwerk- en onderliggende opslaginfrastructuur als andere niet-geïsoleerde hosts.
  • Azure Dedicated Host biedt controle over onderhoudsgebeurtenissen die het Azure-platform start. U kunt een onderhoudsvenster kiezen om de impact op services te verminderen en de beschikbaarheid en privacy van tenantworkloads te waarborgen.

Azure Dedicated Host kan SaaS-providers helpen ervoor te zorgen dat tenanttoepassingen voldoen aan wettelijke, branche- en governancenalevingsvereisten voor het beveiligen van gevoelige informatie. Zie Azure Dedicated Host toevoegen aan een AKS-clustervoor meer informatie.

Karpenter

Karpenter- is een opensource-project voor levenscyclusbeheer voor knooppunten dat is gebouwd voor Kubernetes. Het toevoegen van Karpenter aan een Kubernetes-cluster kan de efficiëntie en kosten van het uitvoeren van workloads op dat cluster verbeteren. Karpenter kijkt naar pods die door de Kubernetes scheduler als niet-gepland worden gemarkeerd. Ook worden knooppunten die aan de podvereisten kunnen voldoen dynamisch in en beheerd.

Karpenter biedt nauwkeurige controle over het inrichten van knooppunten en de plaatsing van werkbelastingen in een beheerd cluster. Dit besturingselement verbetert multitenancy door resourcetoewijzing te optimaliseren, isolatie tussen de toepassingen van elke tenant te garanderen en operationele kosten te verlagen. Wanneer u een multitenant-oplossing op AKS bouwt, biedt Karpenter nuttige mogelijkheden om u te helpen diverse toepassingsvereisten te beheren om verschillende tenants te ondersteunen. U hebt bijvoorbeeld de toepassingen van sommige tenants nodig om te worden uitgevoerd op gpu geoptimaliseerde knooppuntgroepen en andere om te worden uitgevoerd op knooppuntgroepen die zijn geoptimaliseerd voor geheugen. Als uw toepassing lage latentie voor opslag vereist, kunt u Karpenter gebruiken om aan te geven dat voor een pod een knooppunt is vereist dat wordt uitgevoerd in een specifieke beschikbaarheidszone, zodat u uw opslag- en toepassingslaag kunt koppelen.

Met AKS kunt u knooppunten automatisch inrichten op AKS-clusters via Karpenter. De meeste gebruikers moeten de modus voor automatisch inrichten van knooppunten gebruiken om Karpenter in te schakelen als een beheerde invoegtoepassing. Zie Knooppunt automatisch inrichtenvoor meer informatie. Als u geavanceerdere aanpassingen nodig hebt, kunt u ervoor kiezen om Karpenter zelf te hosten. Zie de AKS Karpenter-providervoor meer informatie.

Vertrouwelijke VM's

Confidential Computing is een beveiligingsmaatregel die is gericht op het beveiligen van gegevens tijdens gebruik via software of hardware-ondersteunde isolatie en versleuteling. Deze technologie voegt een extra beveiligingslaag toe aan traditionele benaderingen, het beschermen van data-at-rest en in transit.

AWS-platform biedt ondersteuning voor confidential computing via Nitro Enclaves, die beschikbaar zijn op EC2-exemplaren en op Amazon Elastic Kubernetes Service (EKS). Zie dit artikel over Amazon-documentatie voor meer informatie. Daarnaast bieden Amazon EC2-exemplaren ondersteuning voor AMD SEV-SNP-. Deze GitHub opslagplaats biedt artefacten voor het bouwen en implementeren van een Amazon Machine Image (AMI) voor EKS met AMD SEV-SNP ondersteuning.

Aan de andere kant biedt Azure klanten vertrouwelijke VM's om te voldoen aan strikte isolatie-, privacy- en beveiligingsvereisten binnen een AKS-cluster. Deze vertrouwelijke VM's maken gebruik van een op hardware gebaseerde vertrouwde uitvoeringsomgeving. Azure Confidential VM's maken specifiek gebruik van AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) technologie, die hypervisor en andere hostbeheercodetoegang tot VM-geheugen en -status weigert. Hiermee voegt u een extra beveiligingslaag en beveiliging toe tegen toegang tot operatoren. Raadpleeg de documentatie over met behulp van vertrouwelijke VM's in een AKS-cluster en het overzicht van vertrouwelijke VM's in Azurevoor meer informatie.

Federal Information Process Standards (FIPS)

FIPS 140-3 is een Amerikaanse overheidsstandaard die minimale beveiligingsvereisten definieert voor cryptografische modules in producten en systemen van informatietechnologie. Door FIPS-naleving in te schakelen voor AKS-knooppuntgroepen, kunt u de isolatie, privacy en beveiliging van uw tenantworkloads verbeteren. FIPS- naleving zorgt ervoor dat gevalideerde cryptografische modules worden gebruikt voor versleuteling, hashing en andere beveiligingsgerelateerde bewerkingen. Met AKS-knooppuntgroepen met FIPS-functionaliteit kunt u voldoen aan wettelijke en branchenalevingsvereisten door robuuste cryptografische algoritmen en mechanismen te gebruiken. Azure biedt documentatie over het inschakelen van FIPS voor AKS-knooppuntgroepen, waarmee u de beveiligingspostuur van uw multitenant AKS-omgevingen kunt versterken. Zie FIPS inschakelen voor AKS-knooppuntgroepenvoor meer informatie.

Versleuteling op basis van host

In EKS heeft uw architectuur mogelijk de volgende functies gebruikt om de gegevensbeveiliging te verbeteren:

op host gebaseerde versleuteling op AKS versterkt de isolatie van tenantworkloads, privacy en beveiliging verder. Wanneer u hostversleuteling inschakelt, versleutelt AKS data-at-rest op de onderliggende hostcomputers, zodat gevoelige tenantgegevens worden beschermd tegen onbevoegde toegang. Tijdelijke schijven en tijdelijke besturingssysteemschijven worden in rust versleuteld met door het platform beheerde sleutels wanneer u end-to-end-versleuteling inschakelt.

In AKS gebruiken besturingssysteem- en gegevensschijven versleuteling aan de serverzijde standaard met door platform beheerde sleutels. De caches voor deze schijven worden in rust versleuteld met door het platform beheerde sleutels. U kunt uw eigen sleutelversleutelingssleutel opgeven om de sleutel voor gegevensbeveiliging te versleutelen met behulp van envelopversleuteling, ook wel bekend als wrapping-. De cache voor het besturingssysteem en de gegevensschijven worden ook versleuteld via de BYOK- die u opgeeft.

Met versleuteling op basis van een host wordt een beveiligingslaag toegevoegd voor omgevingen met meerdere tenants. De gegevens van elke tenant in het besturingssysteem en de gegevensschijfcaches worden in rust versleuteld met door de klant beheerde of platformbeheerde sleutels, afhankelijk van het geselecteerde schijfversleutelingstype. Zie voor meer informatie:

Updates en upgrades

Azure werkt regelmatig het vm-hostingplatform bij om de betrouwbaarheid, prestaties en beveiliging te verbeteren. Deze updates variëren van het patchen van softwareonderdelen in de hostingomgeving tot het upgraden van netwerkonderdelen of het buiten gebruik stellen van hardware. Zie Onderhoud voor virtuele machines in Azure voor meer informatie over hoe virtuele machines in Azure worden bijgewerkt.

Updates van vm-hostinginfrastructuur hebben meestal geen invloed op gehoste VM's, zoals agentknooppunten van bestaande AKS-clusters. Voor updates die van invloed zijn op gehoste VM's, minimaliseert Azure de gevallen waarvoor opnieuw opstarten is vereist door de VM te onderbreken tijdens het bijwerken van de host of door de VIRTUELE machine live te migreren naar een al bijgewerkte host.

Als een update opnieuw moet worden opgestart, biedt Azure een melding en een tijdvenster, zodat u de update kunt starten wanneer deze voor u werkt. Het zelfonderhoudsvenster voor hostmachines is doorgaans 35 dagen, tenzij de update dringend is.

U kunt gepland onderhoud gebruiken om VM's bij te werken en meldingen voor gepland onderhoud te beheren met Azure CLI, PowerShell of Azure Portal. Gepland onderhoud detecteert of u automatische upgrade van clusters gebruikt en plant automatisch upgrades tijdens het onderhoudsvenster. Zie de opdracht az aks maintenanceconfiguration en Use Planned Maintenance om onderhoudsvensters te plannen voor uw AKS-cluster (Azure Kubernetes Service) voor meer informatie over gepland onderhoud.

Kubernetes-upgrades

Een deel van de levenscyclus van het AKS-cluster wordt periodiek bijgewerkt naar de nieuwste Kubernetes-versie. Het is belangrijk om upgrades toe te passen om de nieuwste beveiligingsreleases en -functies te verkrijgen. Als u de Kubernetes-versie van bestaande knooppuntgroep-VM's wilt upgraden, moet u knooppunten snoeren en leegmaken en vervangen door nieuwe knooppunten die zijn gebaseerd op een bijgewerkte Kubernetes-schijfinstallatiekopie.

Standaard configureert AKS upgrades om te pieken met één extra knooppunt. Een standaardwaarde van een voor de max-surge instellingen minimaliseert werkbelastingonderbreking door een extra knooppunt te maken om oudere knooppunten te vervangen voordat bestaande toepassingen worden cordoneren of leegmaken. U kunt de max-surge waarde per knooppuntgroep aanpassen om een compromis tussen upgradesnelheid en onderbreking van de upgrade mogelijk te maken. Het verhogen van de max-surge waarde voltooit het upgradeproces sneller, maar een grote waarde voor max-surge kan onderbrekingen veroorzaken tijdens het upgradeproces.

Een waarde van 100% biedt bijvoorbeeld max-surge het snelst mogelijke upgradeproces door het aantal knooppunten te verdubbelen, maar zorgt er ook voor dat alle knooppunten in de knooppuntgroep tegelijkertijd worden verwijderd. Mogelijk wilt u deze hoge waarde gebruiken voor het testen, maar voor productieknooppuntgroepen is een max-surge instelling van 33% beter.

AKS accepteert zowel gehele getallen als percentagewaarden voor max-surge. Een geheel getal, zoals 5 vijf extra knooppunten om te pieken. Percentagewaarden voor max-surge kunnen minimaal 1% en maximaal 100%worden afgerond op het dichtstbijzijnde aantal knooppunten. Een waarde van 50% geeft een piekwaarde aan van de helft van het huidige aantal knooppunten in de pool.

Tijdens een upgrade kan de max-surge waarde minimaal 1 zijn en een maximumwaarde gelijk zijn aan het aantal knooppunten in de knooppuntgroep. U kunt grotere waarden instellen, maar het maximum aantal knooppunten dat wordt gebruikt max-surge , is niet hoger dan het aantal knooppunten in de pool.

Belangrijk

Voor upgradebewerkingen hebben knooppuntpieken voldoende abonnementsquotum nodig voor het aangevraagde max-surge aantal. Een cluster met bijvoorbeeld vijf knooppuntgroepen, elk met vier knooppunten, heeft in totaal 20 knooppunten. Als elke knooppuntgroep een max-surge waarde van 50% heeft, hebt u extra reken- en IP-quotum nodig van 10 knooppunten, of twee knooppunten keer vijf pools, om de upgrade te voltooien.

Als u Azure Container Networking Interface (CNI) gebruikt, moet u er ook voor zorgen dat u voldoende IP-adressen in het subnet hebt om te voldoen aan de CNI-vereisten voor AKS.

Knooppuntgroepen upgraden

Gebruik az aks get-upgrades om beschikbare upgrades te bekijken.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Als u de status van knooppuntgroepen wilt zien, gebruikt u az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

De volgende opdracht maakt gebruik van az aks nodepool upgrade to upgrade a single node pool.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Zie voor meer informatie over het upgraden van de Kubernetes-versie voor een clusterbesturingsvlak en knooppuntgroepen:

Overwegingen bij upgrades

Let op deze aanbevolen procedures en overwegingen voor het upgraden van de Kubernetes-versie in een AKS-cluster.

  • U kunt het beste alle knooppuntgroepen in een AKS-cluster upgraden naar dezelfde Kubernetes-versie. Het standaardgedrag van het upgraden van az aks upgrade alle knooppuntgroepen en het besturingsvlak.

  • Voer handmatig een upgrade uit of stel een kanaal voor automatische upgrade in op uw cluster. Als u Gepland onderhoud gebruikt om VM's te patchen, worden automatische upgrades ook gestart tijdens het opgegeven onderhoudsvenster. Zie Een Azure Kubernetes Service-cluster (AKS) upgraden voor meer informatie.

  • Met az aks upgrade de opdracht met de --control-plane-only vlag wordt alleen het clusterbesturingsvlak bijgewerkt en worden de gekoppelde knooppuntgroepen in het cluster niet gewijzigd. Als u afzonderlijke knooppuntgroepen wilt upgraden, geeft u de doelknooppuntgroep en kubernetes-versie op in de az aks nodepool upgrade opdracht.

  • Een AKS-clusterupgrade activeert het afbakenen en legen van uw knooppunten. Als er een laag rekenquotum beschikbaar is, kan de upgrade mislukken. Zie Regionale vCPU-quota verhogen voor meer informatie over het verhogen van uw quotum.

  • Configureer de max-surge parameter op basis van uw behoeften met behulp van een geheel getal of een percentagewaarde. Gebruik voor productieknooppuntgroepen een max-surge instelling van 33%. Zie Piekupgrade van knooppunten aanpassen voor meer informatie.

  • Wanneer u een upgrade uitvoert van een AKS-cluster dat gebruikmaakt van CNI-netwerken, moet u ervoor zorgen dat het subnet voldoende privé-IP-adressen heeft voor de extra knooppunten die de max-surge instellingen maken. Zie Azure CNI-netwerken configureren in Azure Kubernetes Service (AKS) voor meer informatie.

  • Als uw clusterknooppuntgroepen meerdere Beschikbaarheidszones binnen een regio omvatten, kan het upgradeproces tijdelijk een niet-verdeelde zoneconfiguratie veroorzaken. Zie Speciale overwegingen voor knooppuntgroepen die meerdere Beschikbaarheidszones omvatten voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen