Grundläggande kubernetes-begrepp för Azure Kubernetes Service (AKS)
Programutvecklingen fortsätter att gå mot en containerbaserad metod, vilket ökar behovet av att orkestrera och hantera resurser. Som ledande plattform 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 introducerar:
- Kärnkomponenter för Kubernetes-infrastruktur:
- kontrollplan
- Noder
- nodpooler
- Arbetsbelastningsresurser:
- Skida
- Distributioner
- Uppsättningar
- Så här grupperar du resurser i namnrymder.
Vad är Kubernetes?
Kubernetes är en plattform som utvecklas snabbt och som hanterar containerbaserade program och deras associerade 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 stöder både tillståndslösa och tillståndslösa program allt eftersom teamen går vidare med att införa mikrotjänstbaserade program.
Som en öppen plattform kan du med Kubernetes skapa program med önskat programmeringsspråk, operativsystem, bibliotek eller meddelandebuss. Befintliga CI/CD-verktyg (kontinuerlig integrering och kontinuerlig leverans) kan integreras med Kubernetes för att schemalägga och distribuera versioner.
AKS tillhandahåller en hanterad Kubernetes-tjänst som minskar komplexiteten i distribution och viktiga hanteringsuppgifter, till exempel uppgraderingssamordning. Azure-plattformen hanterar AKS-kontrollplanet och du betalar bara för de AKS-noder som kör dina program. AKS bygger på den öppna källkoden Azure Kubernetes Service Engine: aks-engine.
Kubernetes-klusterarkitektur
Ett Kubernetes-kluster är indelat i två komponenter:
- Kontrollplan: tillhandahåller Grundläggande Kubernetes-tjänster och orkestrering av programarbetsbelastningar.
- Noder: Kör dina programarbetsbelastningar.

Kontrollplan
När du skapar ett AKS-kluster skapas och konfigureras ett kontrollplan automatiskt. Det här kontrollplanet tillhandahålls utan kostnad som en hanterad Azure-resurs som abstraheras från användaren. Du betalar bara för noderna 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 Grundläggande Kubernetes-komponenter:
| Komponent | Beskrivning |
|---|---|
| kube-apiserver | API-servern är hur de underliggande Kubernetes-API:erna exponeras. Den här komponenten ger interaktion för hanteringsverktyg, till exempel kubectl eller Kubernetes-instrumentpanelen. |
| etcd | För att upprätthålla tillståndet för ditt Kubernetes-kluster och konfiguration är etcd med hög tillgänglig kapacitet ett nyckelvärdeslager i Kubernetes. |
| kube-scheduler | När du skapar eller skalar program avgör Scheduler vilka noder som kan köra arbetsbelastningen och startar dem. |
| kube-controller-manager | Kontrollanthanteraren övervakar ett antal mindre styrenheter som utför åtgärder som att replikera poddar och hantera nodåtgärder. |
AKS tillhandahåller ett kontrollplan för en enda klient 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.
Även om du inte behöver konfigurera komponenter (t.ex. en butik med hög tillgänglighet osv.) med det här hanterade kontrollplanet kan du inte komma åt kontrollplanet direkt. Kubernetes-kontrollplans- och noduppgraderingar dirigeras via Azure CLI eller Azure Portal. Om du vill felsöka möjliga problem kan du granska kontrollplansloggarna via Azure Monitor loggar.
Om du vill konfigurera eller få direkt åtkomst till ett kontrollplan distribuerar du ett eget Kubernetes-kluster med aks-engine.
Tillhörande metodtips finns i Metodtips för klustersäkerhet och uppgraderingar i 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 och schemaläggning av att köra 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. |
| container runtime | Gör att program i containrar kan köras och interagera med ytterligare resurser, till exempel det virtuella nätverket och lagringen. AKS-kluster som använder Kubernetes version 1.19+ för Linux-nodpooler containerd använder som containerkörning. Från och med Kubernetes version 1.20 för Windows-nodpooler kan användas som förhandsversion för containerkörningen, men Docker är fortfarande containerd standardcontainerkörningen. AKS-kluster som använder tidigare versioner av Kubernetes för nodpooler använder Docker som containerkörning. |

