Vanliga frågor om Azure Kubernetes Service (AKS)

Den här artikeln tar upp vanliga frågor om Azure Kubernetes Service (AKS).

Vilka Azure-regioner tillhandahåller för närvarande AKS?

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

Kan jag sprida ett AKS-kluster mellan regioner?

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.

Kan jag sprida ett AKS-kluster mellan tillgänglighetszoner?

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

Kan jag begränsa vem som har åtkomst till Kubernetes API-servern?

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.

Kan jag ha olika VM-storlekar i ett enda kluster?

Ja, du kan använda olika storlekar på virtuella datorer i AKS-klustret genom att skapa flera nodpooler.

Tillämpas säkerhetsuppdateringar på AKS-agentnoder?

AKS korrigerar CVE:er som har en "leverantörskorrigering" varje vecka. CVEs utan en korrigering väntar på en "leverantörskorrigering" innan den 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.

Vad är storleksgränsen för en containeravbildning i AKS?

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.

Windows Server-noder

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.

Finns det säkerhetshot mot AKS som jag bör känna till?

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:

Hur kommunicerar det hanterade kontrollplanet med mina noder?

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.

Kan mina poddar använda API-serverns FQDN i stället för klustrets IP-adress?

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.

Varför skapas två resursgrupper med AKS?

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.

    Kommentar

    Att ändra en resurs under nodresursgruppen i AKS-klustret är en åtgärd som inte stöds och orsakar klusteråtgärdsfel. Du kan förhindra att ändringar görs i nodresursgruppen genom att blockera användare från att ändra resurser som hanteras av AKS-klustret.

Kan jag ange mitt eget namn för AKS-nodresursgruppen?

Ja. Som standard namnger AKS nodresursgruppen MC_resourcegroupname_clustername_location, men du kan också 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 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. Se ytterligare information i nästa avsnitt.

Kan jag ändra taggar och andra egenskaper för AKS-resurserna 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). Mer information finns i Erbjuder AKS ett serviceavtal?

Kommentar

Tidigare reserverades taggnamnet "Ägare" för AKS för att hantera den offentliga IP-adress som har tilldelats på klientdelens IP-adress för lastbalanseraren. Nu följer tjänsterna prefixet aks-managed . Använd inte Azure-principer för att använda taggnamnet "Ägare" för äldre resurser. Annars bryts alla resurser i aks-klusterdistributionen och uppdateringsåtgärderna. Detta gäller inte för nyligen skapade resurser.

Vilka Kubernetes-antagningskontrollanter stöder AKS? Kan antagningskontrollanter läggas till eller tas bort?

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.

Kan jag använda webhooks för 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.

Kan webhooks för antagningskontrollanter påverka kube-system och interna AKS-namnområden?

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

Är Azure Key Vault integrerat med AKS?

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

Kan jag köra Windows Server-containrar på AKS?

Ja, Windows Server-containrar är tillgängliga i AKS. Om du vill köra Windows Server-containrar i AKS skapar du en nodpool som kör Windows Server som gästoperativsystem. Windows Server-containrar kan endast använda Windows Server 2019. Information om hur du kommer igång finns i Skapa ett AKS-kluster med en Windows Server-nodpool.

Windows Server-stöd för nodpool innehåller vissa begränsningar som ingår i det överordnade Windows Server i Kubernetes-projektet. Mer information om dessa begränsningar finns i Windows Server-containrar i AKS-begränsningar.

Erbjuder AKS ett serviceavtal?

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

Prisnivån Kostnadsfri har inget associerat serviceavtal, men har ett servicenivåmål99,5 %. Tillfälliga anslutningsproblem observeras om det finns en uppgradering, felaktiga underläggsnoder, plattformsunderhåll, ett program överbelastar API-servern med begäranden osv. För verksamhetskritiska arbetsbelastningar och produktionsarbetsbelastningar, eller om din arbetsbelastning inte tolererar omstarter av API Server, rekommenderar vi att du använder standardnivån, som innehåller serviceavtal för drifttid.

Kan jag tillämpa Azure-reservationsrabatter på mina AKS-agentnoder?

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.

Kan jag flytta/migrera mitt kluster mellan Azure-klientorganisationer?

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

Kan jag flytta/migrera mitt kluster mellan prenumerationer?

För närvarande stöds inte förflyttning av kluster mellan prenumerationer.

Kan jag flytta mina AKS-kluster från den aktuella Azure-prenumerationen till ett annat?

Det går inte att flytta ditt AKS-kluster och dess associerade resurser mellan Azure-prenumerationer.

Kan jag flytta mina AKS-kluster eller AKS-infrastrukturresurser till andra resursgrupper eller byta namn på dem?

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

Varför tar det så lång tid att ta bort mitt kluster?

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.

Varför tar det så lång tid att skapa/uppdatera mitt kluster?

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.

Kan jag återställa mitt kluster när jag har raderat det?

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. Ett exempel på den andra resursgruppen är MC_myResourceGroup_myAKSCluster_eastus.

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.

Vad är plattformsstöd och vad inkluderar det?

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. Plattformsstöd omfattar inte något som är relaterat till följande:

  • Kubernetes-funktioner och -komponenter
  • Skapa kluster- eller nodpool
  • Snabbkorrigeringar
  • Felkorrigeringar
  • Säkerhetskorrigeringar
  • Tillbakadragna komponenter

Mer information om begränsningar finns i plattformens supportprincip.

AKS förlitar sig på versioner och korrigeringar från Kubernetes, som är ett projekt med öppen källkod som endast stöder ett skjutfönster med tre mindre versioner. AKS kan bara garantera fullständigt stöd medan dessa versioner hanteras uppströms. Eftersom det inte finns några fler korrigeringar som skapas uppströms kan AKS antingen lämna dessa versioner okopplade eller förgrena sig. På grund av den här begränsningen stöder plattformssupport inte något från att förlita sig på kubernetes uppströms.

Uppgraderar AKS automatiskt mina kluster som inte stöds?

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. Automatisk uppgradering av ett plattformskluster som stöds till en version som stöds aktiveras som standard.

Till exempel uppgraderar kubernetes v1.25 till v1.26 under v1.29 GA-versionen. Konfigurera underhållsperioder för att minimera störningar. Mer information om automatiska uppgraderingskanaler finns i Automatisk uppgradering .

Om jag har poddar/distributioner i tillståndet "NodeLost" eller "Okänd" kan jag fortfarande uppgradera mitt kluster?

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

Kan jag utföra en uppgradering om jag har ett kluster med en eller flera noder i feltillstånd eller avstängt?

Nej, ta bort/ta bort noder i ett feltillstånd eller på annat sätt från klustret innan du uppgraderar.

Jag körde en klusterborttagning, men ser felet [Errno 11001] getaddrinfo failed

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.

Jag har kört en uppgradering, men nu är mina poddar i kraschloopar och beredskapsavsökningarna misslyckas?

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

Mitt kluster fungerade, men kan plötsligt inte etablera LoadBalancers, montera datorer osv.?

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

Kan jag skala mitt AKS-kluster till noll?

Du kan helt stoppa ett AKS-kluster som körs och spara på respektive beräkningskostnader. Dessutom kan du välja att skala eller autoskala alla eller specifika User nodpooler till 0, vilket endast behåller den nödvändiga klusterkonfigurationen.

Du kan inte skala systemnodpooler direkt till noll.

Kan jag använda API:erna för VM-skalningsuppsättningar för att skala manuellt?

Nej, skalningsåtgärder med hjälp av API:erna för VM-skalningsuppsättningar stöds inte. Använd AKS-API:erna (az aks scale).

Kan jag använda VM-skalningsuppsättningar för att manuellt skala till noll noder?

Nej, skalningsåtgärder med hjälp av API:erna för VM-skalningsuppsättningar stöds inte. Du kan använda AKS-API:et för att skala till noll nodpooler som inte är systemsystem eller stoppa klustret i stället.

Kan jag stoppa eller avallokera alla mina virtuella datorer?

Även om AKS har motståndskraftsmekanismer för att motstå en sådan konfiguration och återställa från den, är det inte en konfiguration som stöds. Stoppa klustret i stället.

Kan jag använda anpassade VM-tillägg?

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.

Lagrar AKS kunddata utanför klustrets region?

Nej, alla data lagras i klustrets region.

Krävs AKS-avbildningar för att köras som rot?

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

Vad är Transparent Läge för Azure CNI jämfört med bryggläge?

Från och med version 1.2.0 anger Azure CNI transparent läge som standard för linux-CNI-distributioner med en enda klientorganisation. Transparent läge ersätter bryggläge. I följande avsnitt om Bryggläge och Transparent läge diskuterar vi mer om skillnaderna mellan båda lägena och fördelarna och begränsningarna för transparent läge i Azure CNI.

Bryggläge

Azure CNI Bridge-läget skapar en L2-brygga med namnet "azure0" på ett "just-in-time"-sätt. Alla poddpargränssnitt veth på värdsidan är anslutna till den här bryggan. Pod-Pod intra VM-kommunikation och den återstående trafiken går genom den här bryggan. Bryggan är en virtuell layer 2-enhet som på egen hand inte kan ta emot eller överföra något om du inte binder en eller flera verkliga enheter till den. Därför måste eth0 för den virtuella Linux-datorn konverteras till en underordnad "azure0"-brygga, vilket skapar en komplex nätverkstopologi i den virtuella Linux-datorn. Som ett symptom var CNI tvunget att hantera andra nätverksfunktioner, till exempel DNS-serveruppdateringar.

Bridge mode topology

I följande exempel visas hur konfigurationen av IP-vägen ser ut i bryggläge. Oavsett hur många poddar noden har finns det bara två vägar någonsin. Den första vägen säger att trafik (exklusive lokal på azure0) går till standardgatewayen för undernätet via gränssnittet med ip "src 10.240.0.4", vilket är Node primary IP. Den andra säger "10.20.x.x" Poddutrymme till kernel för kernel att bestämma.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Transparent läge

Transparent läge är ett enkelt sätt att konfigurera Linux-nätverk. I det här läget ändrar Inte Azure CNI några egenskaper för eth0-gränssnittet på den virtuella Linux-datorn. Den här metoden för att ändra Linux-nätverksegenskaper hjälper till att minska komplexa problem med hörnfall som kluster kan stöta på med Bridge-läge. I transparent läge skapar och lägger Azure CNI till poddpargränssnitt veth på värdsidan som läggs till i värdnätverket. Kommunikation mellan virtuella datorer från podd till podd sker via ip-vägar som lagts till av CNI. I princip är podd-till-pod-kommunikation över layer 3- och L3-routningsregler väg poddtrafik.

Transparent mode topology

I följande exempel visas en konfiguration av ip-vägen för transparent läge. Varje podds gränssnitt får en statisk väg ansluten så trafik med dest IP som podden skickas direkt till poddens gränssnitt för värdsidan veth .

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Fördelar med transparent läge

  • Tillhandahåller åtgärder för conntrack DNS-parallella konkurrensvillkor och undvikande av 5-sekunders DNS-svarstidsproblem utan att du behöver konfigurera nodlokal DNS (du kan fortfarande använda lokal DNS för noder av prestandaskäl).
  • Eliminerar det inledande CNI-bryggläget med 5 sekunders DNS-svarstid som introduceras idag på grund av bryggkonfigurationen "just in time".
  • Ett av hörnfallen i bryggläge är att Azure CNI inte kan fortsätta att uppdatera de anpassade DNS-serverlistor som användare lägger till i antingen VNET eller NIC. Det här scenariot resulterar i att CNI bara plockar upp den första instansen av DNS-serverlistan. Det här problemet löses i transparent läge eftersom CNI inte ändrar några eth0-egenskaper. Se mer här.
  • Ger bättre hantering av UDP-trafik och åtgärder för UDP-översvämningsstorm när ARP överskrider tidsgränsen. I bryggläge, när bryggan inte känner till en MAC-adress för målpodden i podd-till-pod-kommunikation mellan virtuella datorer, resulterar det avsiktligt i storm av paketet till alla portar. Det här problemet löses i transparent läge eftersom det inte finns några L2-enheter i sökvägen. Se mer här.
  • Transparent läge presterar bättre i pod-till-pod-kommunikation mellan virtuella datorer när det gäller dataflöde och svarstid jämfört med bryggläge.

Hur undviker du långsamma problem med behörighetsägarskapsinställningen när volymen har flera filer?

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.

Kan jag använda FIPS kryptografiska bibliotek med distributioner på AKS?

FIPS-aktiverade noder stöds nu i Linux-baserade nodpooler. Mer information finns i Lägga till en FIPS-aktiverad nodpool.

Kan jag konfigurera NSG:er med AKS?

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.

Hur fungerar tidssynkronisering i AKS?

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.

Hur uppdateras AKS-tillägg?

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.

Vad är syftet med AKS Linux-tillägget som jag ser installerat på mina Linux Virtual Machine Scale Sets-instanser?

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.