Så här fungerar Kubernetes-distributioner
Drönarspårningsappen har flera komponenter som distribueras separat från varandra. Din uppgift är 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.
Distributionsalternativ för poddar
Det finns flera alternativ för att hantera distributionen av poddar i ett Kubernetes-kluster när du använder kubectl. Alternativen är:
- Poddmallar
- Replikeringsstyrenheter
- Replikuppsättningar
- Distributioner
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 avsedda tillstånd som ska distribueras.
Vad är en poddmall?
Med en poddmall kan du definiera konfigurationen för den podd 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 till att distribuera poddar manuellt. En manuellt distribuerad podd startas dock inte om på nytt när den slutar fungera, tas bort eller avslutas. Om du vill hantera livscykeln för en podd 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 säkerställer 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 slutar fungera, tas bort eller avslutas.
Anta till exempel att du distribuerar drönarspårningens klientdelswebbplats och att användarna börjar komma åt webbplatsen. Om alla poddar slutar fungera av någon anledning är webbplatsen inte tillgänglig för dina användare om du inte startar nya poddar. En replikeringskontrollant hjälper dig att se till att webbplatsen alltid är tillgänglig.
Vad är en replikuppsättning?
En replikuppsättning ersätter replikeringskontrollanten 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 den. Med den här funktionen kan du hantera poddar som märkts med samma värde som väljarvärdet, men som inte skapats med replikuppsä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.
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 de äldre appversionspoddarna. Löpande uppdateringar startar en podd i taget i stället för att ta bort alla äldre poddar samtidigt. Distributioner använder antalet repliker som konfigurerats i avsnittet med information om replikuppsättningar. Det underhåller antalet poddar som anges i replikuppsättningen eftersom det ersätter gamla poddar med nya poddar.
Distributioner innehåller som standard en rullande uppdateringsstrategi för uppdatering av poddar. Du kan också använda en strategi där du återskapar poddar. Den här strategin avslutar poddar innan nya poddar startas.
Distributioner tillhandahåller också en återställningsstrategi som du kan köra med kubectl.
Distributioner använder YAML-baserade definitionsfiler och gör det enkelt att hantera distributioner. Kom ihåg att distributioner gör det möjligt att tillämpa ä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 en praktisk syntax för att skapa en distribution automatiskt när du distribuerar en podd med kommandot kubectl run. Det här kommandot skapar en distribution med den begärda replikuppsättningen och poddar. Däremot skapar kommandot ingen definitionsfil. Det är en bra idé att hantera alla distributioner med distributionsdefinitionsfiler och spåra ändringar med hjälp av ett versionskontrollsystem.
Att tänka på vid distribuering
Kubernetes har särskilda 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 ska exponera dina appar i klusternätverket och lagra 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. Ta nu en titt på de här aspekterna av ett Kubernetes-kluster och hur de påverkar distributionen av appar.
Kubernetes-nätverkstjänster
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.
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.
Som standard kan inte poddar och noder kommunicera med varandra med olika IP-adressintervall.
För att göra saken ännu mer komplicerad är poddar tillfälliga, som vi såg tidigare. Poddens IP-adress är temporär 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 så att:
- poddar kan kommunicera med varandra mellan noder utan NAT (Network Address Translation)
- Noder kan kommunicera med alla poddar och tvärtom 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. Några exempel är Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T och Weave Net.
Molnleverantörer kan också tillhandahålla egna nätverkslösningar. Till exempel har Azure Kubernetes Service (AKS) stöd för containernätverksgränssnittet Azure Virtual Network, Kubenet, Flannel, Cilium och Antrea.
Kubernetes-tjänster
En Kubernetes-tjänst är ett Kubernetes-objekt som ger stabila nätverkstjänster för poddar. En Kubernetes-tjänst möjliggör kommunikation mellan noder, poddar och användare i appen, både interna och externa, i klustret.
Kubernetes tilldelar en tjänst en IP-adress när tjänsten skapas, på samma sätt som med 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änstens namn, samt 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.
Tjänsterna för den minnesinterna cachen och meddelandekön är tillgängliga för klientdelen och 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 cacheminnet och databehandlingstjä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.
| Tjänst | Beskrivning |
|---|---|
| ClusterIP | Den adress som är tilldelad en tjänst och som gör tjänsten tillgänglig för en uppsättning tjänster i klustret. Till exempel kommunikation mellan klient- 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å den podd som du vill exponera. Du kan till exempel konfigurera port 80 på den podd som kör en av klientdelarna. Du kan nu komma åt klientdelen via en nod-IP-adress och en portadress. |
| LoadBalancer | Lastbalanseraren fördelar belastningen mellan de noder som kör din app och exponerar podden för offentlig nätverksåtkomst. Vanligtvis konfigurerar du 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 appen. |
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.
Så här grupperar du poddar
Det är inte praktiskt att hantera poddar efter IP-adress. Poddarnas IP-adress ändras när kontrollanter återskapar dem, och du kan ha valfritt antal poddar igång samtidigt.
Med ett tjänstobjekt kan du rikta och hantera specifika poddar i klustret med hjälp av väljaretiketter. Du ställer in väljaretiketten i en tjänstdefinition så att den matchar poddetiketten som definierats i poddens definitionsfil.
Anta till exempel att du har många poddar som körs. Endast några av dessa poddar finns på klientdelen, och du vill ange en LoadBalancer-tjänst som endast riktar sig mot klientdelens poddar. Du kan använda tjänsten för att exponera dessa poddar genom att referera till poddetiketten som ett väljarvä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 med hjälp av dess matchande etikett.
Kubernetes-lagring
I Kubernetes används samma koncept för lagringsvolym som i Docker. Docker-volymer hanteras mindre än Kubernetes-volymerna eftersom Docker-volymens livslängd inte hanteras. Kubernetes-volymens omfång är ett explicit omfång som matchar poddens omfång. Denna omfångsmatchning innebär att en volym räcker längre än de containrar som körs i podden. Om podden tas bort gör dock även volymen det.
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å att båda dessa alternativ finns när du distribuerar appkomponenter som kräver beständig lagring, som 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:
- Mellanprogram
- Ramverk för databearbetning
- Databaser
- Cachelagring
- 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.
I en molnmiljö som Azure bör du 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 den minnesinterna cachelagringen, Azure Service Bus-meddelandefunktionen för meddelandekön och Azure Cosmos DB för NoSQL-databasen.