Så här fungerar Kubernetes

Slutförd

En korrekt konfigurerad Kubernetes-installation beror på en gedigen förståelse för Kubernetes-systemarkitekturen. Här tittar du på alla komponenter som utgör en Kubernetes-installation.

Vad är ett datorkluster?

Ett kluster är en uppsättning datorer som du konfigurerar för att arbeta tillsammans och visa som ett enda system. Datorerna som konfigurerats i klustret hanterar samma typer av uppgifter. De kommer till exempel alla att vara värdar för webbplatser, API:er eller köra beräkningsintensivt arbete.

Ett kluster använder centraliserad programvara som ansvarar för att schemalägga och kontrollera dessa uppgifter. Datorerna i ett kluster som kör uppgifterna kallas noderoch datorerna som kör schemaläggningsprogramvaran kallas kontroll plan.

Kubernetes-arkitektur

Kom ihåg att en orkestrerare är ett system som distribuerar och hanterar appar. Du har också lärt dig att ett kluster är en uppsättning datorer som fungerar tillsammans och visas som ett enda system. Du använder Kubernetes som orkestrerings- och klusterprogramvara för att distribuera dina appar och svara på ändringar i beräkningsresursbehov.

Ett Kubernetes-kluster innehåller minst ett huvudplan och en eller flera noder. Både kontrollplan och nodinstanser kan vara fysiska enheter, virtuella datorer eller instanser i molnet. Standardvärden för operativsystem i Kubernetes är Linux, med standardstöd för Linux-baserade arbeten.

Du kan också köra Microsoft-arbetsbelastningar med hjälp av Windows Server 2019 eller senare på klusternoder. Anta till exempel att databehandlingstjänsten i drönarspårningsappen är skriven som en .NET 4.5-app som använder specifika Windows OS API-anrop. Den här tjänsten kan bara köras på noder som kör ett Windows Server-operativsystem.

Nu ska vi titta närmare på både kontrollplan och arbetsnoder och den programvara som körs på var och en. Att förstå rollen för varje komponent och var varje komponent körs i klustret hjälper dig när det gäller att installera Kubernetes.

Kubernetes-kontrollplan

Kubernetes-kontrollplanet i ett Kubernetes-kluster kör en samling tjänster som hanterar orkestreringsfunktionerna i Kubernetes.

Ur ett inlärningsperspektiv är det klokt att använda ett enda kontrollplan i testmiljön när du utforskar Kubernetes-funktioner. I produktions- och molndistributioner som Azure Kubernetes Service (AKS) upptäcker du dock att den föredragna konfigurationen är en distribution med hög tillgänglighet med tre till fem replikerade kontrollplan.

Not

Det faktum att ett kontrollplan kör specifik programvara för att underhålla klustrets tillstånd utesluter inte att det kör andra beräkningsarbetsbelastningar. Du vill vanligtvis dock undanta kontrollplanet från att köra icke-kritiska och användarapplikationers arbetsbelastningar.

Kubernetes-nod

En nod i ett Kubernetes-kluster är den plats där dina beräkningsarbetsbelastningar körs. Varje nod kommunicerar med kontrollplanet via API-servern för att informera den om tillståndsändringar på noden.

Tjänster som körs på ett kontrollplan

Kubernetes förlitar sig på flera administrativa tjänster som körs på kontrollplanet. Dessa tjänster hanterar aspekter som klusterkomponentkommunikation, schemaläggning av arbetsbelastningar och beständighet i klustertillstånd.

Följande tjänster utgör ett Kubernetes-klusters kontrollplan:

• API-server
• Lagringsplats för säkerhetskopiering
• Schemaläggare
• Styrenhetshanterare
• Molnstyrenhetshanterare

Vad är API-servern?

Du kan se API-servern som klientdelen till kubernetes-klustrets kontrollplan. All kommunikation mellan komponenterna i Kubernetes sker via det här API:et.

Som användare använder du till exempel en kommandoradsapp med namnet kubectl som gör att du kan köra kommandon mot Kubernetes-klustrets API-server. Komponenten som tillhandahåller det här API:et kallas kube-apiserveroch du kan distribuera flera instanser av den här komponenten för att stödja skalning i klustret.

Det här API:et exponerar ett RESTful-API som du kan använda för att publicera kommandon eller YAML-baserade konfigurationsfiler. YAML är en humanläsbar data serialiseringsstandard för programmeringsspråk. Du använder YAML-filer för att definiera det avsedda tillståndet för alla objekt i ett Kubernetes-kluster.

Anta till exempel att du vill öka antalet instanser av din app i klustret. Du definierar det nya tillståndet med en YAML-baserad fil och skickar den här filen till API-servern. API-servern validerar konfigurationen, sparar den i klustret och genomför slutligen den konfigurerade ökningen av appdistributioner.

Vad är backningsbutiken?

Bakgrundslagringen är en beständig lagringsplats där ditt Kubernetes-kluster lagrar den sparade konfigurationen. Kubernetes använder en nyckelvärdesbutik med hög tillgänglighet, distribuerad och tillförlitlig som kallas etcd. Det här nyckelvärdesarkivet lagrar aktuellt tillstånd och önskat tillstånd för alla objekt i klustret.

I ett Kubernetes-produktionskluster är den officiella Kubernetes-vägledningen att ha tre till fem replikerade instanser av etcd-databasen för hög tillgänglighet.

Observera

etcd ansvarar inte för säkerhetskopiering av data. Det är ditt ansvar att se till att en effektiv säkerhetskopieringsplan finns på plats för att säkerhetskopiera etcd data.

Vad är schemaläggaren?

Schemaläggaren är den komponent som ansvarar för tilldelningen av arbetsbelastningar över alla noder. Schemaläggaren övervakar klustret för nyligen skapade containrar och tilldelar dem till noder.

Vad är kontrollhanteraren?

Kontrollanthanteraren startar och övervakar de kontrollanter som konfigurerats för ett kluster via API-servern.

Kubernetes använder kontrollanter för att spåra objekttillstånd i klustret. Varje kontroller körs i en icke-avslutande loop medan den övervakar och svarar på händelser i klustret. Det finns till exempel kontrollanter för att övervaka noder, containrar och slutpunkter.

Kontrollanten kommunicerar med API-servern för att fastställa objektets tillstånd. Om det aktuella tillståndet skiljer sig från objektets önskade tillstånd vidtar kontrollanten åtgärder för att säkerställa det önskade tillståndet.

Anta att en av tre containrar som körs i klustret slutar svara och misslyckas. I det här fallet avgör en kontrollant om du behöver starta nya containrar för att säkerställa att dina appar alltid är tillgängliga. Om det önskade tillståndet är att ha tre containrar igång hela tiden, schemaläggs en ny container att köras.

Vad är molnstyrenhetshanteraren?

Molnstyrenhetshanteraren integreras med de underliggande molnteknikerna i klustret när klustret körs i en molnmiljö. Dessa tjänster kan till exempel vara lastbalanserare, köer och lagring.

Tjänster som körs på en nod

Det finns flera tjänster som körs på en Kubernetes-nod för att styra hur arbetsbelastningar körs.

Följande tjänster körs på Kubernetes-noden:

• Kubelet
• Kube-proxy
• Containerkörning

Vad är kubelet?

Kubelet är agenten som körs på varje nod i klustret och övervakar arbetsbegäranden från API-servern. Den ser till att den begärda arbetsenheten körs och är felfri.

Kubelet övervakar noderna och ser till att containrarna som schemalagts på varje nod körs som förväntat. Kubelet hanterar endast containrar som Kubernetes skapar. Det är inte ansvarigt för att omplanera arbete som ska köras på andra noder om den aktuella noden inte kan köra arbetet.

Vad är kube-proxy?

Kube-proxykomponenten ansvarar för lokala klusternätverk och körs på varje nod. Det säkerställer att varje nod har en unik IP-adress. Den implementerar också regler för att hantera routning och belastningsutjämning av trafik med hjälp av iptables och IPVS.

Den här proxyn tillhandahåller inte DNS-tjänster på egen hand. Ett DNS-klustertillägg baserat på CoreDNS rekommenderas och installeras som standard.

Vad är en container-runtime?

Container-runtime är den underliggande programvaran som kör containerar på ett Kubernetes-kluster. Körtiden ansvarar för att hämta, starta och stoppa containerbilder. Kubernetes stöder flera containerkörningar, inklusive men inte begränsat till Docker, containerd, rkt, CRI-O och frakti. Stödet för många typer av containerkörningar baseras på CRI (Container Runtime Interface). CRI är en insticksmodul som gör det möjligt för kubelet att kommunicera med det tillgängliga containersystemet.

Standardcontainerkörningen i AKS är containerbaserad, en containerkörning av branschstandard.

Interagera med ett Kubernetes-kluster

Kubernetes innehåller ett kommandoradsverktyg som heter kubectl för att hantera klustret. Du använder kubectl för att skicka kommandon till klustrets kontrollplan eller hämta information om alla Kubernetes-objekt via API-servern.

kubectl använder en konfigurationsfil som innehåller följande konfigurationsinformation:

• Kluster konfiguration anger ett klusternamn, certifikatinformation och tjänst-API-slutpunkten som är associerad med klustret. Med den här definitionen kan du ansluta från en enskild arbetsstation till flera kluster.
• User configuration anger användarna och deras behörighetsnivåer när de kommer åt de konfigurerade klustren.
• Kontext konfigurerar grupper, kluster och användare med hjälp av ett vänligt namn. Du kan till exempel ha ett "dev-cluster" och ett "prod-cluster" för att identifiera dina utvecklings- och produktionskluster.

Du kan konfigurera kubectl att ansluta till flera kluster genom att ange rätt kontext som en del av kommandoradssyntaxen.

Kubernetes-poddar

En podd representerar en enda instans av en app som körs i Kubernetes. De arbetsbelastningar som du kör i Kubernetes är containerbaserade appar. Till skillnad från i en Docker-miljö kan du inte köra containrar direkt på Kubernetes. Du paketerar containern i ett Kubernetes-objekt som kallas för en podd. En podd är det minsta objekt som du kan skapa i Kubernetes.

En enda pod kan rymma en grupp med en eller flera containrar. En podd innehåller dock vanligtvis inte multiplar av samma app.

En podd innehåller information om den delade lagrings- och nätverkskonfigurationen och en specifikation om hur du kör dess paketerade containrar. Du använder poddmallar för att definiera informationen om poddarna som körs i klustret. Poddmallar är YAML-kodade filer som du återanvänder och inkluderar i andra objekt för att hantera podddistributioner.

Anta till exempel att du vill distribuera en webbplats till ett Kubernetes-kluster. Du skapar podddefinitionsfilen som anger appens containeravbildningar och konfiguration. Därefter distribuerar du podddefinitionsfilen till Kubernetes.

Det är osannolikt att en webbapp har en webbplats som den enda komponenten i lösningen. En webbapp har vanligtvis någon form av datalager och andra stödelement. Kubernetes-poddar kan också innehålla mer än en container.

Anta att webbplatsen använder en databas. Webbplatsen är paketerad i huvudcontainern och databasen paketeras i den stödjande containern. Flera containrar kommunicerar med varandra via en miljö. Containrarna innehåller tjänster för ett värdoperativsystem, en nätverksstack, ett kernelnamnområde, delat minne och en lagringsvolym. Podden är sandbox-miljön som tillhandahåller alla dessa tjänster till din app. Podden gör det också möjligt för containrarna att dela sin tilldelade IP-adress.

Eftersom du kan skapa många poddar som körs på många noder kan det vara svårt att identifiera dem. Du kan identifiera och gruppera poddar med hjälp av strängetiketter som du anger när du definierar en podd.

Livscykel för en Kubernetes-podd

Kubernetes-poddar har en distinkt livscykel som påverkar hur du distribuerar, kör och uppdaterar poddar. Du börjar med att skicka YAML-poddmanifestet till klustret. När manifestfilen har skickats och sparats i klustret definierar den poddens önskade tillstånd. Schemaläggaren schemalägger podden till en hälsosam nod som har tillräckligt med resurser för att köra podden.

Här är faserna i en podds livscykel:

Fas	Beskrivning
Avvaktan	Podden accepterar klustret, men alla containrar i klustret är inte konfigurerade eller redo att köras. Statusen Pågående anger den tid som en podd väntar på att schemaläggas och tiden som krävs för att ladda ner containeravbildningar.
Löpning	Podden övergår till ett körtillstånd efter att alla resurser i podden är redo.
Lyckades	Podden övergår till ett slutfört tillstånd efter att ha slutfört sin avsedda uppgift och kört framgångsrikt.
Misslyckades	Poddar kan misslyckas av olika orsaker. En container i podden kan misslyckas, vilket leder till att alla andra containrar avslutas, eller så hittades kanske inte en avbildning under förberedelsen av poddcontainrarna. I dessa typer av fall kan podden gå till ett feltillstånd. Poddar kan övergå till ett feltillstånd från antingen ett väntande tillstånd eller ett tillstånd som körs. Ett specifikt fel kan också göra att en podd hamnar i ett väntande tillstånd igen.
Okänd	Om poddens tillstånd inte kan fastställas är podden i ett okänt tillstånd.

Poddar sparas i ett kluster tills en kontrollant, kontrollplanet eller en användare uttryckligen tar bort dem. När en podd tas bort skapas en ny podd omedelbart efter. Den nya podden anses vara en helt ny instans baserad på poddmanifestet. Det är inte en exakt kopia, så den skiljer sig från den borttagna podden.

Klustret sparar inte poddens tillstånd eller dynamiskt tilldelade konfiguration. Den sparar till exempel inte poddens ID eller IP-adress. Den här aspekten påverkar hur du distribuerar poddar och hur du utformar dina appar. Du kan till exempel inte förlita dig på förtilldelade IP-adresser för dina poddar.

Containertillstånd

Tänk på att faserna är en sammanfattning av var podden befinner sig i sin livscykel. När du inspekterar en pod använder klustret tre tillstånd för att spåra containrar i poden.

Stat	Beskrivning
Väntan	Standardtillstånd för en container och det tillstånd containern befinner sig i när den inte körs eller avslutas.
Löpning	Containern körs som förväntat utan problem.
Avslutad	Containern körs inte längre. Anledningen är att antingen alla aktiviteter har slutförts eller att containern av någon anledning misslyckades. Det finns en orsaks- och slutkod för felsökning av båda fallen.