Grundläggande Kubernetes-begrepp för Azure Kubernetes Service (AKS)

  • Artikel

I den här artikeln beskrivs grundläggande begrepp för Azure Kubernetes Service (AKS), en hanterad Kubernetes-tjänst som du kan använda för att distribuera och använda containerbaserade program i stor skala i Azure. Det hjälper dig att lära dig mer om infrastrukturkomponenterna i Kubernetes och få en djupare förståelse för hur Kubernetes fungerar i AKS.

Vad är Kubernetes?

Kubernetes är en snabbt växande plattform som hanterar containerbaserade program och tillhörande nätverks- och lagringskomponenter. Kubernetes fokuserar på programarbetsbelastningarna och inte de underliggande infrastrukturkomponenterna. Kubernetes tillhandahåller en deklarativ metod för distributioner som backas upp av en robust uppsättning API:er för hanteringsåtgärder.

Du kan skapa och köra moderna, portabla mikrotjänstbaserade program med Kubernetes för att orkestrera och hantera tillgängligheten för programkomponenterna. Kubernetes stöder både tillståndslösa och tillståndskänsliga program.

Som en öppen plattform kan du med Kubernetes skapa dina program med önskat programmeringsspråk, operativsystem, bibliotek eller meddelandebuss. Befintliga verktyg för kontinuerlig integrering och kontinuerlig leverans (CI/CD) kan integreras med Kubernetes för att schemalägga och distribuera versioner.

AKS tillhandahåller en hanterad Kubernetes-tjänst som minskar komplexiteten i distributions- och kärnhanteringsuppgifter. Azure-plattformen hanterar AKS-kontrollplanet och du betalar bara för DE AKS-noder som kör dina program.

Kubernetes-klusterarkitektur

Ett Kubernetes-kluster är indelat i två komponenter:

  • Kontrollplanet, som tillhandahåller kubernetes-kärntjänster och orkestrering av programarbetsbelastningar, och
  • Noder som kör dina programarbetsbelastningar.

Kubernetes-kontrollplan och nodkomponenter

Kontrollplan

När du skapar ett AKS-kluster skapar och konfigurerar Azure-plattformen automatiskt dess associerade kontrollplan. Det här kontrollplanet med en klient tillhandahålls utan kostnad som en hanterad Azure-resurs som abstraheras från användaren. Du betalar bara för de noder som är kopplade till AKS-klustret. Kontrollplanet och dess resurser finns bara i den region där du skapade klustret.

Kontrollplanet innehåller följande kubernetes-kärnkomponenter:

Komponent beskrivning
kube-apiserver API-servern exponerar underliggande Kubernetes-API:er och tillhandahåller interaktionen för hanteringsverktyg, till exempel kubectl eller Kubernetes-instrumentpanelen.
etcd etcd är ett nyckelvärdesarkiv med hög tillgänglighet i Kubernetes som hjälper till att upprätthålla tillståndet för kubernetes-klustret och konfigurationen.
kube-scheduler När du skapar eller skalar program avgör schemaläggaren vilka noder som kan köra arbetsbelastningen och startar de identifierade noderna.
kube-controller-manager Kontrollanthanteraren övervakar ett antal mindre kontrollanter som utför åtgärder som att replikera poddar och hantera nodåtgärder.

Tänk på att du inte kan komma åt kontrollplanet direkt. Kubernetes-kontrollplans- och noduppgraderingar dirigeras via Azure CLI eller Azure-portalen. Om du vill felsöka möjliga problem kan du granska kontrollplansloggarna med hjälp av Azure Monitor.

Kommentar

Om du vill konfigurera eller komma åt ett kontrollplan direkt kan du distribuera ett självhanterat Kubernetes-kluster med hjälp av Kluster-API-providern Azure.

Noder

Om du vill köra dina program och stödtjänster behöver du en Kubernetes-nod. Varje AKS-kluster har minst en nod, en virtuell Azure-dator (VM) som kör Kubernetes-nodkomponenterna och containerkörningen.

Noder innehåller följande kubernetes-kärnkomponenter:

Komponent beskrivning
kubelet Kubernetes-agenten som bearbetar orkestreringsbegäranden från kontrollplanet tillsammans med schemaläggning och körning av de begärda containrarna.
kube-proxy Proxyn hanterar virtuella nätverk på varje nod, dirigerar nätverkstrafik och hanterar IP-adresser för tjänster och poddar.
containerkörning Med containerkörningen kan containerbaserade program köras och interagera med andra resurser, till exempel det virtuella nätverket eller lagringen. Mer information finns i Konfiguration av containerkörning.

Virtuell Azure-dator och stödresurser för en Kubernetes-nod

Storleken på den virtuella Azure-datorn för dina noder definierar processorer, minne, storlek och den tillgängliga lagringstypen, till exempel högpresterande SSD eller vanlig hårddisk. Planera nodstorleken kring om dina program kan kräva stora mängder cpu och minne eller lagring med höga prestanda. Skala ut antalet noder i AKS-klustret för att möta efterfrågan. Mer information om skalning finns i Skalningsalternativ för program i AKS.

I AKS baseras VM-avbildningen för klustrets noder på Ubuntu Linux, Azure Linux eller Windows Server 2022. När du skapar ett AKS-kluster eller skalar ut antalet noder skapar och konfigurerar Azure-plattformen automatiskt det begärda antalet virtuella datorer. Agentnoder faktureras som vanliga virtuella datorer, så eventuella vm-storleksrabatter, inklusive Azure-reservationer, tillämpas automatiskt.

För hanterade diskar tilldelas standardstorleken och prestandan för disken enligt det valda antalet virtuella datorers SKU och vCPU. Mer information finns i Standardstorlek för OS-disk.

Kommentar

Om du behöver avancerad konfiguration och kontroll på din Kubernetes-nodcontainerkörning och operativsystem kan du distribuera ett självhanterat kluster med hjälp av Kluster-API-providern Azure.

OS-konfiguration

AKS stöder Ubuntu 22.04 och Azure Linux 2.0 som nodoperativsystem (OS) för kluster med Kubernetes 1.25 och senare. Ubuntu 18.04 kan också anges när nodpoolen skapas för Kubernetes version 1.24 och senare.

AKS stöder Windows Server 2022 som standardoperativsystem för Windows-nodpooler i kluster med Kubernetes 1.25 och senare. Windows Server 2019 kan också anges när nodpoolen skapas för Kubernetes version 1.32 och senare. Windows Server 2019 dras tillbaka när Kubernetes version 1.32 når slutet av livslängden och stöds inte i framtida versioner. Mer information om den här tillbakadragningen finns i viktig information om AKS.

Konfiguration av containerkörning

En containerkörning är programvara som kör containrar och hanterar containeravbildningar på en nod. Körningen hjälper till att abstrahera sys-anrop eller OS-specifika funktioner för att köra containrar i Linux eller Windows. För Linux-nodpooler containerd används på Kubernetes version 1.19 och senare. För Windows Server 2019- och 2022-nodpooler containerd är det allmänt tillgängligt och är det enda körningsalternativet i Kubernetes version 1.23 och senare. Från och med maj 2023 har Docker dragits tillbaka och stöds inte längre. Mer information om den här tillbakadragningen finns i viktig information om AKS.

Containerd är en OCI-kompatibel kärncontainerkörning (Open Container Initiative) som tillhandahåller den minsta uppsättningen nödvändiga funktioner för att köra containrar och hantera avbildningar på en nod. Medcontainerd baserade noder och nodpooler kommunicerar kubelet direkt containerd med plugin-programmet CRI (container runtime interface) och tar bort extra hopp i dataflödet jämfört med Docker CRI-implementeringen. Därför ser du bättre svarstid för poddstart och mindre resursanvändning (CPU och minne).

Containerd fungerar på alla GA-versioner av Kubernetes i AKS, i varje Kubernetes-version från och med v1.19, och har stöd för alla Kubernetes- och AKS-funktioner.

Viktigt!

Kluster med Linux-nodpooler som skapats på Kubernetes v1.19 eller högre som standard för containerkörningen containerd . Kluster med nodpooler i tidigare Kubernetes-versioner som stöds tar emot Docker för sin containerkörning. Linux-nodpooler uppdateras till containerd när nodpoolens Kubernetes-version har uppdaterats till en version som stöder containerd.

containerd är allmänt tillgängligt för kluster med Windows Server 2019- och 2022-nodpooler och är det enda alternativet för containerkörning för Kubernetes v1.23 och senare. Du kan fortsätta använda Docker-nodpooler och -kluster i tidigare versioner än 1.23, men Docker stöds inte längre från och med maj 2023. Mer information finns i Lägga till en Windows Server-nodpool med containerd.