Storleken på den virtuella Azure-datorn för dina noder definierar lagringsprocessorer, minne, storlek och typ som är tillgängliga (till exempel högpresterande SSD eller vanlig HÅRDDISK). Planera nodstorleken kring huruvida dina program kan kräva stora mängder cpu och minne eller lagring med höga prestanda. Skala ut antalet noder i ditt AKS-kluster för att möta efterfrågan.
I AKS baseras VM-avbildningen för klustrets noder på Ubuntu 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 debiteras som standard-VM:ar, så eventuella rabatter för VM-storlek (inklusive Azure-reservationer)tillämpas automatiskt.
Distribuera ditt eget Kubernetes-kluster med aks-engine om du använder ett annat värdoperativsystem, containerkörning eller inkluderar olika anpassade paket. De överordnade aks-engine versionerna innehåller funktioner och konfigurationsalternativ i förväg för stöd i AKS-kluster. Om du vill använda en annan containerkörning än eller Docker kan du köra för att konfigurera och distribuera ett containerd aks-engine Kubernetes-kluster som uppfyller dina aktuella behov.
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 tillgängliga resurserna i AKS. Kom ihåg den här informationen när du ställer in begäranden och begränsningar för användar distribuerade poddar.
Om du vill hitta en nods allaocatable resurser kör du:
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ändar distribuerade poddar.
Anteckning
Om du använder AKS-tillägg som Container Insights (OMS) förbrukas ytterligare nodresurser.
Två typer av resurser är reserverade:
Processor
Reserverad processor är beroende av nodtyp och klusterkonfiguration, vilket kan orsaka mindre allocatable CPU på grund av att ytterligare funktioner körs.PROCESSORkärnor på värden 1 2 4 8 16 32 64 Kube-reserverad (cores) 60 100 140 180 260 420 740 Minne
Minne som används av AKS innehåller summan av två värden.kubeletDaemon
kubeletDaemonen installeras på alla Kubernetes-agentnoder för att hantera skapande och avslutning av containrar.Som standard i AKS har
kubeletdaemon regeln memory.available<750Mi eviction, vilket säkerställer att en nod alltid måste ha minst 750 Mi allocatable hela tiden. När en värd är lägre än tröskelvärdet för tillgängligt minne utlöses en av poddarna som körs och frigörkubeletminne på värddatorn.En regreressiv frekvens av minnesreservationer för kubelet-daemonen så att den fungerar korrekt (kube-reserved).
- 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 nästa 112 GB minne (upp till 128 GB)
- 2 % av allt minne över 128 GB
Regler för minnes- och CPU-allokering:
- Håll agentnoderna felfria, inklusive vissa värdsystempoddar som är viktiga för klusterhälsan.
- Gör så att noden rapporterar mindre alltocatable minne och CPU än den skulle göra om den inte var en del av ett Kubernetes-kluster.
Det går inte att ändra resursreservationer ovan.
Om en nod till exempel erbjuder 7 GB rapporterar den 34 % av minnet som inte kan användas, inklusive tröskelvärdet för 750Mi-hård avlägsning.
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.
Associerade metodtips finns i Metodtips för grundläggande schemafunktioner i AKS.
Nodpooler
Noder i samma konfiguration grupperas tillsammans i nodpooler. Ett Kubernetes-kluster innehåller minst en nodpool. Det första antalet noder och storlek definieras 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 agentnoderna.
Anteckning
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 och hantera flera nodpooler för ett kluster i AKS.
Nodväljare
I ett AKS-kluster med flera nodpooler kan du behöva berätta för Kubernetes Scheduler vilken nodpool som ska användas för en viss resurs. Ingress-kontrollanter 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 schemaläggs finns i Metodtips för avancerade schemaläggarfunktioner i AKS.
Skida
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 att containrar delar relaterade resurser.
När du skapar en podd kan du definiera resursbegäranden för att begära en viss mängd PROCESSOR- eller minnesresurser. Kubernetes Scheduler försöker uppfylla begäran genom att schemalägga poddarna att köras på en nod med tillgängliga resurser. Du kan också ange högsta 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-poddlivscykeln.
En podd är en logisk resurs, men programarbetsbelastningar körs på containrarna. Poddar är vanligtvis tillfälliga, engångsresurser. Individuellt schemalagda poddar saknar några av Kubernetes-funktionerna med hög tillgänglighet och redundans. I stället distribueras och hanteras poddar av Kubernetes Controllers, till exempel distributionsstyrenheten.
Distributioner och YAML-manifest
En distribution representerar identiska poddar som hanteras av Kubernetes Deployment Controller. 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, containeravbildningar som används eller ansluten lagring. Distributionsstyrenheten:
- 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 antal repliker som krävs körs i klustret. När poddar schemaläggs individuellt startas de inte om de stöter på problem, och de 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 poddavbrott 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 poddavbrott på 4 (fyra) så att endast en replik kan tas bort eller omplaneras åt gången. Precis som med resursbegränsningar för poddar är bästa praxis att definiera poddavbrottsbudgetar 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
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 kubernetes-klustret. Mer information finns i Installera befintliga program med Helm i AKS.
StatefulSets och DaemonSets
Med Kubernetes Scheduler kör distributionsstyrenheten 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 distributionsstyrenheten är inte idealisk för program som kräver:
- En beständig namngivningskonvention eller lagring.
- En replik ska finnas på varje nod som markeras i ett kluster.
Med två Kubernetes-resurser kan du dock hantera dessa typer av program:
- StatefulSets upprätthåller programtillståndet utanför en enskild poddlivscykel, till exempel lagring.
- DaemonSets säkerställer att en instans körs på varje nod tidigt i Kubernetes-bootstrap-processen.
TillståndsfulSets
Modern programutveckling syftar ofta till tillståndslösa program. För tillståndsful-program, till exempel 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 bra och sekventiell metod för distribution, skalning, uppgradering och avslutning. Namngivningskonventionen, nätverksnamnen och lagringen bevaras när repliker schemas om med en StatefulSet.
Definiera programmet i YAML-format med hjälp av kind: StatefulSet . Därifrån hanterar StatefulSet-kontrollanten distributionen och hanteringen av de nödvändiga replikerna. 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. Om du vill se till att minst en podd i uppsättningen körs på en nod använder du en DaemonSet i stället.
DaemonSets
För specifik logginsamling eller övervakning kan du behöva köra en podd på alla eller valda noder. Du kan använda DaemonSet-distribution på en eller flera identiska poddar, men DaemonSet-kontrollanten ser till att varje nod som anges kör en instans av podden.
DaemonSet-kontrollanten kan schemalägga poddar på noder tidigt i klusterstartprocessen innan Kubernetes-standardschemat 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 av kind: DaemonSet .
Mer information finns i Kubernetes DaemonSets.
Anteckning
Om du använder tillägget Virtuella noder skaparDaemonSets 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 begränsa skapa, visa eller hantera åtkomst till resurser. Du kan till exempel skapa namnrymder för att separera affärsgrupper. Användare kan bara interagera med resurser inom sina tilldelade namnområden.

När du skapar ett AKS-kluster är följande namnområden tillgängliga:
| Namnområde | Description |
|---|---|
| standard | Där poddar och distributioner skapas som standard när ingen anges. I mindre miljöer kan du distribuera program direkt till standardnamnrymden utan att skapa ytterligare logiska avgränsningar. När du interagerar med Kubernetes-API:et, till exempel med , används kubectl get pods standardnamnrymden 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 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-namnrymder.
Nästa steg
Den här artikeln beskriver några av de viktigaste Kubernetes-komponenterna och hur de gäller för AKS-kluster. Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar: