Vanliga frågor och svar om AKS

AKS tillhandahåller SLA-garantier på prisnivån Standard med funktionen Drifttid för serviceavtal.

Plattformsstöd är en reducerad supportplan för "N-3"-versionskluster 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 GA-delversionen som stöds) håller på att sjunka 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.

Ja, AKS stöder Windows Server-containrar. Mer information finns i Windows Server-containrar på AKS.

AKS-agentnoder faktureras som vanliga virtuella Azure-datorer. Om du har köpt Azure-reservationer för den VM-storlek som du använder i AKS tillämpas dessa rabatter automatiskt.

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 inte att flytta eller byta namn på AKS-klustret och dess associerade resurser.

Nej, du kan inte återställa klustret när du har raderat 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 resursgruppen som är värd för dina klusterresurser med hjälp av låsning av nodresursgrupp.

Du kan helt stoppa ett AKS-kluster som körs eller skala eller autoskala alla eller specifika User nodpooler till noll.

Du kan inte skala systemnodpooler direkt till noll.

Nej, skalningsåtgärder som använder API:erna 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:erna för VM-skalningsuppsättningar stöds inte. Du kan använda AKS-API:et för att skala nodpooler som inte är systembaserade till noll eller stoppa klustret i stället.

Nej, det här är inte en konfiguration som stöds. Stoppa klustret i stället.

Nej, skalningsåtgärder som använder API:erna för VM-skalningsuppsättningar stöds inte. Du kan använda AKS-API:erna (az aks scale). 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 Azure-plattformen i den hanterade Kubernetes-miljön som tillhandahålls av AKS. De flesta typer av virtuella Azure-datorer kan till exempel användas direkt med AKS och Azure-reservationer kan användas 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. Du bör bara använda det här klustret 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 ett eget resursgruppsnamn installerar du Azure CLI-tillägget aks-preview version 0.3.2 eller senare. När du skapar ett AKS-kluster med kommandot [az aks create][az-aks-create] 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 egenskapen nodeResourceGroup .

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

När du arbetar med nodresursgruppen bör du tänka på att du inte kan:

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

Du kan få oväntade skalnings- och uppgraderingsfel om du ändrar eller tar bort Azure-skapade 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 skapa Azure-principer med ett omfång för den hanterade resursgruppen.

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

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. Se metodtips för affärskontinuitet och haveriberedskap för vägledning om hur du skapar en arkitektur som innehåller flera regioner.

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 storlekar på virtuella datorer i AKS-klustret genom att skapa flera nodpooler.

AKS anger ingen gräns för containeravbildningens storlek. Det är dock viktigt att förstå att ju större bild, desto högre minnesbehov. 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 Terabyte-intervallet (TBs), kanske kubelet inte kan hämta den från containerregistret till en nod på grund av brist på diskutrymme.

För Windows Server-noder körs inte Windows Update automatiskt och tillämpar de senaste uppdateringarna. Enligt ett regelbundet schema runt Windows Update-versionscykeln och din egen valideringsprocess bör du utföra en uppgradering av klustret och Windows Server-nodpoolerna i AKS-klustret. 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 funktionskrav för "Kör som rot" och undantag måste arkiveras för alla principer:

• 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 Server-auktoriserade 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. CVEs utan en korrigering väntar på en "leverantörskorrigering" innan de kan åtgärdas. AKS-avbildningarna uppdateras automatiskt inom 30 dagar. Vi rekommenderar att du använder en uppdaterad nodavbildning regelbundet för att säkerställa att de senaste korrigerade bilderna och os-korrigeringarna tillämpas och är aktuella. Du kan göra detta med någon av följande metoder:

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

Microsoft tillhandahåller 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. Följande säkerhetshot är relaterat till AKS och Kubernetes som du bör känna till:

• Ny storskalig kampanj riktar sig mot Kubeflow (8 juni 2021).

Nej, alla data lagras i klustrets region.

Traditionellt om din podd körs som en icke-root-användare (vilket du bör) måste du ange en fsGroup i poddens säkerhetskontext så att volymen kan läsas och skrivas av podden. Detta krav beskrivs mer detaljerat här.

En bieffekt av inställningen fsGroup är att varje gång en volym monteras måste Kubernetes rekursivt chown() och chmod() alla filer och kataloger inuti volymen (med några undantag som anges nedan). Det här scenariot inträffar även om gruppägarskapet för volymen redan matchar den begärda fsGroup. Det kan vara dyrt för större volymer med många små filer, vilket kan göra att poddstarten tar lång tid. Det här scenariot har varit ett känt problem före v1.20 och lösningen är att ange poddkörningen som rot:

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

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

AKS använder en säker tunnelkommunikation för att tillåta api-server- och enskilda nod-kubelets att kommunicera även i separata virtuella nätverk. Tunneln skyddas via mTLS-kryptering. Den aktuella huvudtunneln som används av AKS är Konnectivity, som tidigare kallades apiserver-network-proxy. Kontrollera att alla nätverksregler följer de Nätverksregler och FQDN som krävs i Azure.

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. Detta är användbart i de fall då klustrets utgående sker via en layer 7-brandvägg, till exempel när du använder Azure Firewall med programregler.

AKS tillämpar inte nätverkssäkerhetsgrupper (NSG:er) på undernätet och ändrar inte någon av de NSG:er som är associerade med det undernätet. AKS ändrar endast nätverksgränssnittens NSG-inställningar. Om du använder CNI måste du också se till att säkerhetsreglerna i NSG:erna tillåter trafik mellan noden och podd-CIDR-intervallen. 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 localhost. Containrar som körs på poddar får tid från AKS-noderna. Program som startas i en container använder tid från poddens container.

Nej. AKS är en hanterad tjänst och manipulering av IaaS-resurserna 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:

• NamnområdeLivscykel
• 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 antagningskontrollanter på AKS. Vi rekommenderar att du exkluderar interna AKS-namnområden som är markerade med kontrollplansetiketten. Till exempel:

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

AKS brandväggar API-serverns utgående så att antagningskontrollantens webhooks måste 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-systemet, har namnområdet AKS en enforcer för antagning, vilket 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 kritiskt 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 Admissions Enforcer ignorerar den.

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

Azure Key Vault Provider for Secrets Store CSI Driver tillhandahåller intern integrering av Azure Key Vault i AKS.

FIPS-aktiverade noder 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. Du kan se när en ny version är tillgänglig genom att gå till AKS-viktig information.

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 systemenhet som körs på varje nod, identifierar nodproblem och rapporterar dem till klustrets API-server med hjälp av Händelser och NodeConditions.
• ig: 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 är utformade för att samla in relevant information, så att användarna kan 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.

De här verktygen hjälper till att ge observerbarhet kring många problem med nodhälsa, 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 containerkörning: Daemon för körning som inte svarar

Tillägget kräver inte ytterligare utgående åtkomst till url:er, IP-adresser eller portar utöver de dokumenterade KRAVEN för UTGÅENDE AKS. Det kräver inga särskilda behörigheter som beviljats i Azure. Den använder kubeconfig för att ansluta till API-servern för att skicka insamlade övervakningsdata.

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 uppgifter mellan RG, kan borttagningen ta längre tid eller till och med misslyckas. Om du har problem med borttagningar dubbelkollar du att du inte har lås på RG:en, att alla resurser utanför RG:en tas bort från RG och så vidare.

Om du har problem med att skapa och uppdatera klusteråtgärder 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, taggar osv.

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

Nej, ta bort/ta bort noder 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 (NSG:er) som fortfarande används som är associerade med klustret. Ta bort dem och försök ta bort igen.

Bekräfta att tjänstens huvudnamn inte har upphört att gälla. Se autentiseringsuppgifterna för AKS-tjänstens huvudnamn och AKS-uppdatering.

Bekräfta att tjänstens huvudnamn inte har upphört att gälla. Se autentiseringsuppgifterna för AKS-tjänstens huvudnamn och AKS-uppdatering.