Vi rekommenderar starkt att du testar dina arbetsbelastningar på AKS-nodpooler med containerd innan du använder kluster med en Kubernetes-version som stöder containerd för dina nodpooler.

containerd begränsningar/skillnader

  • För containerdrekommenderar vi att du använder crictl som ersättning för Docker CLI för felsökning av poddar, containrar och containeravbildningar på Kubernetes-noder. Mer information om crictlfinns i allmänna alternativ för användning och klientkonfiguration.

    • Containerd tillhandahåller inte de fullständiga funktionerna i Docker CLI. Den är endast tillgänglig för felsökning.
    • crictl erbjuder en mer Kubernetes-vänlig vy över containrar, med begrepp som poddar osv. som finns.

  • Containerd konfigurerar loggning med det standardiserade loggningsformatet cri . Loggningslösningen måste ha stöd för loggningsformatet cri , till exempel Azure Monitor for Containers.

  • Du kan inte längre komma åt Docker-motorn, /var/run/docker.sockeller använda Docker-in-Docker (DinD).

    • Om du för närvarande extraherar programloggar eller övervakningsdata från Docker-motorn använder du Container Insights i stället. AKS har inte stöd för att köra några out-of-band-kommandon på agentnoderna som kan orsaka instabilitet.
    • Vi rekommenderar inte att du skapar avbildningar eller använder Docker-motorn direkt. Kubernetes är inte fullt medveten om de förbrukade resurserna och dessa metoder har många problem enligt beskrivningen här och här.

  • När du skapar avbildningar kan du fortsätta att använda ditt aktuella Docker-byggarbetsflöde som vanligt, såvida du inte skapar avbildningar i AKS-klustret. I det här fallet bör du överväga att byta till den rekommenderade metoden för att skapa avbildningar med hjälp av ACR Tasks eller ett säkrare alternativ i klustret som Docker Buildx.

Resursreservationer

AKS använder nodresurser för att hjälpa nodfunktionen som en del av klustret. Den här användningen kan skapa en avvikelse mellan nodens totala resurser och de allokerbara resurserna i AKS. Kom ihåg den här informationen när du ställer in begäranden och gränser för användardistribuerade poddar.

Om du vill hitta en nods allokerbara resurs kan du använda kubectl describe node kommandot:

kubectl describe node [NODE_NAME]

För att upprätthålla nodprestanda och -funktioner reserverar AKS två typer av resurser, CPU och minne, på varje nod. När en nod växer i resurser växer resursreservationen på grund av ett högre behov av hantering av användardistribuerade poddar. Tänk på att resursreservationerna inte kan ändras.

Kommentar

Användning av AKS-tillägg, till exempel Container Insights (OMS), förbrukar extra nodresurser.

Processor

Reserverad PROCESSOR är beroende av nodtyp och klusterkonfiguration, vilket kan orsaka mindre allokerbar CPU på grund av extra funktioner som körs. I följande tabell visas CPU-reservation i millicores:

CPU-kärnor på värden 1 2 4 8 16 32 64
Kube-reserverade (millicores) 60 100 140 180 260 420 740

Minne

Reserverat minne i AKS innehåller summan av två värden:

Viktigt!

AKS 1.29 förhandsgranskas i januari 2024 och innehåller vissa ändringar i minnesreservationer. Dessa ändringar beskrivs i följande avsnitt.

AKS 1.29 och senare

  1. kubelet daemon har regeln memory.available<100Mi borttagning som standard. Den här regeln säkerställer att en nod alltid har minst 100Mi allokerbar. När en värd ligger under tröskelvärdet kubelet för tillgängligt minne utlöser avslutningen av en av de poddar som körs och frigör minne på värddatorn.

  2. En frekvens av minnesreservationer som anges enligt det lägre värdet: 20 MB * Maximalt antal poddar som stöds på Noden + 50 MB eller 25 % av de totala systemminnesresurserna.

    Exempel:

    • Om den virtuella datorn tillhandahåller 8 GB minne och noden stöder upp till 30 poddar reserverar AKS 20 MB * 30 maxpoddar + 50 MB = 650 MB för kube-reserverade. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
    • Om den virtuella datorn tillhandahåller 4 GB minne och noden stöder upp till 70 poddar reserverar AKS 25 % * 4 GB = 1 000 MB för kube-reserverade, eftersom detta är mindre än 20 MB * 70 Max Poddar + 50 MB = 1450 MB.

    Mer information finns i Konfigurera maximala poddar per nod i ett AKS-kluster.

AKS-versioner före 1.29

  1. kubelet daemon har regeln memory.available<750Mi borttagning som standard. Den här regeln säkerställer att en nod alltid har minst 750Mi allokeringsbar. När en värd är under tröskelvärdet kubelet för tillgängligt minne utlöser avslutningen av en av de poddar som körs och frigör minne på värddatorn.
  2. En regressiv frekvens av minnesreservationer för kubelet-daemon för korrekt funktion (kube-reserverad).
    • 25 % av de första 4 GB minne
    • 20 % av nästa 4 GB minne (upp till 8 GB)
    • 10 % av nästa 8 GB minne (upp till 16 GB)
    • 6 % av de kommande 112 GB minne (upp till 128 GB)
    • 2 % av allt minne mer än 128 GB

Kommentar

AKS reserverar ytterligare 2 GB för systemprocesser i Windows-noder som inte ingår i det beräknade minnet.

Regler för minnes- och CPU-allokering är utformade för att:

  • Håll agentnoderna felfria, inklusive vissa värdsystempoddar som är viktiga för klustrets hälsa.
  • Gör så att noden rapporterar mindre allokerbart minne och PROCESSOR än vad den skulle rapportera om den inte var en del av ett Kubernetes-kluster.

Om en nod till exempel erbjuder 7 GB rapporterar den att 34 % av minnet inte kan allokeras, inklusive tröskelvärdet för 750Mi-hård borttagning.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Förutom reservationer för Själva Kubernetes reserverar det underliggande nodoperativsystemet även en mängd PROCESSOR- och minnesresurser för att underhålla OS-funktioner.

För tillhörande metodtips, se Metodtips för grundläggande scheduler-funktioner i AKS.

Nodpooler

Kommentar

Azure Linux-nodpoolen är nu allmänt tillgänglig (GA). Mer information om fördelarna och distributionsstegen finns i Introduktion till Azure Linux Container Host for AKS.

Noder med samma konfiguration grupperas tillsammans i nodpooler. Varje Kubernetes-kluster innehåller minst en nodpool. Du definierar det första antalet noder och storlekar när du skapar ett AKS-kluster, vilket skapar en standardnodpool. Den här standardnodpoolen i AKS innehåller de underliggande virtuella datorer som kör dina agentnoder.

Kommentar

För att säkerställa att klustret fungerar tillförlitligt bör du köra minst två noder i standardnodpoolen.

Du skalar eller uppgraderar ett AKS-kluster mot standardnodpoolen. Du kan välja att skala eller uppgradera en specifik nodpool. För uppgraderingsåtgärder schemaläggs containrar som körs på andra noder i nodpoolen tills alla noder har uppgraderats.

Mer information finns i Skapa nodpooler och Hantera nodpooler.

Standardstorlek för OS-disk

När du skapar ett nytt kluster eller lägger till en ny nodpool i ett befintligt kluster avgör numret för vCPU:er som standard os-diskstorleken. Antalet virtuella processorer baseras på den virtuella datorns SKU. I följande tabell visas standardstorleken för OS-disken för varje VM-SKU:

VM SKU Cores (vCPU:er) Standardnivå för OS-disk Etablerad IOPS Etablerat dataflöde (Mbit/s)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2 300 150
64+ P30/1024G 5000 200

Viktigt!

Standardstorleken för OS-diskar används endast i nya kluster eller nodpooler när tillfälliga OS-diskar inte stöds och ingen standardstorlek för OS-disken anges. Standardstorleken för OS-disken kan påverka prestandan eller kostnaden för klustret. Du kan inte ändra operativsystemets diskstorlek när klustret eller nodpoolen har skapats. Den här standardstorleken för diskar påverkar kluster eller nodpooler som skapades i juli 2022 eller senare.

Nodväljare

I ett AKS-kluster med flera nodpooler kan du behöva tala om för Kubernetes Scheduler vilken nodpool som ska användas för en viss resurs. Ingresskontrollanter bör till exempel inte köras på Windows Server-noder. Du använder nodväljare för att definiera olika parametrar, till exempel nodoperativsystem, för att styra var en podd ska schemaläggas.

