Grundläggande Kubernetes-begrepp för Azure Kubernetes Service

  • Artikel

Programutvecklingen fortsätter att gå mot en containerbaserad metod, vilket ökar vårt behov av att orkestrera och hantera resurser. Som den ledande plattformen tillhandahåller Kubernetes tillförlitlig schemaläggning av feltoleranta programarbetsbelastningar. Azure Kubernetes Service (AKS), ett hanterat Kubernetes-erbjudande, förenklar ytterligare distribution och hantering av containerbaserade program.

Den här artikeln beskriver grundläggande begrepp:

  • Komponenter i Kubernetes-infrastrukturen:

    • kontrollplan
    • Noder
    • nodpooler

  • Arbetsbelastningsresurser:

    • Skida
    • Distributioner
    • Uppsättningar

  • Gruppera resurser med hjälp av namnområden.

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, 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 har stöd för både tillståndslösa och tillståndskänsliga program när teamen utvecklas genom införandet av mikrotjänstbaserade 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, till exempel uppgraderingssamordning. 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:

  • Kontrollplan: tillhandahåller kubernetes-kärntjänster och orkestrering av programarbetsbelastningar.
  • Noder: kör dina programarbetsbelastningar.

Kubernetes control plane and node components

Kontrollplan

När du skapar ett AKS-kluster skapas och konfigureras ett kontrollplan automatiskt. Det här kontrollplanet tillhandahålls utan kostnad eftersom en hanterad Azure-resurs 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 är hur de underliggande Kubernetes-API:erna exponeras. Den här komponenten tillhandahåller interaktionen för hanteringsverktyg, till exempel kubectl eller Kubernetes-instrumentpanelen.
etcd För att upprätthålla tillståndet för kubernetes-klustret och konfigurationen är den högtillgängliga osv.en nyckelvärdeslagring i Kubernetes.
kube-scheduler När du skapar eller skalar program avgör Scheduler vilka noder som kan köra arbetsbelastningen och starta dem.
kube-controller-manager Kontrollanthanteraren övervakar ett antal mindre kontrollanter som utför åtgärder som att replikera poddar och hantera nodåtgärder.

AKS tillhandahåller ett kontrollplan för en enda klientorganisation, med en dedikerad API-server, schemaläggare osv. Du definierar antalet och storleken på noderna, och Azure-plattformen konfigurerar säker kommunikation mellan kontrollplanet och noderna. Interaktion med kontrollplanet sker via Kubernetes-API:er, till exempel kubectl eller Kubernetes-instrumentpanelen.

Du behöver inte konfigurera komponenter (t.ex. ett lager med hög tillgänglighet osv .) med det här hanterade kontrollplanet, men du kan inte 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 via Azure Monitor-loggar.

Om du vill konfigurera eller direkt komma åt ett kontrollplan distribuerar du ett självhanterat Kubernetes-kluster med hjälp av Cluster API Provider Azure.

Rekommenderade metoder finns i Metodtips för klustersäkerhet och uppgraderingar i AKS.

Information om AKS-kostnadshantering finns i grunderna för AKS-kostnader och prissättning för AKS.

Noder och nodpooler

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

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 Hanterar virtuella nätverk på varje nod. Proxyn dirigerar nätverkstrafik och hanterar IP-adresser för tjänster och poddar.
containerkörning Tillåter att containerbaserade program körs och interagerar med ytterligare resurser, till exempel det virtuella nätverket eller lagringen. AKS-kluster som använder Kubernetes version 1.19+ för Linux-nodpooler använder containerd som sin containerkörning. Från och med Kubernetes version 1.20 för Windows-nodpooler containerd kan användas som förhandsversion för containerkörningen, men Docker är fortfarande standardcontainerkörningen. AKS-kluster som använder tidigare versioner av Kubernetes för nodpooler använder Docker som containerkörning.

Azure virtual machine and supporting resources for a Kubernetes node

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 runt 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 2019. 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 virtuella standarddatorer, 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.

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.

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.

Kör för att hitta en nods allokerbara resurser:

kubectl describe node [NODE_NAME]

För att upprätthålla nodprestanda och -funktioner reserverar AKS resurser 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.

Kommentar

Om du använder AKS-tillägg som Container Insights (OMS) används ytterligare nodresurser.

Två typer av resurser är reserverade:

Processor

Reserverad PROCESSOR är beroende av nodtyp och klusterkonfiguration, vilket kan orsaka mindre allokerbar CPU på grund av att ytterligare funktioner körs.

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

Minne

