Vad är Kubernetes?

Vad är Kubernetes? Och vad är dess arkitektur?

Containerization har klippt kabeln mellan mjukvaruutvecklare och produktionsmiljön. Inte i den meningen att du inte alls behöver ett produktionssystem, men du behöver inte oroa dig för produktionsmiljön.

Apparna är nu buntade med beroenden som de behöver, i en lätt behållare istället för en virtuell dator. Det är toppen! Det ger dock inte immunitet mot systemfel, nätverksfel eller diskfel. Till exempel, om datacentret, där dina servrar körs, är under underhåll kommer din applikation att gå offline.

Kubernetes kommer in i bilden för att lösa dessa problem. Det tar tanken på containrar och utökar den till att fungera över flera beräkningsnoder (som kan vara molnvärd virtuell maskin eller bare metal-servrar). Tanken är att ha ett distribuerat system för containeriserade applikationer att köras på.

Varför Kubernetes?

Nu, varför skulle du behöva ha en distribuerad miljö i första hand?

Av flera skäl är först och främst hög tillgänglighet. Du vill att din e-handelswebbplats ska vara online 24/7, eller förlorar affärer, använd Kubernetes för det. För det andra är skalbarhet, där du vill skala ut. Att skala ut här innebär att du lägger till fler beräkningsnoder för att ge din växande applikation mer benutrymme att använda.

Design och arkitektur

Som alla distribuerade system har ett Kubernetes-kluster en huvudnod och sedan en hel del arbetarnoder vilket är där dina applikationer faktiskt skulle köras. Master är ansvarig för att schemalägga uppgifter, hantera arbetsbelastningar och lägga till nya noder på ett säkert sätt i klustret.

Nu kan naturligtvis själva masternoden misslyckas och ta hela klustret med sig, så Kubernetes låter dig faktiskt ha flera masternoder för redundans skull.

En fågelperspektiv av en typisk Kubernetes-utplacering

Kubernetes Master

Kubernetes-mästaren är vad DevOps-teamet interagerar med och använder för att tillhandahålla nya noder, distribuera nya appar och resursövervakning och hantering. Huvudnodens mest grundläggande uppgift är att schema arbetsbördan effektivt bland alla arbetarnoder för att maximera resursutnyttjandet, förbättra prestanda och följa olika policyer som DevOps-teamet har valt för deras specifika arbetsbelastning.

En annan viktig komponent är etcd vilket är en demon som håller reda på arbetarnoder och håller en databas som lagrar hela klusterns tillstånd. Det är ett datalager med nyckelvärde, som också kan köras i en distribuerad miljö över flera huvudnoder. Innehållet i etcd ger all relevant information om hela klustret. En arbetarnod tittar då och då på innehållet i etcd för att avgöra hur den ska bete sig.

Kontroller är den enhet som skulle ta instruktioner från API-servern (som vi kommer att täcka senare) och utföra nödvändiga åtgärder som att skapa, radera och uppdatera applikationer och paket.

De API-server avslöjar Kubernetes API, som använder JSON-nyttolaster över HTTPS, för att kommunicera med användargränssnittet som utvecklargrupperna eller DevOps-personal så småningom skulle sluta interagera med. Både webbgränssnittet och CLI förbrukar detta API för att interagera med Kubernetes-klustret.

API-servern ansvarar också för kommunikationen mellan arbetarnoderna och olika huvudnodkomponenter som etcd.

Huvudnoden exponeras aldrig för slutanvändaren eftersom det skulle riskera säkerheten för hela klustret.

Kubernetes noder

En maskin (fysisk eller virtuell) skulle behöva några viktiga komponenter som en gång har installerats och konfigurerats ordentligt kan sedan göra den servern till en medlem i ditt Kubernetes-kluster.

Det första du behöver är en containerruntid, som Docker, installerad och körs på den. Det kommer självklart att vara ansvarigt för att snurra upp och hantera containrar.

Tillsammans med Docker-körningen behöver vi också Kubelet demon. Den kommunicerar med huvudnoderna via API-servern och frågar etcd och ger tillbaka hälso- och användningsinformation om de pods som körs på den noden.

Men containrar är ganska begränsade av sig själva, så Kubernetes har en högre abstraktion byggd ovanpå en samling containrar, känd som Skida.

Varför komma med skida??

Docker har en policy att köra en applikation per container. Ofta beskrivs som “En process per container” politik. Detta innebär att om du behöver en WordPress-webbplats uppmuntras du att ha två behållare för databasen att köras på och en annan för webbservern att köra på. Att samla sådana relaterade komponenter i en applikation i en pod säkerställer att när du skala ut, kommer de två interberoende behållarna alltid att samexistera på samma nod och därmed prata med varandra snabbt och enkelt.

Pods är den grundläggande distributionsenheten i Kubernetes. När du skala ut lägger du till fler pods i klustret. Varje pod får sin egen unika IP-adress inom klustrets interna nätverk.

Tillbaka till Kubernetes-noden

Nu kan en nod köra flera pods och det kan finnas många sådana noder. Allt är bra tills du funderar på att försöka kommunicera med den yttre världen. Om du har en enkel webbaserad tjänst, hur skulle du rikta ditt domännamn till denna samling pods med många IP-adresser??

Du kan inte, och du behöver inte! Kube-proxy är den sista biten i pusslet som gör det möjligt för operatörer att exponera vissa pods för Internet. Till exempel kan din front-end göras tillgänglig för allmänheten och kube-proxy skulle distribuera trafiken mellan alla olika pods som är ansvariga för hosting av frontend. Din databas behöver dock inte offentliggöras och kube-proxy tillåter endast intern kommunikation för sådana backend-relaterade arbetsbelastningar.

Behöver du allt detta?

Om du precis börjat som hobbyist eller student, skulle det faktiskt vara ineffektivt att använda Kubernetes för en enkel applikation. Hela rigmarolen skulle förbruka mer resurser än din faktiska applikation och skulle ge mer förvirring för en enskild individ.

Men om du ska arbeta med ett stort team och distribuera dina appar för seriös kommersiell användning, är Kubernetes värt tilläggskostnaden. Du kan hindra saker från att bli kaotiska. Gör utrymme för underhåll utan stillestånd. Ställ in snygga A / B-testförhållanden och skala ut gradvis utan att spendera för mycket på infrastrukturen.