Så här fungerar Kubernetes

Slutförd

En korrekt konfigurerad Kubernetes-installation är beroende av goda kunskaper om systemarkitekturen i Kubernetes. 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 fungera tillsammans och visas som ett enda system. Datorerna som konfigurerats i klustret hanterar samma typer av uppgifter. De är till exempel värdar för webbplatser eller API:er, eller så kör de beräkningsintensiva arbeten.

Ett kluster använder centraliserad programvara som ansvarar för schemaläggning och styrning av de här uppgifterna. Datorerna i ett kluster som kör uppgifter kallas noder, och datorerna som kör schemaläggningsprogramvaran kallas för kontrollplan.

Kubernetes-arkitektur

Som vi sett tidigare är en initierare 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 dirigerings- och klusterprogramvara för att distribuera dina appar och svara på ändringar i beräkningsresursernas behov.

Ett Kubernetes-kluster innehåller minst ett kontrollplan och en eller flera noder. Både kontrollplan- och nodinstanserna kan vara fysiska enheter, virtuella datorer eller instanser i molnet. Standardvärdet för värdoperativsystemet i Kubernetes är Linux, med standardstöd för Linux-baserade arbetsbelastningar.

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 köras endast på noder som kör ett Windows Server-operativsystem.

Titta nu på både kontrollplan och arbetsnoder och den programvara som körs på var och en mer i detalj. Att förstå rollen för varje komponent och var varje komponent körs i klustret hjälper dig när det är dags att installera Kubernetes.

Kubernetes kontrollplan

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

Ur ett utbildningsperspektiv är det klokt att använda ett enda kontrollplan i din testmiljö när du utforskar Kubernetes-funktionerna. 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.

Kommentar

Det faktum att ett kontrollplan kör en särskild programvara för att bibehålla klustrets tillstånd utesluter inte att det även kör andra arbetsbelastningar. Oftast vill du dock inte att kontrollplanet kör icke-kritiska arbetsbelastningar eller användarappar.

Kubernetes-nod

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

Tjänster som körs på ett kontrollplan

Kubernetes använder sig av 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
• Lagringsenhet
• Scheduler
• Kontrollanthanteraren
• Molnkontrollanthanteraren

Vad är API-servern?

Du kan se API-servern som klientdelen till kubernetes-klustrets kontrollplan. All kommunikation mellan komponenterna i Kubernetes sker via detta API.

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 detta API kallas för kube-apiserver. Du kan distribuera flera instanser av komponenten för att stödja skalning i klustret.

Detta API exponerar ett RESTful-API som gör att du kan publicera kommandon eller YAML-baserade konfigurationsfiler. YAML är en läsbar standard för dataserialisering 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 verifierar konfigurationen, sparar den i klustret och genomför slutligen den konfigurerade ökningen av appdistributioner.

Vad är lagringsenheten?

Lagringsplatsen är en beständig lagringsplats där Kubernetes-klustret sparar sin slutförda konfiguration. Kubernetes använder ett distribuerat och tillförlitligt nyckel/värde-lager med hög tillgänglighet som kallas etcd. Nyckel/värde-lagret lagrar det aktuella samt det önskade tillståndet för alla objekt i klustret.

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

Kommentar

etcd ansvarar inte för säkerhetskopiering av data. Det är ditt ansvar att se till att det finns en effektiv säkerhetskopieringsplan 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 att hitta nyligen skapade containrar och tilldelar dem till noder.

Vad är kontrollanthanteraren?

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 kontrollant körs i en icke-avslutande loop medan du tittar på 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 bestämmer 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 tre containrar alltid körs schemaläggs en ny container för körning.

Vad är molnkontrollanthanteraren?

Molnkontrollanthanteraren integreras med den underliggande molntekniken i klustret när klustret körs i en molnmiljö. Exempel på sådana tjänster är 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 en agent 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 de containrar som schemalagts på varje nod körs som förväntat. Kubelet hanterar endast containrar som Kubernetes skapar. Den ansvarar inte för att ändra schemaläggningen för jobb så att de körs på andra noder om den aktuella noden inte kan köra jobbet.

Vad är kube-proxy?

Kube-proxykomponenten ansvarar för lokala klusternätverk och körs på varje nod. Den ser till att varje nod har en unik IP-adress. Den implementerar dessutom regler för hantering av routning och belastningsutjämning av trafik med hjälp av iptables och IPVS.

Den här proxyn tillhandahåller inte själva DNS-tjänsterna. Ett DNS-klustertillägg som baseras på CoreDNS rekommenderas och installeras som standard.

Vad är containerkörningen?

Containerkörningen är den underliggande programvara som kör containrar i ett Kubernetes-kluster. Körningen ansvarar för att hämta, starta och stoppa containeravbildningar. 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 containerkörningstyper baseras på CRI (Container Runtime Interface). CRI är en plugin-design som gör att kubelet kan kommunicera med den tillgängliga containerkörningen.

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

Interagera med ett Kubernetes-kluster

Kubernetes tillhandahå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:

• Konfigurationen Kluster anger ett klusternamn, certifikatinformation och service API-slutpunkten som är associerad med klustret. Med den här definitionen kan du ansluta från en enskild arbetsstation till flera kluster.
• Konfigurationen Användare anger användare och deras behörighetsnivåer för åtkomst till de konfigurerade klustren.
• Kontextkonfiguration grupperar kluster och användare med hjälp av ett eget namn. Du kan till exempel ha ett ”utv-kluster” och ett ”prod-kluster” för att identifiera dina utvecklings- respektive 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 enskild 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 Docker-miljöer kan du inte köra containrar direkt i Kubernetes. Du paketerar containern i ett Kubernetes-objekt som kallas för en podd. En podd är det minsta objekt du kan skapa i Kubernetes.

En enskild podd kan innehålla en grupp med en eller flera containrar. Däremot innehåller en podd oftast inte flera instanser 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 de poddar som körs i klustret. Poddmallar är YAML-kodade filer som du återanvänder och inkluderar i andra objekt för att hantera poddistributioner.

Anta till exempel att du vill distribuera en webbplats till ett Kubernetes-kluster. Du skapar poddefinitionsfilen som anger appens containeravbildningar och konfiguration. Sedan distribuerar du poddefinitionsfilen till Kubernetes.

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

Anta att din webbplats använder en databas. Här är webbplatsen paketerad i huvudcontainern och databasen är paketerad i stödcontainern. 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 en sandbox-miljö som tillhandahåller alla dessa tjänster till din app. Podden gör också att containrarna kan dela dess 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.

Livscykeln för en Kubernetes-podd

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

Det här är faserna i en podds livscykel:

Fas	beskrivning
Väntande	Podden accepterar klustret, men alla containrar i klustret är inte konfigurerade eller redo att köras. Statusen Väntar anger den tid som en podd väntar på att schemaläggas och hur lång tid det går att ladda ned containeravbildningar.
Körs	Podden övergår till ett körningstillstånd när alla resurser i en podd är klara.
Slutfördes	Podden övergår till ett slutfört tillstånd när podden har slutfört sin avsedda aktivitet och körts.
Misslyckades	Poddar kan misslyckas av olika skäl. 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 misslyckat tillstånd från antingen ett väntande tillstånd eller ett körningstillstånd. Ett specifikt fel kan också försätta en podd i väntande tillstånd igen.
Okänt	Om poddens tillstånd inte kan fastställas är podden i ett okänt tillstånd.

Poddar behålls 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 är inte en exakt kopia, så den skiljer sig från den borttagna podden.

Klustret sparar inte poddens tillstånd eller dynamiskt tilldelade konfiguration. Poddens ID eller IP-adress sparas till exempel inte. 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.

Container-tillstånd

Tänk på att faserna är en sammanfattning av var podden befinner sig i sin livscykel. När du inspekterar poddar finns det tre tillstånd som klustret använder för att spåra dina containrar inuti podden:

Stat/län	beskrivning
Väntar	Standardtillståndet för en container och det tillstånd som containern är i när den inte körs eller avslutas.
Körs	Containern körs som förväntat utan problem.
Avslutad	Containern körs inte längre. Orsaken är att alla uppgifter har avslutats eller att containern har misslyckats av någon anledning. I båda fallen genereras en orsaks- och slutkod för felsökning.