Minne som används av 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. Detta säkerställer att en nod alltid har minst 100Mi allokerbar hela tiden. 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 installeras på alla Kubernetes-agentnoder för att hantera skapande och avslutning av containrar. Som standard på AKS kubelet har daemon regeln memory.available<750Mi borttagning, vilket säkerställer att en nod alltid måste ha minst 750Mi allokeringsbar hela tiden. När en värd ligger under tröskelvärdet kubelet för tillgängligt minne utlöses 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 över 128 GB

Kommentar

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

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

  • 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.

Det går inte att ändra ovanstående resursreservationer.

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. Ett Kubernetes-kluster innehåller minst en nodpool. Det initiala antalet noder och storlek definieras när du skapar ett AKS-kluster som 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å (2) 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 om hur du använder flera nodpooler i AKS finns i Skapa flera nodpooler för ett kluster i AKS.

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.

Med nodväljare kan du 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 om hur du styr var poddar är schemalagda finns i Metodtips för avancerade scheduler-funktioner i AKS.

Nodresursgrupp

När du skapar ett AKS-kluster måste du ange en resursgrupp för att skapa klusterresursen i. Förutom den här resursgruppen skapar och hanterar AKS-resursprovidern även 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, till exempel MC_myResourceGroup_myAKSCluster_eastus. När klustret skapas har du också möjlighet att ange namnet som tilldelats till nodresursgruppen. 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.

Om du ändrar eller tar bort Azure-skapade taggar och andra resursegenskaper i nodresursgruppen kan du få oväntade resultat, till exempel skalnings- och uppgraderingsfel. När AKS hanterar livscykeln för infrastrukturen i nodresursgruppen flyttas klustret till ett tillstånd som inte stöds.

Ett vanligt scenario där kunder vill ändra resurser är genom taggar. 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 vill skapa eller ändra anpassade taggar, till exempel för att tilldela en affärsenhet eller ett kostnadsställe. Detta kan också uppnås genom att skapa Azure-principer med ett omfång för den hanterade resursgruppen.

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?

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 Klusterkonfiguration i AKS.

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 en instans av ditt program. En 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 att begära en viss mängd cpu- eller minnesresurser. 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. Bästa praxis ä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 distribueras och hanteras poddar av Kubernetes-styrenheter, till exempel distributionskontrollanten.

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 ytterligare 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, containeravbildning som används eller ansluten lagring. Distributionskontrollanten:

  • 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 poddarna schemaläggs individuellt startas de inte om om de stöter på ett problem och schemaläggs inte 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 (5) repliker i distributionen kan du definiera ett poddfel på 4 (fyra) för att endast tillåta att en replik tas bort eller schemaläggs om i taget. Precis som med poddresursbegränsningar är bästa praxis att definiera budgetar för 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. Skapa en distribution genom att definiera en manifestfil i YAML-format.

I följande exempel skapas en grundläggande distribution av NGINX-webbservern. Distributionen anger tre (3) repliker som ska skapas och kräver att port 80 är öppen i containern. Resursbegäranden och -gränser definieras också för CPU och minne.

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 filen kör nginx-avbildningen från Docker Hub.
.spec.replicas Anger hur många poddar som ska skapas. Den här filen 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. Den här gränsen tillämpas av kubelet.
.spec.spec.resources.limits.cpu Anger den maximala mängden tillåtna processorer. Den här gränsen tillämpas av kubelet.
.spec.spec.resources.limits.memory Anger den maximala mängden minne som tillåts. Den här gränsen tillämpas av kubelet.

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

Med Kubernetes Scheduler kör distributionskontrollanten 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:

  • 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 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 avslutning. Namngivningskonventionen, nätverksnamnen och lagringen bevaras när repliker schemaläggs om med en StatefulSet.

Definiera programmet i YAML-format med .kind: StatefulSet Därifrån hanterar StatefulSet Controller distributionen och hanteringen av de repliker som krävs. Data skrivs 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.

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 använder du 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-styrenheten kan schemalägga poddar på noder tidigt i klusterstartsprocessen innan kubernetes-standardschemaläggaren har startats. Den här möjligheten säkerställer att poddarna i en DaemonSet startas innan traditionella poddar i en distribution eller StatefulSet schemaläggs.

Precis som StatefulSets definieras en DaemonSet som en del av en YAML-definition med hjälp kind: DaemonSetav .

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 ett namnområde 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 namespaces to logically divide resources and applications

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

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 Används vanligtvis inte, men kan användas 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

Den här artikeln beskriver några av kubernetes-kärnkomponenterna och hur de gäller för AKS-kluster. Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar: