Redigera

Dela via

Hantering av Kubernetes-noder och nodpooler

Azure Kubernetes Service (AKS)
Azure Virtual Machines

Kubernetes-arkitekturen baseras på två lager: kontrollplanet och en eller flera noder i nodpooler. Den här artikeln beskriver och jämför hur Amazon Elastic Kubernetes Service (Amazon EKS) och Azure Kubernetes Service (AKS) hanterar agent- eller arbetsnoder.

Kommentar

Den här artikeln är en del av en serie artiklar som hjälper proffs som är bekanta med Amazon EKS att förstå Azure Kubernetes Service (AKS).

I både Amazon EKS och AKS tillhandahåller och hanterar molnplattformen kontrollplansskiktet, och kunden hanterar nodskiktet. Följande diagram visar relationen mellan kontrollplanet och noderna i AKS Kubernetes-arkitekturen.

Diagram som visar kontrollplanet och noderna i AKS-arkitekturen.

Amazon EKS-hanterade nodgrupper

Amazon EKS-hanterade nodgrupper automatiserar etablerings- och livscykelhanteringen för Amazon Elastic Compute Cloud-arbetsnoder (EC2) för Amazon EKS-kluster. AWS-användare (Amazon Web Services) kan använda kommandoradsverktyget eksctl för att skapa, uppdatera eller avsluta noder för sina EKS-kluster. Noduppdateringar och avslutningar avspärrar automatiskt och tömmer noder för att säkerställa att program förblir tillgängliga.

Varje hanterad nod etableras som en del av en Amazon EC2-grupp för automatisk skalning som Amazon EKS använder och kontrollerar. Autoskalning av Kubernetes-kluster justerar automatiskt antalet arbetsnoder i ett kluster när poddar misslyckas eller schemaläggs om till andra noder. Varje nodgrupp kan konfigureras för att köras över flera Tillgänglighetszoner inom en region.

Mer information om Amazon EKS-hanterade noder finns i Skapa en hanterad nodgrupp och Uppdatera en hanterad nodgrupp.

Du kan också köra Kubernetes-poddar på AWS Fargate. Fargate tillhandahåller beräkningskapacitet på begäran och rätt storlek för containrar. Mer information om hur du använder Fargate med Amazon EKS finns i AWS Fargate.

Karpenter

Karpenter är ett projekt med öppen källkod som är utformat för att förbättra nodlivscykelhanteringen i Kubernetes-kluster. Den automatiserar etablering och avetablering av noder baserat på poddarnas specifika schemaläggningsbehov, vilket möjliggör effektiv skalning och kostnadsoptimering. Dess huvudfunktioner är:

  • Övervaka poddar som Kubernetes-schemaläggaren inte kan schemalägga på grund av resursbegränsningar.
  • Utvärdera schemaläggningskraven (resursbegäranden, nodväljare, tillhörighet, toleranser osv.) för de oplanerade poddarna.
  • Etablera nya noder som uppfyller kraven för dessa poddar.
  • Ta bort noder när de inte längre behövs.

Med Karpenter definierar du NodePools med begränsningar för nodetablering som taints, etiketter, krav (instanstyper, zoner osv.) och begränsningar för totalt antal etablerade resurser. När du distribuerar arbetsbelastningar anger du olika schemaläggningsbegränsningar i poddspecifikationerna, till exempel resursbegäranden/-gränser, nodväljare, nod-/poddtillhörigheter, toleranser och topologispridningsbegränsningar. Karpenter etablerar sedan noder i rätt storlek baserat på dessa specifikationer.

Före lanseringen av Karpenter förlitade sig Amazon EKS-användare främst på Amazon EC2 Auto Scaling-grupper och Kubernetes Cluster Autoscaler (CAS) för att dynamiskt justera beräkningskapaciteten för sina kluster. Du behöver inte skapa dussintals nodgrupper för att uppnå den flexibilitet och mångfald du får med Karpenter. Till skillnad från Kubernetes Cluster Autoscaler är Karpenter inte lika nära kopplat till Kubernetes-versioner och kräver inte att du hoppar mellan AWS- och Kubernetes-API:er.

Karpenter konsoliderar ansvarsområden för instansorkestrering i ett enda system, vilket är enklare, stabilare och klustermedveten. Karpenter har utformats för att övervinna några av de utmaningar som cluster autoscaler innebär genom att tillhandahålla förenklade sätt att:

  • Etablera noder baserat på arbetsbelastningskrav.
  • Skapa olika nodkonfigurationer efter instanstyp med flexibla NodePool-alternativ. I stället för att hantera många specifika anpassade nodgrupper kan Du med Karpenter hantera olika arbetsbelastningskapaciteter med en enda, flexibel NodePool.
  • Uppnå förbättrad poddschemaläggning i stor skala genom att snabbt starta noder och schemalägga poddar.

Information och dokumentation om hur du använder Karpenter finns på karpenter.sh webbplats.

Karpenter för skalningshantering närmare Kubernetes interna API:er än automatiska skalningsgrupper (ASG) och hanterade nodgrupper (MNG). ASG:er och MNG:er är AWS-interna abstraktioner där skalning utlöses baserat på mått på AWS-nivå, till exempel EC2 CPU-belastning. Cluster Autoscaler överbryggar Kubernetes-abstraktionerna till AWS-abstraktioner, men förlorar viss flexibilitet på grund av detta, till exempel schemaläggning för en specifik tillgänglighetszon.

Karpenter tar bort ett lager av AWS-abstraktion för att få en del av flexibiliteten direkt till Kubernetes. Karpenter används bäst för kluster med arbetsbelastningar som stöter på perioder med hög, hög efterfrågan eller har olika beräkningskrav. MNG:er och ASG:er är bra för kluster som kör arbetsbelastningar som tenderar att vara mer statiska och konsekventa. Du kan använda en blandning av dynamiskt och statiskt hanterade noder, beroende på dina behov.

Kata-containrar

Kata Containers är ett projekt med öppen källkod som ger en säker containerkörning som kombinerar containrarnas lätta natur med säkerhetsfördelarna med virtuella datorer. Det löser behovet av starkare arbetsbelastningsisolering och säkerhet genom att starta varje container med ett annat gästoperativsystem, till skillnad från traditionella containrar som delar samma Linux-kernel mellan arbetsbelastningar. Kata Containers kör containrar på en OCI-kompatibel virtuell dator, vilket ger strikt isolering mellan containrar på samma värddator. Kata Containers tillhandahålla följande funktioner:

  • Förbättrad arbetsbelastningsisolering: Varje container körs på sin egen lätta virtuella dator, vilket säkerställer isolering på maskinvarunivå.
  • Förbättrad säkerhet: Användningen av VM-teknik ger ytterligare ett säkerhetslager, vilket minskar risken för containerutbrott.
  • Kompatibilitet med branschstandarder: Kata Containers integreras med branschstandardverktyg som OCI-containerformatet och Kubernetes CRI-gränssnittet.
  • Stöd för flera arkitekturer och hypervisor-: Kata Containers stöder AMD64- och ARM-arkitekturer och kan användas med hypervisor-program som Cloud-Hypervisor och Firecracker.
  • Enkel distribution och hantering: Kata Containers abstraherar bort komplexiteten i orkestrering av arbetsbelastningar genom att använda Kubernetes-orkestreringssystemet.

AWS-kunder kan konfigurera och köra Kata Containers på AWS genom att konfigurera en Amazon Elastic Kubernetes Service (EKS) kluster för att använda Firecracker, en virtualiseringsteknik med öppen källkod som utvecklats av Amazon för att skapa och hantera säkra container med flera klientorganisationer och funktionsbaserade tjänster. Firecracker gör det möjligt för kunder att distribuera arbetsbelastningar på lätta virtuella datorer, så kallade microVMs, som ger förbättrad säkerhet och arbetsbelastningsisolering över traditionella virtuella datorer, samtidigt som containrars hastighet och resurseffektivitet möjliggörs. Aktivering av Kata-containrar på AWS EKS kräver en rad manuella steg som beskrivs i Förbättra Kubernetes-arbetsbelastningsisolering och säkerhet med katacontainrar.

Dedikerade värdar

När du använder Amazon Elastic Kubernetes Service (EKS) för att distribuera och köra containrar kan du köra dem på dedikerade Amazon EC2-värdar. Observera dock att den här funktionen endast är tillgänglig för självhanterade nodgrupper. Det innebär att kunderna måste skapa en starta mall manuellt, grupper för automatisk skalningoch registrera dem med EKS-klustret. Skapandeprocessen för dessa resurser är densamma som för allmän automatisk EC2-skalning.

Mer detaljerad information om hur du kör containrar på dedikerade EC2-värdar med AWS EKS finns i följande dokumentation:

AKS-noder och nodpooler

När du skapar ett AKS-kluster skapas och konfigureras automatiskt ett kontrollplan som tillhandahåller kubernetes-kärntjänster och dirigering av programarbetsbelastningar. Azure-plattformen tillhandahåller AKS-kontrollplanet utan kostnad som en hanterad Azure-resurs. Kontrollplanet och dess resurser finns bara i den region där du skapade klustret.

Noderna, som även kallas agentnoder eller arbetsnoder, är värdar för arbetsbelastningar och program. I AKS hanterar och betalar kunderna fullständigt för agentnoderna som är kopplade till AKS-klustret.

För att köra program och stödtjänster behöver ett AKS-kluster minst en nod: En virtuell Azure-dator (VM) för att köra Kubernetes-nodkomponenterna och containerkörningen. Varje AKS-kluster måste innehålla minst en systemnodpool med minst en nod.

AKS grupperar noder med samma konfiguration i nodpooler med virtuella datorer som kör AKS-arbetsbelastningar. Systemnodpooler har det primära syftet att vara värd för kritiska systempoddar, till exempel CoreDNS. Användarnodpooler har det primära syftet att vara värd för arbetsbelastningspoddar. Om du bara vill ha en nodpool i ditt AKS-kluster, till exempel i en utvecklingsmiljö, kan du schemalägga programpoddar i systemnodpoolen.

Diagram som visar en enskild Kubernetes-noder.

Du kan också skapa flera användarnodpooler för att separera olika arbetsbelastningar på olika noder för att undvika det bullriga granneproblemet eller för att stödja program med olika beräknings- eller lagringskrav.

Varje agentnod i en system- eller användarnodpool är en virtuell dator som etableras som en del av Azure Virtual Machine Scale Sets och hanteras av AKS-klustret. Mer information finns i Noder och nodpooler.

Du kan definiera det inledande talet och storleken för arbetsnoder när du skapar ett AKS-kluster eller när du lägger till nya noder och nodpooler i ett befintligt AKS-kluster. Om du inte anger en VM-storlek är standardstorleken Standard_D2s_v3 för Windows-nodpooler och Standard_DS2_v2 för Linux-nodpooler.

Viktigt!

Om du vill ge bättre svarstid för anrop inom noden och kommunikation med plattformstjänster väljer du en VM-serie som stöder accelererat nätverk.

Skapa nodpool

Du kan lägga till en nodpool i ett nytt eller befintligt AKS-kluster med hjälp av verktygen Azure Portal, Azure CLI, AKS REST API eller infrastruktur som kod (IaC), till exempel Bicep, Azure Resource Manager-mallar eller Terraform. Mer information om hur du lägger till nodpooler i ett befintligt AKS-kluster finns i Skapa och hantera flera nodpooler för ett kluster i Azure Kubernetes Service (AKS).

När du skapar en ny nodpool skapas den associerade VM-skalningsuppsättningen i nodresursgruppen, en Azure-resursgrupp som innehåller alla infrastrukturresurser för AKS-klustret. Dessa resurser omfattar Kubernetes-noder, virtuella nätverksresurser, hanterade identiteter och lagring.

Som standard har nodresursgruppen ett namn som MC_<resourcegroupname>_<clustername>_<location>. AKS tar automatiskt bort nodresursgruppen när du tar bort ett kluster, så du bör endast använda den här resursgruppen för resurser som delar klustrets livscykel.

Lägga till en nodpool

I följande kodexempel används kommandot Azure CLI az aks nodepool add för att lägga till en nodpool med namnet mynodepool med tre noder i ett befintligt AKS-kluster som heter myAKSCluster i myResourceGroup resursgruppen.

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

Nodpooler för oanvänd kapacitet

En nodpool för oanvänd kapacitet är en nodpool som backas upp av en skalningsuppsättning för virtuella datorer med oanvänd kapacitet. Användning av virtuella datorer med oanvänd kapacitet för noder med ditt AKS-kluster drar nytta av outnyttad Azure-kapacitet till betydande kostnadsbesparingar. Mängden tillgänglig outnyttad kapacitet varierar beroende på många faktorer, inklusive nodstorlek, region och tid på dagen.

När du distribuerar en nodpool för oanvänd kapacitet allokerar Azure de oanvända noderna om det finns tillgänglig kapacitet. Men det finns inget serviceavtal (SLA) för dekornoderna. En skalningsuppsättning för oanvänd kapacitet som säkerhetskopierar nodpoolen för oanvänd kapacitet distribueras i en enda feldomän och erbjuder inga garantier för hög tillgänglighet. När Azure behöver tillbaka kapaciteten avlägsnar Azure-infrastrukturen skalningsnoder för oanvänd kapacitet, och du får högst 30 sekunders varsel innan du avlägsnar den. Tänk på att en skalningsuppsättningsnodpool inte kan vara klustrets standardnodpool. En nodpool för oanvänd kapacitet kan endast användas för en sekundär pool.

Oanvända noder är för arbetsbelastningar som kan hantera avbrott, tidiga avslutningar eller avhysningar. Till exempel är batchbearbetningsjobb, utvecklings- och testmiljöer och stora beräkningsarbetsbelastningar bra kandidater för schemaläggning på en nodpool med oanvänd kapacitet. Mer information finns i punktinstansens begränsningar.

Följande az aks nodepool add kommando lägger till en nodpool för oanvänd kapacitet till ett befintligt kluster med automatisk skalning aktiverat.

  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

Mer information om nodpooler för oanvänd kapacitet finns i Lägga till en skalningsuppsättningsnodpool i ett AKS-kluster (Azure Kubernetes Service).

Tillfälliga operativsystemdiskar

Som standard replikerar Azure automatiskt den virtuella datorns operativsystemdisk (OS) till Azure Storage för att undvika dataförlust om den virtuella datorn behöver flyttas till en annan värd. Men eftersom containrar inte är utformade för att bevara det lokala tillståndet, ger operativsystemets disk i lagring ett begränsat värde för AKS. Det finns vissa nackdelar, till exempel långsammare nodetablering och högre svarstid för läsning/skrivning.

Tillfälliga OS-diskar lagras däremot endast på värddatorn, till exempel en tillfällig disk, och ger lägre svarstid för läsning/skrivning och snabbare nodskalning och klusteruppgraderingar. Precis som en tillfällig disk ingår en tillfällig OS-disk i priset för virtuella datorer, så du debiteras inga extra lagringskostnader.

Viktigt!

Om du inte uttryckligen begär hanterade diskar för operativsystemet är AKS som standard ett tillfälliga operativsystem om möjligt för en viss nodpoolskonfiguration.

Om du vill använda tillfälliga operativsystem måste OS-disken få plats i den virtuella datorns cacheminne. Dokumentation om virtuella Azure-datorer visar storleken på den virtuella datorns cache i parenteser bredvid I/O-dataflöde som cachestorlek i gibibyte (GiB).

AkS-standardvärdet Standard_DS2_v2 VM-storlek med standardstorleken 100 GB OS stöder tillfälliga operativsystem, men har bara 86 GB cachestorlek. Den här konfigurationen är som standard hanterad disk om du inte uttryckligen anger något annat. Om du uttryckligen begär tillfälliga operativsystem för den här storleken får du ett verifieringsfel.

Om du begär samma Standard_DS2_v2 virtuella dator med en 60 GB OS-disk får du ett tillfälliga operativsystem som standard. Den begärda os-storleken på 60 GB är mindre än den maximala cachestorleken på 86 GB.

Standard_D8s_v3 med en 100 GB OS-disk stöder tillfälliga operativsystem och har 200 GB cacheutrymme. Om en användare inte anger operativsystemdisktypen får en nodpool ett tillfälliga operativsystem som standard.

Följande az aks nodepool add kommando visar hur du lägger till en ny nodpool i ett befintligt kluster med en tillfällig OS-disk. Parametern --node-osdisk-type anger os-disktypen till Ephemeral, och parametern --node-osdisk-size definierar os-diskstorleken.

  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

Mer information om tillfälliga OS-diskar finns i tillfälliga operativsystem.

Nodpooler för virtuella datorer i Azure Kubernetes Service (AKS)

Varje hanterad nodgrupp i EKS backas upp av en Amazon EC2 Auto Scaling-grupp, som hanteras av Amazon EKS. Med den här integreringen kan EKS automatiskt hantera etablering och skalning av EC2-instanser i nodgruppen. Grupper för automatisk skalning kan konfigureras för att stödja flera EC2-instanstyper, men de ger inte möjlighet att ange hur många noder som ska skapas eller skalas för varje instanstyp. I stället hanterar EKS skalningen av nodgruppen baserat på önskad konfiguration och principer som definierats av användaren. Detta säkerställer en förenklad och automatiserad hanteringsprocess för nodgruppen och ger flexibilitet när det gäller att välja de EC2-instanstyper som passar dina arbetsbelastningskrav. AWS-kunder kan dock starta självhanterade Amazon Linux-noder med eksctl eller AWS-hanteringskonsolen.

Med vm-nodpoolerhanterar Azure Kubernetes Service (AKS) etablering och start av varje agentnod. För nodpooler för vm-skalningsuppsättningar hanterar AKS modellen för vm-skalningsuppsättningar och använder den för att uppnå konsekvens mellan alla agentnoder i nodpoolen. I stället gör nodpooler för virtuella datorer att du kan orkestrera klustret med virtuella datorer som passar dina enskilda arbetsbelastningar bäst och ange hur många noder som ska skapas eller skalas för varje virtuell datorstorlek.

En nodpool består av en uppsättning virtuella datorer, med olika storlekar (SKU:er) avsedda att stödja olika typer av arbetsbelastningar. Dessa storlekar på virtuella datorer, som kallas SKU:er, kategoriseras i olika familjer som är optimerade för specifika ändamål. Mer information om SKU:er för virtuella datorer finns i översikten över VM-SKU:er.

För att aktivera skalning av flera storlekar på virtuella datorer använder nodpoolstypen Virtuella datorer en ScaleProfile som konfigurerar hur nodpoolen skalar, särskilt den önskade listan över storlek och antal virtuella datorer. En ManualScaleProfile är en skalningsprofil som anger önskad storlek och antal virtuella datorer. Endast en virtuell datorstorlek tillåts i en ManualScaleProfile. Du måste skapa en separat ManualScaleProfile för varje virtuell datorstorlek i nodpoolen.

När du skapar en ny nodpool för virtuella datorer behöver du minst en ManualScaleProfile i ScaleProfile. Flera manuella skalningsprofiler kan skapas för en enda nodpool för virtuella datorer.

Fördelarna med nodpooler för virtuella datorer är:

  • Flexibilitet: Nodspecifikationer kan uppdateras efter dina arbetsbelastningar och behov.
  • Finjusterad kontroll: Med kontroller på enskild nodnivå kan du ange och blanda noder i olika specifikationer för att förbättra konsekvensen.
  • Efficiency: Du kan minska nodavtrycket för klustret, vilket förenklar driftskraven.

Nodpooler för virtuella datorer ger en bättre upplevelse för dynamiska arbetsbelastningar och krav på hög tillgänglighet. De gör att du kan konfigurera flera virtuella datorer i samma familj i en nodpool, med din arbetsbelastning automatiskt schemalagd på de tillgängliga resurser som du konfigurerar.

I följande tabell jämförs nodpooler för virtuella datorer med standard skalningsuppsättning nodpooler.

Typ av nodpool Kapacitet
Nodpool för virtuella datorer Du kan lägga till, ta bort eller uppdatera noder i en nodpool. Typer av virtuella datorer kan vara valfri virtuell dator av samma familjetyp (t.ex. D-serien, A-serien osv.).
Vm-skalningsuppsättningsbaserad nodpool Du kan lägga till eller ta bort noder av samma storlek och skriva i en nodpool. Om du lägger till en ny storlek på den virtuella datorn i klustret måste du skapa en ny nodpool.

Nodpooler för virtuella datorer har följande begränsningar:

  • Autoskalning av kluster stöds inte.
  • InfiniBand är inte tillgängligt.
  • Windows-nodpooler stöds inte.
  • Den här funktionen är inte tillgänglig i Azure-portalen. Använd Azure CLI-- eller REST-API:er för att utföra CRUD-åtgärder eller hantera poolen.
  • Ögonblicksbild av nodpoolen stöds inte.
  • Alla vm-storlekar som har valts i en nodpool måste komma från samma virtuella datorfamilj. Du kan till exempel inte blanda en virtuell datortyp i N-serien med en virtuell datortyp i D-serien i samma nodpool.
  • Nodpooler för virtuella datorer tillåter upp till fem olika storlekar på virtuella datorer per nodpool.

Virtuella noder

Du kan använda virtuella noder för att snabbt skala ut programarbetsbelastningar i ett AKS-kluster. Virtuella noder ger dig snabb poddetablering och du betalar bara per sekund för körningstid. Du behöver inte vänta tills klustrets autoskalning distribuerar nya arbetsnoder för att köra fler poddrepliker. Virtuella noder stöds endast med Linux-poddar och noder. Tillägget för virtuella noder för AKS baseras på det virtuella Kubelet-projektet med öppen källkod.

Funktionen för virtuell nod är beroende av Azure Container Instances. Mer information om virtuella noder finns i Skapa och konfigurera ett AKS-kluster (Azure Kubernetes Services) för användning av virtuella noder.

Taints, etiketter och taggar

När du skapar en nodpool kan du lägga till Kubernetes-taints och etiketter och Azure-taggar i den nodpoolen. När du lägger till en taint, etikett eller tagg får alla noder i nodpoolen den tainten, etiketten eller taggen.

Om du vill skapa en nodpool med en taint kan du använda az aks nodepool add kommandot med parametern --node-taints . Om du vill märka noderna i en nodpool kan du använda parametern --labels och ange en lista med etiketter, enligt följande kod:

  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

Mer information finns i Ange en taint, etikett eller tagg för en nodpool.

Reserverade systemetiketter

Amazon EKS lägger till automatiserade Kubernetes-etiketter till alla noder i en hanterad nodgrupp som eks.amazonaws.com/capacityType, som anger kapacitetstypen. AKS lägger också automatiskt till systemetiketter till agentnoder.

Följande prefix är reserverade för AKS-användning och kan inte användas för någon nod:

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

För andra reserverade prefix, se Kubernetes välkända etiketter, anteckningar och taints.

I följande tabell visas etiketter som är reserverade för AKS-användning och som inte kan användas för någon nod. I tabellen anger kolumnen Användning av virtuell nod om etiketten stöds på virtuella noder.

I kolumnen Virtuell nodanvändning:

  • N/A innebär att egenskapen inte gäller för virtuella noder eftersom det skulle kräva att värden ändras.
  • Samma innebär att de förväntade värdena är desamma för en virtuell nodpool som för en standardnodpool.
  • Virtuell ersätter SKU-värden för virtuella datorer eftersom virtuella nodpoddar inte exponerar någon underliggande virtuell dator.
  • Den virtuella nodversionen refererar till den aktuella versionen av den virtuella Versionen av Kubelet-ACI-anslutningsappen.
  • Undernätsnamnet för virtuell nod är det undernät som distribuerar virtuella nodpoddar till Azure Container Instances.
  • Virtuellt nodnätverk är det virtuella nätverket som innehåller det virtuella nodundernätet.
Etikett Värde Exempel på alternativ Användning av virtuell nod
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Samma
kubernetes.io/arch amd64 runtime.GOARCH Ej tillämpligt
kubernetes.io/os <OS Type> Linux eller Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Samma
topology.kubernetes.io/zone <Azure zone> 0 Samma
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Samma
kubernetes.azure.com/mode <mode> User eller System User
kubernetes.azure.com/role agent Agent Samma
kubernetes.azure.com/scalesetpriority <scale set priority> Spot eller Regular Ej tillämpligt
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Samma
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed Ej tillämpligt
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS Ej tillämpligt
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Version av virtuell nod
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Namn på undernät för virtuell nod
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Virtuellt nodnätverk
kubernetes.azure.com/ppg <nodepool ppg name> ppgName Ej tillämpligt
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name Ej tillämpligt
kubernetes.azure.com/accelerator <accelerator> nvidia Ej tillämpligt
kubernetes.azure.com/fips_enabled <fips enabled> True Ej tillämpligt
kubernetes.azure.com/os-sku <os/sku> Se Skapa eller uppdatera OS SKU Linux SKU

Windows-nodpooler

AKS har stöd för att skapa och använda Windows Server-containernodpooler via azure-containernätverksgränssnittet (CNI). Information om hur du planerar nödvändiga undernätsintervall och nätverksöverväganden finns i Konfigurera Azure CNI-nätverk.

Följande az aks nodepool add kommando lägger till en nodpool som kör Windows Server-containrar.

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

Föregående kommando använder standardundernätet i det virtuella AKS-klustrets virtuella nätverk. Mer information om hur du skapar ett AKS-kluster med en Windows-nodpool finns i Skapa en Windows Server-container i AKS.

Överväganden för nodpool

Följande överväganden och begränsningar gäller när du skapar och hanterar nodpooler och flera nodpooler:

  • Kvoter, storleksbegränsningar för virtuella datorer och regiontillgänglighet gäller för AKS-nodpooler.
  • Systempooler måste innehålla minst en nod. Du kan ta bort en systemnodpool om du har en annan systemnodpool som ska ta plats i AKS-klustret. Användarnodpooler kan innehålla noll eller fler noder.
  • Du kan inte ändra storleken på den virtuella datorn för en nodpool när du har skapat den.
  • För flera nodpooler måste AKS-klustret använda Standard SKU-lastbalanserare. Grundläggande SKU-lastbalanserare stöder inte flera nodpooler.
  • Alla klusternodpooler måste finnas i samma virtuella nätverk och alla undernät som är tilldelade till en nodpool måste finnas i samma virtuella nätverk.
  • Om du skapar flera nodpooler när klustret skapas måste Kubernetes-versionerna för alla nodpooler matcha kontrollplanets version. Du kan uppdatera versioner när klustret har etablerats med hjälp av åtgärder per nodpool.

Skalning av nodpool

När programarbetsbelastningen ändras kan du behöva ändra antalet noder i en nodpool. Du kan skala upp eller ned antalet noder manuellt med kommandot az aks nodepool scale . I följande exempel skalas antalet noder in mynodepool till fem:

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

Skala nodpooler automatiskt med hjälp av autoskalning av kluster

AKS stöder automatiskt skalning av nodpooler med autoskalning av kluster. Du aktiverar den här funktionen i varje nodpool och definierar ett minsta och ett maximalt antal noder.

Följande az aks nodepool add kommando lägger till en ny nodpool som anropas mynodepool till ett befintligt kluster. Parametern --enable-cluster-autoscaler aktiverar autoskalning av kluster i den nya nodpoolen, och parametrarna --min-count och --max-count anger det lägsta och högsta antalet noder i poolen.

  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

Följande az aks nodepool update-kommando uppdaterar det minsta antalet noder från en till tre för nodpoolen mynewnodepool .

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

Du kan inaktivera autoskalning av klustret med az aks nodepool update genom att skicka parametern --disable-cluster-autoscaler .

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

Om du vill återanvända autoskalning av klustret i ett befintligt kluster använder du az aks nodepool update, anger parametrarna --enable-cluster-autoscaler, --min-countoch --max-count .

Mer information om hur du använder autoskalning av kluster för enskilda nodpooler finns i Skala ett kluster automatiskt för att uppfylla programkraven på Azure Kubernetes Service (AKS).

Poddsandboxning

AKS-kunder kan enkelt konfigurera och köra Kata Containers på AKS på ett fullständigt hanterat sätt. Detta möjliggörs med hjälp av Pod Sandboxing, en funktion som skapar en isoleringsgräns mellan containerprogrammet och containervärdens delade kernel- och beräkningsresurser.

AKS innehåller en mekanism som kallas Pod Sandboxing som tillhandahåller en isoleringsgräns mellan containerprogrammet och den delade kerneln och beräkningsresurserna för containervärden, till exempel PROCESSOR, minne och nätverk. Poddsandboxning kompletterar andra säkerhetsåtgärder eller dataskyddskontroller som hjälper klientorganisationer att skydda känslig information och uppfylla efterlevnadskrav för reglering, bransch eller styrning, till exempel PCI DSS (Payment Card Industry Data Security Standard), International Organization for Standardization (ISO) 27001 och Health Insurance Portability and Accountability Act (HIPAA).

Genom att distribuera program i separata kluster eller nodpooler kan du starkt isolera klientarbetsbelastningarna för olika team eller kunder. Att använda flera kluster och nodpooler kan vara lämpligt för isoleringskraven för många organisationer och SaaS-lösningar, men det finns scenarier där ett enda kluster med delade VM-nodpooler är effektivare. Du kan till exempel använda ett enda kluster när du kör obetrodda och betrodda poddar på samma nod eller samlokaliserar DaemonSets och privilegierade containrar på samma nod för snabbare lokal kommunikation och funktionell gruppering. Pod Sandboxing kan hjälpa dig att isolera klientprogram på samma klusternoder utan att behöva köra dessa arbetsbelastningar i separata kluster eller nodpooler. Andra metoder kräver att du omkompilerar din kod eller orsakar andra kompatibilitetsproblem, men Pod Sandboxing i AKS kan köra valfri container som inte har modifierats inuti en förbättrad säkerhetsgräns för virtuella datorer.

Poddsandboxning på AKS baseras på Kata Containers som körs på Azure Linux-containervärd för AKS stack för att tillhandahålla maskinvaruisolering. Kata Containers på AKS bygger på en säkerhetshärdad Azure-hypervisor. Den uppnår isolering per podd via en kapslad, lätt Kata VM som använder resurser från en överordnad VM-nod. I den här modellen får varje Kata-podd sin egen kernel i en kapslad virtuell Kata-gästdator. Använd den här modellen om du vill placera många Kata-containrar på en enda virtuell gästdator medan du fortsätter att köra containrar på den överordnade virtuella datorn. Den här modellen ger en stark isoleringsgräns i ett delat AKS-kluster.

Mer information finns i:

Dedikerad Azure-värd

Azure Dedicated Host är en tjänst som tillhandahåller fysiska servrar som är dedikerade till en enda Azure-prenumeration och tillhandahåller maskinvaruisolering på fysisk servernivå. Du kan etablera dessa dedikerade värdar inom en region, tillgänglighetszon och feldomän, och du kan placera virtuella datorer direkt i de etablerade värdarna.

Det finns flera fördelar med att använda Azure Dedicated Host med AKS, bland annat:

  • Maskinvaruisolering säkerställer att inga andra virtuella datorer placeras på de dedikerade värdarna, vilket ger ett extra lager av isolering för klientarbetsbelastningar. Dedikerade värdar distribueras i samma datacenter och delar samma nätverk och underliggande lagringsinfrastruktur som andra icke-isolerade värdar.
  • Azure Dedicated Host ger kontroll över underhållshändelser som Azure-plattformen initierar. Du kan välja ett underhållsperiod för att minska påverkan på tjänster och säkerställa tillgänglighet och sekretess för klientarbetsbelastningar.

Azure Dedicated Host kan hjälpa SaaS-leverantörer att se till att klientprogram uppfyller regel-, bransch- och styrningsefterlevnadskrav för att skydda känslig information. Mer information finns i Lägg till en dedikerad Azure-värd i ett AKS-kluster.

Karpenter

Karpenter är ett projekt för nodlivscykelhantering med öppen källkod som skapats för Kubernetes. Genom att lägga till Karpenter i ett Kubernetes-kluster kan du förbättra effektiviteten och kostnaden för att köra arbetsbelastningar i klustret. Karpenter bevakar poddar som Kubernetes-schemaläggaren markerar som oplanerade. Den etablerar och hanterar även dynamiskt noder som kan uppfylla poddkraven.

Karpenter ger detaljerad kontroll över nodetablering och arbetsbelastningsplacering i ett hanterat kluster. Den här kontrollen förbättrar flera klientorganisationer genom att optimera resursallokering, säkerställa isolering mellan varje klientorganisations program och minska driftskostnaderna. När du skapar en lösning för flera klienter på AKS tillhandahåller Karpenter användbara funktioner som hjälper dig att hantera olika programkrav för att stödja olika klientorganisationer. Du kan till exempel behöva vissa klientprogram för att köras på GPU-optimerade nodpooler och andra för att köras på minnesoptimerade nodpooler. Om ditt program kräver låg svarstid för lagring kan du använda Karpenter för att ange att en podd kräver en nod som körs i en specifik tillgänglighetszon så att du kan samplacera lagrings- och programnivån.

AKS möjliggör automatisk avetablering av noder i AKS-kluster via Karpenter. De flesta användare bör använda autoetableringsläget för noder för att aktivera Karpenter som ett hanterat tillägg. Mer information finns i Node autoprovisioning. Om du behöver mer avancerad anpassning kan du välja att själv vara värd för Karpenter. Mer information finns i AKS Karpenter-providern.

Konfidentiella virtuella datorer

Konfidentiell databehandling är en säkerhetsåtgärd som syftar till att skydda data när de används via programvara eller maskinvaruassisterad isolering och kryptering. Den här tekniken lägger till ett extra säkerhetslager för traditionella metoder, som skyddar vilande data och under överföring.

AWS-plattformen stöder konfidentiell databehandling via Nitro Enclaves, som finns på EC2-instanser samt på Amazon Elastic Kubernetes Service (EKS). Mer information finns i den här artikeln i Amazon-dokumentationen. Dessutom stöder Amazon EC2-instanser AMD SEV-SNP-. Den här GitHub--lagringsplatsen innehåller artefakter för att skapa och distribuera en Amazon Machine Image (AMI) för EKS med stöd för AMD SEV-SNP.

Å andra sidan ger Azure kunder konfidentiella virtuella datorer för att uppfylla strikta krav på isolering, sekretess och säkerhet i ett AKS-kluster. Dessa konfidentiella virtuella datorer använder en maskinvarubaserad betrodd körningsmiljö. Mer specifikt använder azure-konfidentiella virtuella datorer amd säker krypterad virtualisering – säker kapslad växling (SEV-SNP) teknik, som nekar hypervisor-kod och annan kodåtkomst för värdhantering till vm-minne och -tillstånd. Detta lägger till ytterligare ett lager av skydd och skydd mot operatörsåtkomst. Mer information finns i dokumentationen om med hjälp av konfidentiella virtuella datorer i ett AKS-kluster och översikt över konfidentiella virtuella datorer i Azure.

Fips (Federal Information Process Standards)

FIPS 140-3 är en amerikansk myndighetsstandard som definierar minimikrav för kryptografiska moduler i produkter och system för informationsteknik. Genom att aktivera FIPS-efterlevnad för AKS-nodpoolerkan du förbättra isoleringen, sekretessen och säkerheten för dina klientarbetsbelastningar. FIPS- efterlevnad säkerställer användningen av validerade kryptografiska moduler för kryptering, hashning och andra säkerhetsrelaterade åtgärder. Med FIPS-aktiverade AKS-nodpooler kan du uppfylla regel- och branschefterlevnadskrav genom att använda robusta kryptografiska algoritmer och mekanismer. Azure tillhandahåller dokumentation om hur du aktiverar FIPS för AKS-nodpooler, vilket gör att du kan stärka säkerhetsstatusen för dina AKS-miljöer med flera klientorganisationer. Mer information finns i Aktivera FIPS för AKS-nodpooler.

Värdbaserad kryptering

I EKS kan din arkitektur ha använt följande funktioner för att förbättra datasäkerheten:

Värdbaserad kryptering på AKS stärker ytterligare klientorganisations arbetsbelastningsisolering, sekretess och säkerhet. När du aktiverar värdbaserad kryptering krypterar AKS vilande data på de underliggande värddatorerna, vilket säkerställer att känslig klientinformation skyddas mot obehörig åtkomst. Tillfälliga diskar och tillfälliga OS-diskar krypteras i vila med plattformshanterade nycklar när du aktiverar kryptering från slutpunkt till slutpunkt.

I AKS använder operativsystem och datadiskar kryptering på serversidan med plattformshanterade nycklar som standard. Cacheminnena för dessa diskar krypteras i vila med plattformshanterade nycklar. Du kan ange din egen nyckelkrypteringsnyckel för att kryptera dataskyddsnyckeln med hjälp av kuvertkryptering, även kallat omslutning. Cachen för operativsystemet och datadiskarna krypteras också via BYOK- som du anger.

Värdbaserad kryptering lägger till ett säkerhetslager för miljöer med flera klientorganisationer. Varje klients data i operativsystemet och datadiskcachen krypteras i vila med antingen kundhanterade eller plattformshanterade nycklar, beroende på den valda diskkrypteringstypen. Mer information finns i:

Uppdateringar och uppgraderingar

Azure uppdaterar regelbundet sin värdplattform för virtuella datorer för att förbättra tillförlitlighet, prestanda och säkerhet. Dessa uppdateringar sträcker sig från korrigering av programvarukomponenter i värdmiljön till uppgradering av nätverkskomponenter eller avaktivering av maskinvara. Mer information om hur Azure uppdaterar virtuella datorer finns i Underhåll för virtuella datorer i Azure.

Uppdateringar av vm-värdinfrastruktur påverkar vanligtvis inte värdbaserade virtuella datorer, till exempel agentnoder i befintliga AKS-kluster. För uppdateringar som påverkar värdbaserade virtuella datorer minimerar Azure de fall som kräver omstarter genom att pausa den virtuella datorn när värden uppdateras eller direktmigrera den virtuella datorn till en redan uppdaterad värd.

Om en uppdatering kräver en omstart tillhandahåller Azure ett meddelande och ett tidsfönster så att du kan starta uppdateringen när den fungerar åt dig. Självunderhållsfönstret för värddatorer är vanligtvis 35 dagar, såvida inte uppdateringen är brådskande.

