Så här fungerar Kubernetes-distributioner

  • 10 minuter

Drönarspårningsappen har flera komponenter som distribueras separat från varandra. Det är ditt jobb att konfigurera distributioner för dessa komponenter i klustret. Här tittar du på några av de distributionsalternativ som är tillgängliga för att distribuera dessa komponenter.

Diagram över den övergripande arkitekturen som visar komponenterna för drönarspårningslösningen.

Implementeringsalternativ för pods

Det finns flera alternativ för att hantera distributionen av poddar i ett Kubernetes-kluster när du använder kubectl. Alternativen är:

  • Pod-mallar
  • Replikeringskontroller
  • Replikuppsättningar
  • Utrullningar

Du kan använda någon av dessa fyra Kubernetes-objekttypsdefinitioner för att distribuera en podd eller poddar. Dessa filer använder YAML för att beskriva poddens eller poddarnas önskade tillstånd för distribution.

Vad är en poddmall?

Med en poddmall kan du definiera konfigurationen av den podd som du vill distribuera. Mallen innehåller information som namnet på containeravbildningen och vilket containerregister som ska användas för att hämta avbildningarna. Mallen innehåller även information om körningskonfiguration, till exempel portar som ska användas. Mallar definieras med YAML på samma sätt som när du skapar Docker-filer.

Du kan använda mallar för att distribuera poddar manuellt. En manuellt distribuerad podd startas dock inte om när den misslyckas, tas bort eller avslutas. För att hantera en podds livscykel måste du skapa ett Kubernetes-objekt på högre nivå.

Vad är en replikeringskontrollant?

En replikeringskontrollant använder poddmallar och definierar ett angivet antal poddar som måste köras. Kontrollanten hjälper dig att köra flera instanser av samma podd och ser till att poddar alltid körs på en eller flera noder i klustret. Kontrollanten ersätter poddar som körs på det här sättet med nya poddar om de misslyckas, tas bort eller avslutas.

Anta till exempel att du lanserar front-end-webbplatsen för drönarspårning och att användarna börjar använda webbplatsen. Om alla poddar av någon anledning misslyckas är webbplatsen inte tillgänglig för användarna om du inte startar nya poddar. En replikeringskontrollant hjälper dig att se till att din webbplats alltid är tillgänglig.

Vad är en replikuppsättning?

En replikuppsättning ersätter replikeringsstyrenheten som det bästa sättet att distribuera repliker. En replikuppsättning innehåller samma funktioner som en replikeringskontrollant, men den har ett extra konfigurationsalternativ för att inkludera ett väljarevärde.

Med en väljare kan replikuppsättningen identifiera alla poddar som körs under dess kontroll. Med den här funktionen kan du hantera poddar som är märkta med samma värde som väljarens värde, men som inte har skapats med den replikerade uppsättningen.

Vad är en distribution?

En distribution skapar ett hanteringsobjekt på en nivå som är högre än en replikuppsättning och gör att du kan distribuera och hantera uppdateringar för poddar i ett kluster.

Anta att du har fem instanser av din app distribuerade i klustret. Det finns fem poddar som kör version 1.0.0 av din app.

diagram som visar fem poddar som körs på en nod med samma poddversion.

Om du bestämmer dig för att uppdatera appen manuellt kan du ta bort alla poddar och sedan starta nya poddar som kör version 2.0.0 av appen. Med den här strategin upplever din app stilleståndstid.

I stället vill du köra en löpande uppdatering där du startar poddar med den nya versionen av appen innan du tar bort poddarna med den äldre appversionen. Löpande uppdateringar startar en podd i taget i stället för att ta bort alla äldre poddar samtidigt. Distributioner respekterar antalet repliker som konfigurerats i avsnittet som beskriver information om replikuppsättningar. Det upprätthåller det antal poddar som anges i replikuppsättningen genom att byta ut gamla mot nya.

diagram som visar fem poddar, två poddar som anges som version 1 och tre poddar som anges som version 2.

Deployment, som standard, tillhandahåller en löpande uppdateringsstrategi för att uppdatera poddar. Du kan också använda en ny strategi. Den här strategin avslutar poddar innan nya poddar startas.

Utrullningar ger dig också en återställningsstrategi som du kan köra med hjälp av kubectl.

Distributioner använder YAML-baserade definitionsfiler och gör det enkelt att hantera distributioner. Tänk på att distributioner gör att du kan tillämpa alla ändringar i klustret. Du kan till exempel distribuera nya versioner av en app, uppdatera etiketter och köra andra repliker av dina poddar.

kubectl har praktisk syntax för att skapa en distribution automatiskt när du använder kommandot kubectl run för att distribuera en podd. Det här kommandot skapar en distribution med den nödvändiga replikuppsättningen och podar. Kommandot skapar dock ingen definitionsfil. Det är bästa praxis att hantera alla distributioner med distributionsdefinitionsfiler och spåra ändringar med hjälp av ett versionskontrollsystem.

Distributionsöverväganden

Kubernetes har specifika krav på hur du konfigurerar nätverk och lagring för ett kluster. Hur du konfigurerar dessa två aspekter påverkar dina beslut om hur du exponerar dina appar i klusternätverket och lagrar data.

Till exempel har var och en av tjänsterna i drönarspårningsappen specifika krav för användaråtkomst, nätverksåtkomst mellan processer och datalagring. Nu ska vi ta en titt på dessa Kubernetes-klusteraspekter och hur de påverkar distributionen av appar.

Kubernetes-nätverk

Anta att du har ett kluster med ett kontrollplan och två noder. När du lägger till noder i Kubernetes tilldelas en IP-adress automatiskt till varje nod från ett internt privat nätverksintervall. Anta till exempel att ditt lokala nätverksintervall är 192.168.1.0/24.

diagram över noder med tilldelade IP-adresser i ett kluster.

Varje podd som du distribuerar tilldelas en IP-adress från en pool med IP-adresser. Anta till exempel att konfigurationen använder nätverksintervallet 10.32.0.0/12, som följande bild visar.

Diagram över noder och poddar med tilldelade IP-adresser i ett kluster.

Poddar och noder kan som standard inte kommunicera med varandra med hjälp av olika IP-adressintervall.

För att ytterligare komplicera saker och ting, kom ihåg att kapslar är tillfälliga. Poddens IP-adress är tillfällig och kan inte användas för att återansluta till en nyligen skapad podd. Den här konfigurationen påverkar hur din app kommunicerar med sina interna komponenter och hur du och tjänsterna interagerar med den externt.

För att förenkla kommunikationen förväntar sig Kubernetes att du konfigurerar nätverk på ett sådant sätt att:

  • Poddar kan kommunicera med varandra mellan noder utan NAT (Network Address Translation).
  • Noder kan kommunicera med alla poddar och vice versa utan NAT.
  • Agenter på en nod kan kommunicera med alla noder och poddar.

Kubernetes erbjuder flera nätverksalternativ som du kan installera för att konfigurera nätverk. Exempel är Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T och Weave Net.

Molnleverantörer tillhandahåller också egna nätverkslösningar. Azure Kubernetes Service (AKS) stöder till exempel Azure Virtual Network Container Network Interface (CNI), Kubenet, Flannel, Cilium och Antrea.

Kubernetes-tjänster

En Kubernetes-tjänst är ett Kubernetes-objekt som tillhandahåller stabilt nätverk för poddar. En Kubernetes-tjänst möjliggör kommunikation mellan noder, poddar och användare av din app (både interna och externa) till klustret.

Kubernetes tilldelar en tjänst en IP-adress när den skapas, precis som en nod eller podd. Dessa adresser tilldelas från ett tjänstklusters IP-intervall. till exempel 10.96.0.0/12. En tjänst tilldelas också ett DNS-namn baserat på tjänstnamnet och en IP-port.

I drönarspårningsappen är nätverkskommunikationen följande:

  • Webbplatsen och RESTful-API:et är tillgängliga för användare utanför klustret.

  • Cache- och meddelandekötjänsterna i minnet är tillgängliga för klientdelen respektive RESTful-API:et, men inte för externa användare.

  • Meddelandekön behöver åtkomst till databehandlingstjänsten, men inte till externa användare.

  • NoSQL-databasen är tillgänglig för minnesintern cache och databearbetningstjänsten, men inte för externa användare.

För att stödja dessa scenarier kan du konfigurera tre typer av tjänster för att exponera appens komponenter.

Service Beskrivning
ClusterIP Adressen som tilldelats till en tjänst som gör tjänsten tillgänglig för en uppsättning tjänster i klustret. Till exempel kommunikation mellan klientdels- och serverdelskomponenterna i din app.
NodePort Nodporten mellan 30000 och 32767 som Kubernetes-kontrollplanet tilldelar tjänsten. till exempel 192.169.1.11 på kluster01. Sedan konfigurerar du tjänsten med en målport på podden som du vill exponera. Konfigurera till exempel port 80 på podden som kör en av frontändarna. Nu kan du komma åt klientdelen via en nod-IP- och portadress.
Lastbalanserare Lastbalanseraren som möjliggör distribution av belastning mellan noder som kör din app och exponerar podden för offentlig nätverksåtkomst. Du konfigurerar vanligtvis lastbalanserare när du använder molnleverantörer. I det här fallet dirigeras trafik från den externa lastbalanseraren till de poddar som kör din app.

I drönarspårningsappen kan du välja att exponera spårningswebbplatsen och RESTful-API:et med hjälp av en LoadBalancer och databehandlingstjänsten med hjälp av en ClusterIP.

Gruppera poddar

Det är inte praktiskt att hantera poddar efter IP-adress. Podd-IP-adresser ändras när kontrollanter återskapar dem, och du kan ha valfritt antal poddar som körs.

diagram över en tjänst med väljareetiketter.

Med ett tjänstobjekt kan du rikta in dig på och hantera specifika poddar i klustret med hjälp av väljareetiketter. Du anger etiketten för selektorn i en servicedefinition så att den matchar podetiketten som är definierad i poddens definitionsfil.

Anta till exempel att du har många körande pods. Endast ett fåtal av dessa pods finns i front-end, och du vill ställa in en LoadBalancer-tjänst som riktar sig endast mot front-end-poddarna. Du kan använda din tjänst för att exponera dessa poddar genom att referera till poddetiketten som ett väljarevärde i tjänstens definitionsfil. Tjänsten grupperar endast de poddar som matchar etiketten. Om en podd tas bort och återskapas läggs den nya podden automatiskt till i tjänstgruppen via dess matchande etikett.

Kubernetes lagring

Kubernetes använder samma koncept för lagringsvolym som du hittar när du använder Docker. Docker-volymer hanteras mindre än Kubernetes-volymerna eftersom Docker-volymens livslängd inte hanteras. Livslängden för en Kubernetes-volym är en uttryckt livslängd som överensstämmer med poddens livslängd. Den här livslängdsmatchningen innebär att en volym överlever de containrar som körs i podden. Men om podden tas bort, försvinner också volymen.

diagram över en tjänst med väljareetiketter igen.

Kubernetes tillhandahåller alternativ för att etablera beständig lagring med hjälp av PersistentVolumes. Du kan också begära specifik lagring för poddar med hjälp av PersistentVolumeClaims.

Tänk på båda dessa alternativ när du distribuerar appkomponenter som kräver sparad lagring, till exempel meddelandeköer och databaser.

Överväganden för molnintegrering

Kubernetes dikterar inte vilken teknikstack du använder i din molnbaserade app. I en molnmiljö som Azure kan du använda flera tjänster utanför Kubernetes-klustret.

Kom ihåg att Kubernetes inte tillhandahåller någon av följande tjänster:

  • Middleware (mellanprogram)
  • Ramverk för databehandling
  • Databaser
  • Cachar
  • Klusterlagringssystem

I den här drönarspårningslösningen finns det tre tjänster som tillhandahåller mellanprogramsfunktioner: en NoSQL-databas, en minnesintern cachetjänst och en meddelandekö. Du kan välja MongoDB Atlas som NoSQL-lösning, Redis för att hantera minnesintern cache och RabbitMQ eller Kafka beroende på dina behov av meddelandeköer.

När du använder en molnmiljö som Azure är det bästa praxis att använda tjänster utanför Kubernetes-klustret. Det här beslutet kan förenkla klustrets konfiguration och hantering. Du kan till exempel använda Azure Cache for Redis- för cachelagringstjänster i minnet, Azure Service Bus-meddelanden för meddelandekön och Azure Cosmos DB- för NoSQL-databasen.