Vanliga frågor och svar om AKS

AKS tillhandahåller serviceavtalsgarantier (SLA) på prisnivån Standard med funktionen Drifttids-SLA.

Plattformsstöd är en reducerad supportplan för kluster av version n-3 som inte stöds. Plattformsstöd omfattar endast stöd för Azure infrastruktur.

Mer information finns i plattformens supportprincip.

Ja, AKS initierar automatiska uppgraderingar för kluster som inte stöds. När ett kluster i en n-3-version (där n är den senaste aks-delversionen som stöds som är allmänt tillgänglig) håller på att falla till n-4 uppgraderar AKS automatiskt klustret till n-2 för att stanna kvar i en AKS-supportprincip.

Mer information finns i Kubernetes-versioner som stöds, Fönster för planerat underhåll och Automatiska uppgraderingar.

AKS-agentnoder faktureras som standard Azure virtuella datorer (VM). Om du har köpt Azure-reservationer för den VM-storlek som du använder i AKS, appliceras dessa rabatter automatiskt.

Ja, AKS stöder Windows Server containrar. För mer information, se FAQ för Windows Server på AKS.

AKS stöder fyra huvudsakliga Linux-operativsystem, inklusive Ubuntu Linux, Azure Linux, Azure Linux OS Guard och Flatcar Container Linux för AKS. När du anger --os-type Linux när nodpoolen skapas eller kluster skapas är standardoperativsystemet Ubuntu Linux.

När du använder --os-sku Ubuntuanvänder AKS som standard Ubuntu 22.04 i Kubernetes version 1.25-1.34. AKS använder som standard Ubuntu 24.04 i Kubernetes versioner 1.35+. När du använder --os-sku AzureLinux används Azure Linux 3.0 som standard i AKS för Kubernetes versioner 1.32+. I vissa scenarier, till exempel FIPS-aktiverade nodpooler, kan standardversionen av operativsystemet skilja sig åt. Mer information finns i nodbilder .

Nej. Det går för närvarande inte att flytta AKS-klustret mellan klientorganisationer.

Nej. Det går för närvarande inte att flytta AKS-klustret mellan prenumerationer.

Nej. Det går för närvarande inte att flytta AKS-klustret till ett annat virtuellt nätverk.

Nej. Det går inte att flytta eller byta namn på AKS-klustret och dess associerade resurser.

Nej. Du kan inte återställa klustret när du har tagit bort det. När du tar bort klustret tas även nodresursgruppen och alla dess resurser bort.

Om du vill behålla någon av dina resurser flyttar du dem till en annan resursgrupp innan du tar bort klustret. Om du vill skydda mot oavsiktliga borttagningar kan du låsa den AKS-hanterade resursgrupp som är värd för dina klusterresurser med hjälp av låsning av nodresursgrupp.

Du kan stoppa ett körande AKS-kluster eller skala alla eller specifika User nodpooler till noll, eller använda autoskalning.

Du kan inte skala systemnodpooler direkt till noll.

Nej. Skalningsåtgärder som använder API:er för VM-skalningsuppsättningar stöds inte. Du kan använda AKS-API:erna (az aks scale).

Nej. Skalningsåtgärder som använder API:er för VM-skalningsuppsättningar stöds inte. Du kan använda AKS-API:et för att skala icke-systemnodpooler till noll eller stoppa klustret i stället.

Nej. Den här konfigurationen stöds inte. Stoppa klustret i stället.

AKS bygger på många Azure infrastrukturresurser, inklusive vm-skalningsuppsättningar, virtuella nätverk och hanterade diskar. Med de här integreringarna kan du använda många av kärnfunktionerna i den Azure plattformen i den hanterade Kubernetes-miljön som tillhandahålls av AKS. Du kan till exempel använda de flesta Azure VM-typer direkt med AKS, och du kan använda Azure Reservationer för att få rabatter på dessa resurser automatiskt.

För att aktivera den här arkitekturen omfattar varje AKS-distribution två resursgrupper:

1. Du skapar den första resursgruppen. Den här gruppen innehåller endast Kubernetes-tjänstresursen. AKS-resursprovidern skapar automatiskt den andra resursgruppen under distributionen. Ett exempel på den andra resursgruppen är MC_myResourceGroup_myAKSCluster_eastus. Information om hur du anger namnet på den andra resursgruppen finns i nästa avsnitt.
2. Den andra resursgruppen, som kallas nodresursgruppen, innehåller alla infrastrukturresurser som är associerade med klustret. Dessa resurser omfattar virtuella Kubernetes-noddatorer, virtuella nätverk och lagring. Som standard har nodresursgruppen ett namn som MC_myResourceGroup_myAKSCluster_eastus. AKS tar automatiskt bort nodresursgruppen när du tar bort klustret. Använd endast den här resursgruppen för resurser som delar klustrets livscykel.

Som standard namnger AKS nodresursgruppen MC_resourcegroupname_clustername_location, men du kan ange ditt eget namn.

Om du vill ange ditt eget resursgruppsnamn installerar du aks-preview Azure CLI-tilläggsversionen 0.3.2 eller senare. När du skapar ett AKS-kluster med hjälp az aks create av kommandot använder du parametern --node-resource-group och anger ett namn för resursgruppen. Om du använder en Azure Resource Manager mall för att distribuera ett AKS-kluster kan du definiera resursgruppens namn med hjälp av egenskapen nodeResourceGroup.

• Azure-resursprovider skapar automatiskt den sekundära resursgruppen.
• Du kan bara ange ett anpassat resursgruppnamn när du skapar klustret.

När du arbetar med nodresursgruppen kan du inte:

• Ange en befintlig resursgrupp för nodresursgruppen.
• Ange en annan prenumeration för nodresursgruppen.
• Ändra namnet på nodens resursgrupp när du har skapat klustret.
• Ange namn för de hanterade resurserna i nodresursgruppen.
• Ändra eller ta bort Azure taggar för hanterade resurser i nodresursgruppen.

Du kan få oväntade skalnings- och uppgraderingsfel om du ändrar eller tar bort Azure taggar och andra resursegenskaper i nodresursgruppen. Med AKS kan du skapa och ändra anpassade taggar som skapats av slutanvändare, och du kan lägga till taggarna när du skapar en nodpool. Du kanske vill skapa eller ändra anpassade taggar, till exempel för att tilldela en affärsenhet eller ett kostnadsställe. Ett annat alternativ är att tillämpa principer och ändra taggar via själva AKS-resursen, särskilt via kluster- och nodpoolerna.

Azure-skapade taggar skapas för sina respektive Azure-tjänster, och du ska alltid tillåta dem. För AKS finns taggarna aks-managed och k8s-azure . Att ändra taggar som skapats Azure på resurser under nodresursgruppen i AKS-klustret är en åtgärd som inte stöds, vilket bryter mot servicenivåmålet (SLO).

AKS använder Helm för att leverera komponenter till klustret. Du kan säkert ignorera aks-managed Helm-versioner med prefixet. Kontinuerligt ökande revisioner av dessa Helm-versioner är förväntade och säkra.

En fullständig lista över tillgängliga regioner finns i AKS-regioner och tillgänglighet.

Nej. AKS-kluster är regionala resurser och kan inte sträcka sig över regioner. Vägledning om hur du skapar en arkitektur som innehåller flera regioner finns i metodtips för affärskontinuitet och haveriberedskap.

Ja, du kan distribuera ett AKS-kluster i en eller flera tillgänglighetszoner i regioner som stöder dem.

Ja, du kan använda olika VM-storlekar i ditt AKS-kluster genom att skapa flera nodpooler.

AKS anger ingen gräns för containeravbildningens storlek. Men ju större bild, desto högre minnesefterfrågan. En större storlek kan potentiellt överskrida resursgränserna eller det övergripande tillgängliga minnet för arbetsnoder. Som standard är minne för VM-storlek Standard_DS2_v2 för ett AKS-kluster inställt på 7 GiB.

När en containeravbildning är för stor, som i terabyteintervallet (TB), kanske kubelet inte kan hämta den från containerregistret till en nod på grund av bristen på diskutrymme.

För Windows Server noder körs inte Windows Update automatiskt och tillämpar de senaste uppdateringarna. Du bör utföra en uppgradering på klustret och Windows Server nodpooler i AKS-klustret. Följ ett regelbundet schema baserat på Windows Update versionscykel och din egen valideringsprocess. Den här uppgraderingsprocessen skapar noder som kör den senaste Windows Server avbildningen och korrigeringarna och sedan tar bort de äldre noderna. Mer information om den här processen finns i Uppgradera en nodpool i AKS.

Följande avbildningar har funktionella krav för att köras som root-användare, och undantag måste göras för alla policyer.

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Ja, det finns två alternativ för att begränsa åtkomsten till API-servern:

• Använd API-serverauktoriserade IP-intervall om du vill underhålla en offentlig slutpunkt för API-servern men begränsa åtkomsten till en uppsättning betrodda IP-intervall.
• Använd ett privat kluster om du vill begränsa API-servern till att endast vara tillgänglig inifrån ditt virtuella nätverk.

AKS korrigerar CVE:er som har en leverantörskorrigering varje vecka. CVE:er utan korrigering väntar på en leverantörskorrigering innan de kan åtgärdas. AKS-avbildningarna uppdateras automatiskt inom 30 dagar. Vi rekommenderar att du tillämpar en uppdaterad nodavbildning på en vanlig takt för att säkerställa att de senaste korrigerade bilderna och os-korrigeringarna tillämpas och är aktuella. Du kan göra den här uppgiften:

• Manuellt via Azure-portalen eller Azure CLI.
• Genom att uppgradera ditt AKS-kluster. Klustret uppgraderar avspärrnings- och tömningsnoder automatiskt. Sedan tas en ny nod online med den senaste Ubuntu-avbildningen och en uppdaterad korrigeringsversion eller en mindre Kubernetes-version. Mer information finns i Uppgradera ett AKS-kluster.
• Genom att använda en nodenbilduppgradering.

Microsoft ger vägledning för andra åtgärder som du kan vidta för att skydda dina arbetsbelastningar via tjänster som Microsoft Defender för containrar. Information om ett säkerhetshot som rör AKS och Kubernetes finns i Nya storskaliga kampanjmål för Kubeflow (8 juni 2021).

Nej. Alla data lagras i klustrets region.

Om din podd körs som en icke-root användare (vilket den bör), måste du normalt ange en fsGroup-parameter i poddens säkerhetskontext så att volymen kan läsas och skrivas av podden. Mer information om det här kravet finns i Konfigurera en säkerhetskontext för en podd eller container.

En bieffekt av inställningen fsGroup är att varje gång en volym monteras måste Kubernetes använda chown() kommandona och chmod() rekursivt för alla filer och kataloger i volymen (med några få undantag). Det här scenariot inträffar även om gruppägarskapet för volymen redan matchar den begärda fsGroup parametern. Den här konfigurationen kan vara dyr för större volymer med många små filer, vilket kan göra att poddstarten tar lång tid. Det här scenariot var ett känt problem före v1.20. Lösningen är att ange att podden ska köras som root.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Problemet löstes med Kubernetes version 1.20. Mer information finns i Kubernetes 1.20: Detaljerad kontroll över volymbehörighetsändringar.

AKS använder säker tunnelkommunikation för att möjliggöra att api-server och enskilda node kubelets kommunicerar, även över separata virtuella nätverk. Tunneln skyddas genom ömsesidig Transport Layer Security (TLS)-kryptering. Den aktuella huvudtunneln som AKS använder är Konnectivity, som tidigare kallades apiserver-network-proxy. Kontrollera att alla nätverksregler följer Azure nödvändiga nätverksregler och fullständigt kvalificerade domännamn (FQDN).

Ja, du kan lägga till anteckningen kubernetes.azure.com/set-kube-service-host-fqdn i poddar för att ange variabeln KUBERNETES_SERVICE_HOST till domännamnet för API-servern i stället för IP-adressen för tjänsten i klustret. Den här ändringen är användbar i de fall då klustrets utgående sker via en layer 7-brandvägg. Ett exempel är när du använder Azure Firewall med programregler.

AKS tillämpar inte nätverkssäkerhetsgrupper (NSG:er) på sitt undernät och ändrar inte någon av de NSG:er som är associerade med det undernätet. AKS ändrar endast NSG-inställningarna för nätverksgränssnittet. Om du använder CNI (Container Network Interface) måste du också se till att säkerhetsreglerna i NSG:erna tillåter trafik mellan nod- och pod-CIDR-intervallen (klasslös interdomänroutning). Om du använder kubenet måste du också se till att säkerhetsreglerna i NSG:erna tillåter trafik mellan noden och podd-CIDR. Mer information finns i Nätverkssäkerhetsgrupper.

AKS-noder kör chrony-tjänsten, som hämtar tid från den lokala värd. Kontainrar som körs på poddar får tid från AKS-noderna. Program som öppnas i en container använder tid från poddens container.

Nej. AKS är en hanterad tjänst. Manipulering av IaaS-resurser (infrastruktur som en tjänst) stöds inte. Om du vill installera anpassade komponenter använder du Kubernetes API:er och mekanismer. Använd till exempel DaemonSets för att installera nödvändiga komponenter.

AKS stöder följande antagningskontrollanter:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

För närvarande kan du inte ändra listan över antagningskontrollanter i AKS.

Ja, du kan använda webhooks för inträdeskontroller i AKS. Vi rekommenderar att du undantar interna AKS-namnområden som är markerade med control-plane etiketten. Till exempel:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS begränsar API-serverns utgående trafik, så att dina webhooks för admissionskontroll behöver vara tillgängliga inifrån klustret.

För att skydda systemets stabilitet och förhindra att anpassade antagningskontrollanter påverkar interna tjänster i kube-system-namnområdet har AKS en antagningsverkställare som automatiskt exkluderar kube-system och AKS interna namnområden. Den här tjänsten ser till att de anpassade antagningskontrollanterna inte påverkar de tjänster som körs i kube-system.

Om du har ett viktigt användningsfall för att distribuera något på kube-system (rekommenderas inte) till stöd för din anpassade webhook för antagning kan du lägga till följande etikett eller kommentar så att antagningstvingandet ignorerar det:

• Etikett: "admissions.enforcer/disabled": "true"
• Anteckning: "admissions.enforcer/disabled": true

Azure Key Vault provider för Secrets Store CSI Driver erbjuder en naturlig integrering av Azure Key Vault i AKS.

Noder som är aktiverade med FIPS (Federal Information Processing Standards) stöds nu i Linux-baserade nodpooler. Mer information finns i Lägga till en FIPS-aktiverad nodpool.

Alla korrigeringar, inklusive en säkerhetskorrigering, tillämpas automatiskt på AKS-klustret. Allt som är större än en korrigering, till exempel större eller mindre versionsändringar (som kan ha icke-bakåtkompatibla ändringar i dina distribuerade objekt), uppdateras när du uppdaterar klustret om en ny version är tillgänglig. Information om när en ny version är tillgänglig finns i AKS-releasenoter.

AKS Linux-tillägget är ett Azure VM-tillägg som installerar och konfigurerar övervakningsverktyg på Kubernetes-arbetsnoder. Tillägget installeras på alla nya och befintliga Linux-noder. Den konfigurerar följande övervakningsverktyg:

• Nodexportör: Samlar in maskinvarutelemetri från den virtuella datorn och gör den tillgänglig med hjälp av en måttslutpunkt. Sedan kan ett övervakningsverktyg, till exempel Prometheus, skrota dessa mått.
• Node-problem-detector: Syftar till att göra olika nodproblem synliga för överordnade lager i klusterhanteringsstacken. Det är en systemd-enhet som körs på varje nod, identifierar nodproblem och rapporterar dem till klustrets API-server genom att använda Events och NodeConditions.
• ig: Är ett eBPF-baserat ramverk med öppen källkod för felsökning och observation av Linux- och Kubernetes-system. Den innehåller en uppsättning verktyg (eller prylar) som samlar in relevant information som användarna kan använda för att identifiera orsaken till prestandaproblem, krascher eller andra avvikelser. I synnerhet gör dess oberoende från Kubernetes det möjligt för användare att använda det även för felsökning av kontrollplansproblem.

Dessa verktyg hjälper till att ge observerbarhet kring många nodhälsorelaterade problem, till exempel:

• Problem med infrastrukturdaemon: NTP-tjänsten är nere
• Maskinvaruproblem: Felaktig processor, minne eller disk
• Kernelproblem: Kernel-dödläge, skadat filsystem
• Problem med containerruntime: Runtime-daemon som inte svarar

Tillägget kräver inte extra utgående åtkomst till webbadresser, IP-adresser eller portar utöver de dokumenterade AKS-utgående kraven. Det kräver inga särskilda behörigheter som beviljas i Azure. Den använder kubeconfig för att ansluta till API-servern för att skicka de övervakningsdata som samlas in.

De flesta kluster tas bort vid användarbegäran. I vissa fall, särskilt när du tar med din egen resursgrupp eller utför aktiviteter mellan resursgrupper, kan borttagningen ta längre tid eller till och med misslyckas. Om du har problem med borttagningar kontrollerar du att du inte har lås på resursgruppen. Se till att alla resurser utanför resursgruppen inte är kopplade till resursgruppen.

Om du har problem med att skapa och uppdatera kluster kontrollerar du att du inte har några tilldelade principer eller tjänstbegränsningar som kan blockera AKS-klustret från att hantera resurser som virtuella datorer, lastbalanserare eller taggar.

Det kan du, men vi rekommenderar det inte. Utför uppdateringar när klustrets tillstånd är känt och felfritt.

Nej. Ta bort noder som är i ett feltillstånd eller på annat sätt från klustret innan du uppgraderar.

Oftast uppstår det här felet om du har en eller flera nätverkssäkerhetsgrupper som fortfarande är associerade med klustret. Ta bort dem och försök att ta bort klustret igen.

Bekräfta att tjänstens huvudnamn inte har upphört att gälla. Mer information finns i AKS-tjänstens huvudnamn och AKS-uppdateringsautentiseringsuppgifter.

Bekräfta att tjänsthuvudnamnet inte har upphört att gälla. Mer information finns i AKS-tjänsthuvudkonto och uppdatera-AKS-autentiseringsuppgifter.

Från och med den 17 mars 2027 stöder Azure Kubernetes Service (AKS) inte längre eller tillhandahåller säkerhetsuppdateringar Ubuntu 20.04. Alla befintliga nodbilder tas bort och du kan inte skala några nodpooler som kör Ubuntu 20.04. Migrera till en Ubuntu-version som stöds genom att uppgradera dina nodpooler till Kubernetes version 1.35+. Mer information om den här tillbakadragningen finns i Retirement GitHub issue and the Azure Updates retirement announcement. Om du vill hålla dig informerad om meddelanden och uppdateringar följer du AKS-viktig information.

Från och med den 1 mars 2026 stöder Azure Kubernetes Service (AKS) inte längre Windows Server 2019 nodpooler. Nodpooler som kör Kubernetes version 1.33+ kan inte använda Windows Server 2019. Från och med den 1 april 2027 tar AKS bort alla befintliga nodbilder för Windows Server 2019, vilket innebär att skalningsåtgärderna misslyckas. Mer information om den här tillbakadragningen finns i Retirement GitHub issue and the Azure Updates retirement announcement. Om du vill hålla dig informerad om meddelanden och uppdateringar följer du AKS-viktig information. Från och med den 15 mars 2027 stöder Azure Kubernetes Service (AKS) inte längre Windows Server 2022 nodpooler. Nodpooler som kör Kubernetes version 1.36+ kan inte använda Windows Server 2022. Från och med den 1 april 2028 tar AKS bort alla befintliga nodbilder för Windows Server 2022, vilket innebär att skalningsåtgärderna misslyckas. Mer information om den här tillbakadragningen finns i Retirement GitHub issue and the Azure Updates retirement announcement. Om du vill hålla dig informerad om meddelanden och uppdateringar följer du AKS-viktig information.