I följande grundläggande exempel schemaläggs en NGINX-instans på en Linux-nod med nodväljaren "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Mer information finns i Metodtips för avancerade scheduler-funktioner i AKS.

Nodresursgrupp

När du skapar ett AKS-kluster anger du en Azure-resursgrupp för att skapa klusterresurserna i. Förutom den här resursgruppen skapar och hanterar AKS-resursprovidern en separat resursgrupp som kallas nodresursgruppen. Nodresursgruppen innehåller följande infrastrukturresurser:

  • Vm-skalningsuppsättningar och virtuella datorer för varje nod i nodpoolerna
  • Det virtuella nätverket för klustret
  • Lagringen för klustret

Nodresursgruppen tilldelas som standard ett namn med följande format: MC_resourceGroupName_clusterName_location. När klustret skapas kan du ange namnet som tilldelats till nodresursgruppen. När du använder en Azure Resource Manager-mall kan du definiera namnet med hjälp av nodeResourceGroup egenskapen . När du använder Azure CLI använder du parametern --node-resource-groupaz aks create med kommandot, som du ser i följande exempel:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

När du tar bort AKS-klustret tar AKS-resursprovidern automatiskt bort nodresursgruppen.

Nodresursgruppen har följande begränsningar:

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

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). Om du ändrar eller tar bort Azure-skapade taggar eller andra resursegenskaper i nodresursgruppen kan du få oväntade resultat, till exempel skalnings- och uppgraderingsfel. AKS hanterar infrastrukturlivscykeln i nodresursgruppen, så om du gör ändringar flyttas klustret till ett tillstånd som inte stöds. Mer information finns i Erbjuder AKS ett serviceavtal?

Med AKS kan du skapa och ändra taggar som sprids till resurser i nodresursgruppen, och du kan lägga till taggarna när du skapar eller uppdaterar klustret. Du kanske till exempel vill skapa eller ändra anpassade taggar för att tilldela en affärsenhet eller ett kostnadsställe. Du kan också skapa Azure-principer med ett omfång för den hanterade resursgruppen.

Om du vill minska risken för ändringar i nodresursgruppen som påverkar dina kluster kan du aktivera låsning av nodresursgrupper för att tillämpa en neka-tilldelning på dina AKS-resurser. Mer information finns i Fullständigt hanterad resursgrupp (förhandsversion).

Varning

Om du inte har aktiverat låsning av nodresursgrupp kan du ändra valfri resurs direkt i nodresursgruppen. Direkt ändring av resurser i nodresursgruppen kan göra att klustret blir instabilt eller inte svarar.

Poddar

Kubernetes använder poddar för att köra instanser av ditt program. En enda podd representerar en enda instans av ditt program.

Poddar har vanligtvis en 1:1-mappning med en container. I avancerade scenarier kan en podd innehålla flera containrar. Poddar med flera containrar schemaläggs tillsammans på samma nod och tillåter containrar att dela relaterade resurser.

När du skapar en podd kan du definiera resursbegäranden för en viss mängd cpu eller minne. Kubernetes Scheduler försöker uppfylla begäran genom att schemalägga poddarna så att de körs på en nod med tillgängliga resurser. Du kan också ange maximala resursgränser för att förhindra att en podd förbrukar för mycket beräkningsresurs från den underliggande noden. Vår rekommenderade metod är att inkludera resursgränser för alla poddar för att hjälpa Kubernetes Scheduler att identifiera nödvändiga, tillåtna resurser.

Mer information finns i Kubernetes-poddar och Kubernetes-poddens livscykel.

En podd är en logisk resurs, men programarbetsbelastningar körs på containrarna. Poddar är vanligtvis tillfälliga, disponibla resurser. Individuellt schemalagda poddar missar några av kubernetes-funktionerna med hög tillgänglighet och redundans. I stället distribuerar och hanterar Kubernetes-styrenheter, till exempel distributionskontrollanten, poddar.

Distributioner och YAML-manifest

En distribution representerar identiska poddar som hanteras av Kubernetes-distributionskontrollanten. En distribution definierar antalet poddrepliker som ska skapas. Kubernetes Scheduler ser till att extra poddar schemaläggs på felfria noder om poddar eller noder stöter på problem. Du kan uppdatera distributioner för att ändra konfigurationen av poddar, containeravbildningen eller den anslutna lagringen.

Distributionskontrollanten hanterar distributionens livscykel och utför följande åtgärder:

  • Tömmer och avslutar ett visst antal repliker.
  • Skapar repliker från den nya distributionsdefinitionen.
  • Fortsätter processen tills alla repliker i distributionen har uppdaterats.

De flesta tillståndslösa program i AKS bör använda distributionsmodellen i stället för att schemalägga enskilda poddar. Kubernetes kan övervaka distributionens hälsa och status för att säkerställa att det nödvändiga antalet repliker körs i klustret. När de schemaläggs individuellt startas inte poddar om de stöter på ett problem och de inte schemaläggs om på felfria noder om deras aktuella nod stöter på ett problem.

Du vill inte störa hanteringsbeslut med en uppdateringsprocess om ditt program kräver ett minsta antal tillgängliga instanser. Budgetar för poddstörningar definierar hur många repliker i en distribution som kan tas bort under en uppdatering eller noduppgradering. Om du till exempel har fem repliker i distributionen kan du definiera ett poddfel på fyra för att endast tillåta att en replik tas bort eller schemaläggs om åt gången. Precis som med poddresursgränser rekommenderar vi att du definierar poddstörningar för program som kräver att ett minsta antal repliker alltid finns.

Distributioner skapas och hanteras vanligtvis med kubectl create eller kubectl apply. Du kan skapa en distribution genom att definiera en manifestfil i YAML-format. I följande exempel visas en grundläggande distributionsmanifestfil för en NGINX-webbserver:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

En uppdelning av distributionsspecifikationerna i YAML-manifestfilen är följande:

Specifikation beskrivning
.apiVersion Anger den API-grupp och API-resurs som du vill använda när du skapar resursen.
.kind Anger vilken typ av resurs du vill skapa.
.metadata.name Anger namnet på distributionen. Den här YAML-exempelfilen kör nginx-avbildningen från Docker Hub.
.spec.replicas Anger hur många poddar som ska skapas. Den här YAML-exempelfilen skapar tre duplicerade poddar.
.spec.selector Anger vilka poddar som ska påverkas av den här distributionen.
.spec.selector.matchLabels Innehåller en karta över {key, value} par som gör att distributionen kan hitta och hantera de skapade poddarna.
.spec.selector.matchLabels.app Måste matcha .spec.template.metadata.labels.
.spec.template.labels Anger de {key, value} par som är kopplade till objektet.
.spec.template.app Måste matcha .spec.selector.matchLabels.
.spec.spec.containers Anger listan över containrar som tillhör podden.
.spec.spec.containers.name Anger namnet på containern som anges som en DNS-etikett.
.spec.spec.containers.image Anger containeravbildningens namn.
.spec.spec.containers.ports Anger listan över portar som ska exponeras från containern.
.spec.spec.containers.ports.containerPort Anger antalet portar som ska exponeras på poddens IP-adress.
.spec.spec.resources Anger de beräkningsresurser som krävs av containern.
.spec.spec.resources.requests Anger den minsta mängd beräkningsresurser som krävs.
.spec.spec.resources.requests.cpu Anger den minsta mängd processorkraft som krävs.
.spec.spec.resources.requests.memory Anger den minsta mängd minne som krävs.
.spec.spec.resources.limits Anger den maximala mängden beräkningsresurser som tillåts. Kubelet tillämpar den här gränsen.
.spec.spec.resources.limits.cpu Anger den maximala mängden tillåtna processorer. Kubelet tillämpar den här gränsen.
.spec.spec.resources.limits.memory Anger den maximala mängden minne som tillåts. Kubelet tillämpar den här gränsen.

Mer komplexa program kan skapas genom att inkludera tjänster, till exempel lastbalanserare, i YAML-manifestet.

Mer information finns i Kubernetes-distributioner.

Pakethantering med Helm

Helm används ofta för att hantera program i Kubernetes. Du kan distribuera resurser genom att skapa och använda befintliga offentliga Helm-diagram som innehåller en paketerad version av programkod och Kubernetes YAML-manifest. Du kan lagra Helm-diagram antingen lokalt eller på en fjärrlagringsplats, till exempel en Azure Container Registry Helm-diagramlagringsplats.

Om du vill använda Helm installerar du Helm-klienten på datorn eller använder Helm-klienten i Azure Cloud Shell. Sök efter eller skapa Helm-diagram och installera dem sedan i ditt Kubernetes-kluster. Mer information finns i Installera befintliga program med Helm i AKS.

StatefulSets och DaemonSets

Distributionskontrollanten använder Kubernetes Scheduler och kör repliker på alla tillgängliga noder med tillgängliga resurser. Den här metoden kan vara tillräcklig för tillståndslösa program, men distributionskontrollanten är inte idealisk för program som kräver följande specifikationer:

  • En beständig namngivningskonvention eller lagring.
  • En replik som ska finnas på varje markerad nod i ett kluster.

Med två Kubernetes-resurser kan du dock hantera dessa typer av program: StatefulSets och DaemonSets.

StatefulSets upprätthåller tillståndet för program utöver en enskild poddlivscykel. DaemonSets säkerställer en instans som körs på varje nod tidigt i Kubernetes bootstrap-processen.

StatefulSets

Modern programutveckling syftar ofta till tillståndslösa program. För tillståndskänsliga program, som de som innehåller databaskomponenter, kan du använda StatefulSets. Precis som distributioner skapar och hanterar en StatefulSet minst en identisk podd. Repliker i en StatefulSet följer en graciös, sekventiell metod för distribution, skalning, uppgradering och avslutningsåtgärder. Namngivningskonventionen, nätverksnamnen och lagringen bevaras när repliker schemaläggs om med en StatefulSet.

Du kan definiera programmet i YAML-format med hjälp av kind: StatefulSet. Därifrån hanterar StatefulSet Controller distributionen och hanteringen av de repliker som krävs. Dataskrivningar till beständig lagring som tillhandahålls av Azure Managed Disks eller Azure Files. Med StatefulSets finns den underliggande beständiga lagringen kvar, även när StatefulSet tas bort.

Mer information finns i Kubernetes StatefulSets.

Viktigt!

Repliker i en StatefulSet schemaläggs och körs över alla tillgängliga noder i ett AKS-kluster. För att säkerställa att minst en podd i din uppsättning körs på en nod bör du använda en DaemonSet i stället.

DaemonSets

För specifik loggsamling eller övervakning kan du behöva köra en podd på alla noder eller en viss uppsättning noder. Du kan använda DaemonSets för att distribuera till en eller flera identiska poddar. DaemonSet Controller ser till att varje angiven nod kör en instans av podden.

DaemonSet Controller kan schemalägga poddar på noder tidigt i klusterstartsprocessen innan kubernetes-standardschemaläggaren startar. Den här möjligheten säkerställer att poddarna i ett DaemonSet-tillstånd innan traditionella poddar i en distribution eller StatefulSet schemaläggs.

Precis som StatefulSets kan du definiera en DaemonSet som en del av en YAML-definition med hjälp av kind: DaemonSet.

Mer information finns i Kubernetes DaemonSets.

Kommentar

Om du använder tillägget virtuella noder skapar DaemonSets inte poddar på den virtuella noden.

Namnrymder

Kubernetes-resurser, till exempel poddar och distributioner, grupperas logiskt i namnområden för att dela upp ett AKS-kluster och skapa, visa eller hantera åtkomst till resurser. Du kan till exempel skapa namnområden för att separera affärsgrupper. Användare kan bara interagera med resurser inom sina tilldelade namnområden.

Kubernetes-namnområden för att logiskt dela upp resurser och program

Följande namnområden är tillgängliga när du skapar ett AKS-kluster:

Namnområde beskrivning
standard Där poddar och distributioner skapas som standard när ingen tillhandahålls. I mindre miljöer kan du distribuera program direkt till standardnamnområdet utan att skapa ytterligare logiska separationer. När du interagerar med Kubernetes-API:et, till exempel med kubectl get pods, används standardnamnområdet när inget anges.
kube-system Där kärnresurser finns, till exempel nätverksfunktioner som DNS och proxy, eller Kubernetes-instrumentpanelen. Vanligtvis distribuerar du inte dina egna program till det här namnområdet.
kube-public Vanligtvis används inte, du kan använda den för att resurser ska vara synliga i hela klustret och kan visas av alla användare.

Mer information finns i Kubernetes-namnområden.

Nästa steg

Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar: