Bästa praxis för Kubernetes. Organisera Kubernetes med namnrymder

Bästa praxis för Kubernetes. Skapa små containrar

Allteftersom du börjar skapa fler och fler Kubernetes-tjänster blir de enkla uppgifterna mer komplicerade. Till exempel kan utvecklarteam inte skapa tjänster eller distributioner med samma namn. Om du har tusentals pods kan bara uppräkningen av dem ta mycket tid, för att inte tala om att säkerställa korrekt hantering. Och det här är bara toppen av isberget.

Låt oss titta på hur namespaces underlättar hanteringen av Kubernetes-resurser. Så vad är egentligen ett namespace? Ett namespace kan ses som en virtuell kluster inom ditt Kubernetes-kluster. Du kan ha flera isolerade namespaces inom ett och samma Kubernetes-kluster. De kan verkligen hjälpa dig och dina team med organisation, säkerhet och till och med systemets prestanda.

I de flesta Kubernetes-distributioner kommer klustret "out of the box" med ett namespace som kallas "default". Det finns faktiskt tre namespaces som Kubernetes arbetar med: default, kube-system och kube-public. För närvarande används kube-public inte så ofta.

Att lämna kube-namespacet orört är en bra idé, särskilt i ett hanterat system som Google Kubernetes Engine. Det använder namespace "default" som en plats där dina tjänster och applikationer skapas. Det finns ingenting speciellt med det, förutom att Kubernetes är konfigurerat för att använda det "utanför boxen", och du kan inte ta bort det. Det är bra för att komma igång och för system med låg prestanda, men jag skulle inte rekommendera att använda default namespace i stora produktionssystem. I det sista fallet kan ett utvecklarteam lätt skriva över någon annans kod och störa en annan teams arbete utan att ens vara medveten om det.

Därför bör du skapa flera namespaces och använda dem för att segmentera dina tjänster i hanterade enheter. Ett namespace kan skapas med ett enda kommando. Om du vill skapa ett namespace som heter test, använd kommandot $ kubectl create namespace test, eller skapa bara en YAML-fil och använd den som vilken annan Kubernetes-resurs som helst.

Du kan se alla namespaces med kommandot $ kubectl get namespace.

När du har genomfört detta kommer du att se tre inbyggda namnutrymmen och ett nytt namnutrymme som heter "test". Låt oss titta på en enkel YAML-fil avsedd för att skapa en pod. Du kan märka att det inte finns någon hänvisning till namnutrymmet.

Om du använder kubectl för att köra denna fil kommer den att skapa modulen mypod i det aktuella aktiva namnutrymmet. Detta kommer att vara standardnamnutrymmet tills du ändrar det. Det finns två sätt att informera Kubernetes om vilket namnutrymme du vill skapa din resurs i. Det första sättet är att använda flaggan för namnutrymme när du skapar resursen.

Det andra sättet är att ange namnutrymmet i YAML-deklarationen.

Om du anger namnutrymmet i YAML kommer resursen alltid att skapas i detta namnutrymme. Om du försöker använda ett annat namnutrymme med flaggan för namnutrymme kommer kommandot att avslutas med ett fel. Nu, om du försöker hitta din pod, kommer du inte att kunna göra det.

Detta beror på att alla kommandon körs utanför det aktuella aktiva namnutrymmet. För att hitta din pod måste du använda flaggan för namnutrymme, men det blir snabbt tröttsamt, särskilt om du arbetar som utvecklare i en grupp som använder sitt eget namnutrymme och inte vill använda en sådan flagga för varje enskilt kommando. Låt oss se hur detta kan lösas.

Som standard heter ditt aktiva namnutrymme default. Om du inte specificerar namnutrymme i resursens YAML kommer alla Kubernetes-kommandon att använda detta aktiva default namespace. Tyvärr kan försök att hantera det aktiva namnutrymmet med kubectl misslyckas. Men det finns ett mycket bra verktyg som heter Kubens, vilket förenklar denna process avsevärt. När du kör kommandot kubens ser du alla namnutrymmen med det aktiva namnutrymmet markerat.

För att byta det aktiva namnutrymmet till namnutrymmet test kör du helt enkelt kommandot $ kubens test. Om du sedan skriver in kommandot $ kubens igen kommer du att se att det nu markerade nya aktiva namnutrymmet är – test.

Det innebär att du inte behöver ett namnrymdsflagga för att se pod i namnrymden test.

Således är namnrymder dolda för varandra, men de är inte isolerade från varandra. En tjänst från en namnrymd kan ganska enkelt kommunicera med en tjänst i en annan namnrymd, vilket ofta är mycket användbart. Möjligheten till kommunikation mellan olika namnrymder innebär att din utvecklargrupps tjänst kan interagera med en tjänst från en annan utvecklingsteam i en annan namnrymd.

Vanligtvis, när din applikation vill få åtkomst till en Kubernetes-tjänst, använder du den inbyggda DNS-upptäckten och anger helt enkelt tjänstens namn för din applikation. Men du kan skapa en tjänst med samma namn i flera namnrymder, vilket inte är tillåtet.

Lyckligtvis är det enkelt att kringgå detta genom att använda det utvidgade formatet för DNS-adresser. Tjänster i Kubernetes exponerar sina slutpunkter med hjälp av ett gemensamt DNS-mönster. Det ser ungefär ut så här:

I allmänhet behöver du bara tjänstens namn, och DNS kommer automatiskt att bestämma den fullständiga adressen.

Men om du behöver få åtkomst till en tjänst i en annan namnrymnd, använd helt enkelt tjänstens namn plus namnrymden:

Till exempel, om du vill ansluta till databasens tjänst i testnamnrymden kan du använda adressen database.test.

Om du istället vill ansluta till databasens tjänst i produktionsnamnrymden använder du database.prod.

Om du verkligen vill isolera och begränsa åtkomst till namnrymden, låter Kubernetes dig göra det med hjälp av Kubernetes nätverkspolicyer. Mer om detta kommer jag att berätta i nästa del.

Jag får ofta frågan hur många namnrymder man ska skapa och i vilka syften? Vad innebär en förvaltad datasegment?

Om du skapar för många namnruvar kommer de bara att stå i vägen för dig. Om det däremot finns för få namnruvar förlorar du alla fördelar med en sådan lösning. Jag tror att det finns fyra grundläggande steg som varje företag går igenom i processen att skapa sin organisatoriska struktur. Beroende på den utvecklingsfas som ditt projekt eller företag befinner sig i kan du tillämpa en lämplig strategi för att skapa namnrum.

Föreställ dig att du är en del av ett litet team som arbetar med att utveckla 5-10 mikrotjänster och du lätt kan samla alla utvecklare i ett rum. I denna situation är det meningsfullt att starta alla prod-tjänster i namnrymden default. Självklart kan du för större handlingsutrymme använda 2 namnrum - ett för prod och ett för dev. Och det är troligt att du testar din utveckling på din lokala dator med hjälp av något som Minikube.

Anta att omständigheterna har förändrats och nu har du ett snabbt växande team som samtidigt arbetar med fler än 10 mikrotjänster. Det kommer en tid då det är nödvändigt att använda flera kluster eller namnrum, separerade för prod och dev. Teamet kan delas in i flera undergrupper så att varje grupp har sina egna mikrotjänster och var och en av dessa grupper kan välja sitt eget namnrum för att underlätta hanteringen av utveckling och programvaruleverans.

I takt med att varje medlem i teamet får en uppfattning om hur systemet fungerar som helhet blir det allt svårare att koordinera varje förändring med alla andra utvecklare. Att försöka rulla ut hela stacken på din lokala dator blir svårare för varje dag.

I stora företag vet inte utvecklarna vem som arbetar med vad. Team kommunicerar genom serviceavtal eller använder teknologin Service mesh, som lägger till en abstraktionsnivå ovanpå nätverket, typ konfigurationsverktyget Istio. Att försöka köra hela stacken lokalt är helt enkelt omöjligt. Jag rekommenderar starkt att använda en plattform för kontinuerlig leverans (CD) som Spinnaker i Kubernetes. Så, det kommer en tid när varje team definitivt behöver sitt eget namnrum. Varje team kan till och med välja flera namnrum för utvecklings- och produktionsmiljöer.

Slutligen finns det stora företagsorganisationer där en grupp utvecklare inte ens känner till andra gruppers existens. Ett sådant företag kan till och med anställa externa utvecklare som kommunicerar genom väl dokumenterade API:er. I varje sådan grupp finns det flera team och flera mikrotjänster. I det här fallet är det nödvändigt att använda alla verktyg jag talade om tidigare.

Programmerare ska inte manuellt distribuera tjänster och ska inte ha tillgång till namnrum som inte berör dem. I det här skedet är det lämpligt att ha flera kluster för att minska "explosionsradien" av dåligt konfigurerade applikationer, för att förenkla faktureringsprocesser och resursförvaltning.

Således gör rätt användning av namnrum i din organisation Kubernetes mer hanterbart, kontrollerat, säkert och flexibelt.

Bästa praxis för Kubernetes. Kontroll av Kubernetes livskraft med hjälp av Readiness- och Liveness-tester

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com