När du börjar skapa fler och fler Kubernetes-tjänster börjar uppgifter som från början är enkla att bli mer komplexa. Till exempel kan utvecklingsteam inte skapa tjänster eller distributioner under samma namn. Om du har tusentals pods tar det mycket tid att bara lista dem, än mindre att hantera dem korrekt. Och detta är bara toppen av isberget.
Låt oss titta på hur namnutrymmet gör det enklare att hantera Kubernetes-resurser. Så vad är ett namnutrymme? Namnutrymme kan ses som ett virtuellt kluster inom ditt Kubernetes-kluster. Du kan ha flera namnområden isolerade från varandra inom ett enda Kubernetes-kluster. De kan verkligen hjälpa dig och dina team med organisation, säkerhet och till och med systemprestanda.
På de flesta Kubernetes-distributioner kommer klustret ur lådan med ett namnutrymme som kallas "default". Det finns faktiskt tre namnområden som Kubernetes hanterar: standard, kube-system och kube-public. För närvarande används inte Kube-public särskilt ofta.
Att lämna kube-namnutrymmet ensamt är en bra idé, särskilt på ett hanterat system som Google Kubernetes Engine. Den använder namnutrymmet "standard" som platsen där dina tjänster och applikationer skapas. Det finns absolut inget speciellt med det, förutom att Kubernetes är konfigurerat direkt för att använda det, och du kan inte ta bort det. Det här är bra för att komma igång och system med låg prestanda, men jag skulle inte rekommendera att använda standardnamnutrymmet på stora prod-system. I det senare fallet kan ett utvecklingsteam enkelt skriva om någon annans kod och bryta ett annat teams arbete utan att ens inse det.
Därför bör du skapa flera namnområden och använda dem för att segmentera dina tjänster i hanterbara enheter. Ett namnområde kan skapas med ett enda kommando. Om du vill skapa ett namnområde med namnet test, använd sedan kommandot $ kubectl skapa namnområdestest eller skapa helt enkelt en YAML-fil och använd den som vilken annan Kubernetes-resurs som helst.
Du kan se alla namnområden med kommandot $ kubectl get namespace.
När det är klart ser du tre inbyggda namnutrymmen och ett nytt namnområde som heter "test". Låt oss titta på en enkel YAML-fil för att skapa en pod. Du kommer att märka att namnutrymmet inte nämns.
Om du använder kubectl för att köra den här filen kommer den att skapa mypod-modulen i det för närvarande aktiva namnområdet. Detta kommer att vara standardnamnutrymmet tills du ändrar det. Det finns två sätt att berätta för Kubernetes vilket namnområde du vill skapa din resurs i. Det första sättet är att använda en namnområdesflagga när du skapar en resurs.
Det andra sättet är att ange namnutrymmet i YAML-deklarationen.
Om du anger ett namnområde i YAML kommer resursen alltid att skapas i det namnområdet. Om du försöker använda ett annat namnområde medan du använder namnområdesflaggan kommer kommandot att misslyckas. Om du nu försöker hitta din pod kommer du inte att kunna göra det.
Detta beror på att alla kommandon exekveras utanför det för närvarande aktiva namnområdet. För att hitta din pod måste du använda en namnområdesflagga, men det här blir snabbt tråkigt, speciellt om du är en utvecklare i ett team som använder sitt eget namnområde och inte vill använda den flaggan för varje enskilt kommando. Låt oss se hur vi kan fixa detta.
Ur lådan kallas ditt aktiva namnutrymme standard. Om du inte anger ett namnområde i resursen YAML kommer alla Kubernetes-kommandon att använda detta aktiva standardnamnutrymme. Tyvärr kan det misslyckas att försöka hantera det aktiva namnutrymmet med kubectl. Det finns dock ett mycket bra verktyg som heter Kubens som gör denna process mycket enklare. När du kör kommandot kubens ser du alla namnområden med det aktiva namnområdet markerat.
För att byta det aktiva namnutrymmet till testnamnområdet, kör du helt enkelt $kubens testkommando. Om du sedan kör kommandot $kubens igen kommer du att se att ett nytt aktivt namnutrymme nu är tilldelat - test.
Det betyder att du inte behöver namnutrymmesflaggan för att se podden i testnamnområdet.
På så sätt är namnområdena dolda från varandra, men inte isolerade från varandra. En tjänst i ett namnområde kan kommunicera ganska enkelt med en tjänst i ett annat namnområde, vilket ofta är mycket användbart. Möjligheten att kommunicera över olika namnområden innebär att dina utvecklares tjänst kan kommunicera med ett annat utvecklarteams tjänst i ett annat namnområde.
Vanligtvis när din applikation vill komma åt en Kubernetes-tjänst använder du den inbyggda DNS-upptäcktstjänsten och ger helt enkelt din applikation namnet på tjänsten. Men genom att göra det kan du skapa en tjänst under samma namn i flera namnområden, vilket inte är acceptabelt.
Lyckligtvis är detta lätt att komma runt genom att använda den utökade formen av DNS-adressen. Tjänster i Kubernetes exponerar sina slutpunkter med hjälp av en gemensam DNS-mall. Det ser ut ungefär så här:
Vanligtvis behöver du bara tjänstens namn och DNS kommer automatiskt att avgöra den fullständiga adressen.
Men om du behöver komma åt en tjänst i ett annat namnområde, använd helt enkelt tjänstens namn plus namnområdets namn:
Om du till exempel vill ansluta till en tjänstedatabas i ett testnamnområde kan du använda adressdatabasen database.test
Om du vill ansluta till tjänstedatabasen i prod-namnområdet använder du database.prod.
Om du verkligen vill isolera och begränsa åtkomsten till namnutrymmet låter Kubernetes dig göra detta med Kubernetes nätverkspolicyer. Jag ska prata om detta i nästa avsnitt.
Jag får ofta frågan, hur många namnutrymmen ska jag skapa och för vilka ändamål? Vad är en hanterad del av data?
Om du skapar för många namnutrymmen kommer de bara att komma i vägen. Om det är för få av dem kommer du att förlora alla fördelar med en sådan lösning. Jag tror att det finns fyra huvudsteg som varje företag går igenom när de skapar sin organisationsstruktur. Beroende på utvecklingsstadiet ditt projekt eller företag befinner sig i, kanske du vill anta en lämplig namnområdesstrategi.
Föreställ dig att du är en del av ett litet team som arbetar med att utveckla 5-10 mikrotjänster och du kan enkelt samla alla utvecklare i ett rum. I den här situationen är det vettigt att köra alla prod-tjänster i standardnamnutrymmet. Naturligtvis, för mer flexibilitet, kan du använda 2 namnområden - separat för prod och dev. Och troligtvis testar du din utveckling på din lokala dator med något som Minikube.
Låt oss säga att saker förändras och att du nu har ett snabbt växande team som arbetar på mer än 10 mikrotjänster åt gången. Det kommer en tid då det är nödvändigt att använda flera kluster eller namnutrymmen, separat för prod och dev. Du kan dela upp teamet i flera underteam så att vart och ett av dem har sina egna mikrotjänster och vart och ett av dessa team kan välja sin egen namnrymd för att underlätta processen för att hantera mjukvaruutveckling och release.
I takt med att varje teammedlem får insikt i hur systemet som helhet fungerar, blir det svårare och svårare att samordna varje förändring med alla andra utvecklare. Att försöka snurra upp en full stack på din lokala maskin blir svårare för varje dag.
I stora företag vet utvecklare i allmänhet inte vem som arbetar med vad. Team kommunicerar med hjälp av servicekontrakt eller använder servicemesh-teknik, som lägger till ett abstraktionsskikt över nätverket, såsom Istio-konfigurationsverktyget. Att försöka köra en hel stack lokalt är helt enkelt inte möjligt.Jag rekommenderar starkt att du använder en plattform för kontinuerlig leverans (CD) som Spinnaker på Kubernetes. Så det kommer en punkt där varje kommando definitivt behöver sitt eget namnutrymme. Varje team kan till och med välja flera namnområden för dev-miljön och prod-miljön.
Slutligen finns det stora entreprenörsföretag där en grupp utvecklare inte ens känner till existensen av andra grupper. Ett sådant företag kan i allmänhet anställa tredjepartsutvecklare som interagerar med det genom väldokumenterade API:er. Varje sådan grupp innehåller flera team och flera mikrotjänster. I det här fallet måste du använda alla verktyg som jag pratade om tidigare.
Programmerare ska inte distribuera tjänster manuellt och ska inte ha tillgång till namnutrymmen som inte berör dem. I detta skede är det tillrådligt att ha flera kluster för att minska "sprängradien" för dåligt konfigurerade applikationer, för att förenkla faktureringsprocesser och resurshantering.
Korrekt användning av namnutrymmen av din organisation gör att du kan göra Kubernetes mer hanterbar, kontrollerbar, säker och flexibel.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com