Du kan använda Planerat underhåll för att uppdatera virtuella datorer och hantera meddelanden om planerat underhåll med Azure CLI, PowerShell eller Azure Portal. Planerat underhåll identifierar om du använder automatisk uppgradering av kluster och schemalägger uppgraderingar under underhållsfönstret automatiskt. Mer information om planerat underhåll finns i kommandot az aks maintenanceconfiguration och Use Planned Maintenance to schedule maintenance windows for your Azure Kubernetes Service (AKS) cluster (Använda planerat underhåll för att schemalägga underhållsperioder för ditt AKS-kluster (Azure Kubernetes Service).

Kubernetes-uppgraderingar

En del av AKS-klusterlivscykeln uppgraderar regelbundet till den senaste Kubernetes-versionen. Det är viktigt att använda uppgraderingar för att få de senaste säkerhetsversionerna och funktionerna. Om du vill uppgradera Kubernetes-versionen av befintliga virtuella nodpooler måste du spärra och tömma noder och ersätta dem med nya noder som baseras på en uppdaterad Kubernetes-diskavbildning.

Som standard konfigurerar AKS uppgraderingar till överspänning med en extra nod. Ett standardvärde för en för max-surge inställningarna minimerar arbetsbelastningsavbrott genom att skapa en extra nod som ersätter äldre versionsnoder innan befintliga program spärras eller töms. Du kan anpassa max-surge värdet per nodpool för att möjliggöra en kompromiss mellan uppgraderingshastighet och uppgraderingsavbrott. max-surge Om du ökar värdet slutförs uppgraderingsprocessen snabbare, men ett stort värde för max-surge kan orsaka störningar under uppgraderingsprocessen.

Ett värde på 100 % ger till exempel max-surge den snabbaste möjliga uppgraderingsprocessen genom att dubblera antalet noder, men gör också att alla noder i nodpoolen töms samtidigt. Du kanske vill använda det här höga värdet för testning, men för produktionsnodpooler är en max-surge inställning på 33 % bättre.

AKS accepterar både heltals- och procentvärden för max-surge. Ett heltal som 5 anger att fem extra noder ska ökas. Procentvärden för max-surge kan vara minst 1% och högst , avrundade 100%upp till närmaste nodantal. Värdet 50% anger ett överspänningsvärde på hälften av det aktuella antalet noder i poolen.

Under en uppgradering max-surge kan värdet vara minst 1 och ett högsta värde som är lika med antalet noder i nodpoolen. Du kan ange större värden, men det maximala antalet noder som används för max-surge är inte högre än antalet noder i poolen.

Viktigt!

För uppgraderingsåtgärder behöver nodtoppar tillräckligt med prenumerationskvot för det begärda max-surge antalet. Till exempel har ett kluster som har fem nodpooler, var och en med fyra noder, totalt 20 noder. Om varje nodpool har ett max-surge värde på 50 % behöver du ytterligare beräknings- och IP-kvot på 10 noder, eller två noder gånger fem pooler, för att slutföra uppgraderingen.

Om du använder Azure Container Networking Interface (CNI) kontrollerar du också att du har tillräckligt med IP-adresser i undernätet för att uppfylla CNI-kraven för AKS.

Uppgradera nodpooler

Om du vill se tillgängliga uppgraderingar använder du az aks get-upgrades.

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

Om du vill se status för nodpooler använder du az aks nodepool-listan.

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

Följande kommando använder az aks nodepool upgrade för att uppgradera en enskild nodpool.

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

Mer information om hur du uppgraderar Kubernetes-versionen för ett klusterkontrollplan och nodpooler finns i:

Att tänka på när du uppgraderar

Observera dessa metodtips och överväganden för att uppgradera Kubernetes-versionen i ett AKS-kluster.

  • Det är bäst att uppgradera alla nodpooler i ett AKS-kluster till samma Kubernetes-version. Standardbeteendet för uppgraderingar av az aks upgrade alla nodpooler och kontrollplanet.

  • Uppgradera manuellt eller ange en kanal för automatisk uppgradering i klustret. Om du använder Planerat underhåll för att korrigera virtuella datorer startar även automatiska uppgraderingar under det angivna underhållsfönstret. Mer information finns i Uppgradera ett kluster i Azure Kubernetes Service (AKS).

  • Kommandot az aks upgrade med --control-plane-only flaggan uppgraderar bara klusterkontrollplanet och ändrar inte någon av de associerade nodpoolerna i klustret. Om du vill uppgradera enskilda nodpooler anger du målnodpoolen och Kubernetes-versionen i az aks nodepool upgrade kommandot .

  • En AKS-klusteruppgradering utlöser en avspärrning och tömning av dina noder. Om du har låg beräkningskvot kan uppgraderingen misslyckas. Mer information om hur du ökar din kvot finns i Öka regionala vCPU-kvoter.

  • Konfigurera parametern max-surge baserat på dina behov med hjälp av ett heltal eller ett procentvärde. För produktionsnodpooler använder du en max-surge inställning på 33 %. Mer information finns i Anpassa uppgradering av nodtoppar.

  • När du uppgraderar ett AKS-kluster som använder CNI-nätverk kontrollerar du att undernätet har tillräckligt med tillgängliga privata IP-adresser för de extra noder som max-surge inställningarna skapar. Mer information finns i Konfigurera Azure CNI-nätverk i Azure Kubernetes Service (AKS).

  • Om klusternodpoolerna sträcker sig över flera Tillgänglighetszoner i en region kan uppgraderingsprocessen tillfälligt orsaka en obalanserad zonkonfiguration. Mer information finns i Särskilda överväganden för nodpooler som sträcker sig över flera Tillgänglighetszoner.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg