Naarmate u steeds meer Kubernetes-services gaat maken, worden taken die aanvankelijk eenvoudig waren steeds complexer. Ontwikkelteams kunnen bijvoorbeeld geen services of implementaties onder dezelfde naam maken. Als je duizenden pods hebt, kost het simpelweg opsommen ervan veel tijd, laat staan het correct beheren ervan. En dit is nog maar het topje van de ijsberg.
Laten we eens kijken hoe de naamruimte het eenvoudiger maakt om Kubernetes-resources te beheren. Dus wat is een naamruimte? Naamruimte kan worden gezien als een virtueel cluster binnen uw Kubernetes-cluster. U kunt meerdere naamruimten van elkaar geïsoleerd hebben binnen één Kubernetes-cluster. Ze kunnen u en uw teams echt helpen met de organisatie, beveiliging en zelfs systeemprestaties.
Op de meeste Kubernetes-distributies wordt het cluster standaard geleverd met een naamruimte met de naam 'default'. Er zijn eigenlijk drie naamruimten waarmee Kubernetes te maken heeft: standaard, kube-system en kube-public. Momenteel wordt Kube-public nog niet zo vaak gebruikt.
Het is een goed idee om de kube-naamruimte met rust te laten, vooral op een beheerd systeem zoals Google Kubernetes Engine. Het gebruikt de "standaard" naamruimte als de plaats waar uw services en applicaties worden gemaakt. Er is absoluut niets bijzonders aan, behalve dat Kubernetes kant-en-klaar is geconfigureerd om het te gebruiken, en je het niet kunt verwijderen. Dit is geweldig om aan de slag te gaan en voor systemen met lage prestaties, maar ik zou het gebruik van de standaardnaamruimte op grote productiesystemen niet aanraden. In het laatste geval kan het ene ontwikkelteam gemakkelijk de code van iemand anders herschrijven en het werk van een ander team kapot maken zonder het zelfs maar te beseffen.
Daarom moet u meerdere naamruimten maken en deze gebruiken om uw services in beheersbare eenheden te segmenteren. Met één enkele opdracht kan een naamruimte worden gemaakt. Als u een naamruimte met de naam test wilt maken, gebruikt u de opdracht $ kubectl create namespace test of maakt u eenvoudigweg een YAML-bestand en gebruikt u dit zoals elke andere Kubernetes-bron.
U kunt alle naamruimten bekijken met de opdracht $ kubectl get namespace.
Zodra het klaar is, zie je drie ingebouwde naamruimten en een nieuwe naamruimte genaamd "test". Laten we eens kijken naar een eenvoudig YAML-bestand om een pod te maken. U zult merken dat er geen sprake is van naamruimte.
Als u kubectl gebruikt om dit bestand uit te voeren, wordt de mypod-module gemaakt in de momenteel actieve naamruimte. Dit zal de standaardnaamruimte zijn totdat u deze wijzigt. Er zijn twee manieren om Kubernetes te vertellen in welke naamruimte u uw resource wilt maken. De eerste manier is om een naamruimtevlag te gebruiken bij het maken van een resource.
De tweede manier is om de naamruimte op te geven in de YAML-declaratie.
Als u een naamruimte opgeeft in YAML, wordt de resource altijd in die naamruimte gemaakt. Als u een andere naamruimte probeert te gebruiken terwijl u de naamruimtevlag gebruikt, mislukt de opdracht. Als u nu uw pod probeert te vinden, zult u dat niet kunnen doen.
Dit gebeurt omdat alle opdrachten worden uitgevoerd buiten de momenteel actieve naamruimte. Om je pod te vinden, moet je een naamruimtevlag gebruiken, maar dit wordt snel saai, vooral als je een ontwikkelaar bent in een team dat zijn eigen naamruimte gebruikt en die vlag niet voor elk afzonderlijk commando wil gebruiken. Laten we kijken hoe we dit kunnen oplossen.
Standaard wordt uw actieve naamruimte standaard genoemd. Als u geen naamruimte opgeeft in de bron-YAML, gebruiken alle Kubernetes-opdrachten deze actieve standaardnaamruimte. Helaas kan het proberen de actieve naamruimte te beheren met kubectl mislukken. Er is echter een zeer goede tool genaamd Kubens die dit proces veel eenvoudiger maakt. Wanneer u de opdracht kubens uitvoert, ziet u alle naamruimten waarbij de actieve naamruimte is gemarkeerd.
Om de actieve naamruimte naar de testnaamruimte te schakelen, voert u eenvoudigweg de opdracht $kubens test uit. Als u vervolgens het commando $kubens opnieuw uitvoert, zult u zien dat er nu een nieuwe actieve naamruimte is toegewezen: test.
Dit betekent dat u de naamruimtevlag niet nodig hebt om de pod in de testnaamruimte te zien.
Op deze manier zijn de naamruimten voor elkaar verborgen, maar niet van elkaar geïsoleerd. Een service in de ene naamruimte kan vrij eenvoudig communiceren met een service in een andere naamruimte, wat vaak erg handig is. De mogelijkheid om tussen verschillende naamruimten te communiceren betekent dat de service van uw ontwikkelaars kan communiceren met de service van een ander ontwikkelteam in een andere naamruimte.
Wanneer uw applicatie toegang wil krijgen tot een Kubernetes-service, gebruikt u doorgaans de ingebouwde DNS-detectieservice en geeft u uw applicatie eenvoudigweg de naam van de service. Door dit te doen kunt u echter een service onder dezelfde naam in meerdere naamruimten maken, wat niet acceptabel is.
Gelukkig is dit eenvoudig te omzeilen door de uitgebreide vorm van het DNS-adres te gebruiken. Services in Kubernetes maken hun eindpunten zichtbaar met behulp van een gemeenschappelijke DNS-sjabloon. Het ziet er ongeveer zo uit:
Normaal gesproken hebt u alleen de servicenaam nodig en bepaalt DNS automatisch het volledige adres.
Als u echter toegang wilt krijgen tot een service in een andere naamruimte, gebruikt u eenvoudigweg de servicenaam plus de naamruimtenaam:
Als u bijvoorbeeld verbinding wilt maken met een servicedatabase in een testnaamruimte, kunt u de adresdatabase database.test gebruiken
Als u verbinding wilt maken met de servicedatabase in de prod-naamruimte, gebruikt u database.prod.
Als u de toegang tot de naamruimte echt wilt isoleren en beperken, kunt u met Kubernetes dit doen met behulp van Kubernetes Network Policies. Hierover zal ik het hebben in de volgende aflevering.
Vaak wordt mij de vraag gesteld: hoeveel namespaces moet ik aanmaken en met welk doel? Wat is een beheerd stukje data?
Als u te veel naamruimten maakt, staan ze u alleen maar in de weg. Als er te weinig zijn, verliest u alle voordelen van een dergelijke oplossing. Ik denk dat er vier hoofdfasen zijn die elk bedrijf doorloopt bij het creëren van zijn organisatiestructuur. Afhankelijk van de ontwikkelingsfase waarin uw project of bedrijf zich bevindt, wilt u wellicht een geschikte naamruimtestrategie hanteren.
Stel je voor dat je deel uitmaakt van een klein team dat werkt aan de ontwikkeling van 5-10 microservices en dat je gemakkelijk alle ontwikkelaars in één ruimte kunt verzamelen. In deze situatie is het zinvol om alle prod-services in de standaardnaamruimte uit te voeren. Voor meer flexibiliteit kunt u uiteraard twee naamruimten gebruiken - afzonderlijk voor prod en dev. En hoogstwaarschijnlijk test u uw ontwikkeling op uw lokale computer met behulp van zoiets als Minikube.
Laten we zeggen dat de dingen veranderen en dat u nu een snelgroeiend team heeft dat aan meer dan tien microservices tegelijk werkt. Er komt een moment dat het nodig is om meerdere clusters of naamruimten te gebruiken, afzonderlijk voor prod en dev. U kunt het team opdelen in verschillende subteams, zodat elk van hen zijn eigen microservices heeft en elk van deze teams zijn eigen naamruimte kan kiezen om het proces van het beheren van softwareontwikkeling en -release te vergemakkelijken.
Naarmate elk teamlid inzicht krijgt in hoe het systeem als geheel werkt, wordt het steeds moeilijker om elke verandering met alle andere ontwikkelaars te coördineren. Het wordt elke dag moeilijker om een volledige stapel op je lokale machine te draaien.
Bij grote bedrijven weten ontwikkelaars doorgaans niet wie waar precies aan werkt. Teams communiceren via servicecontracten of maken gebruik van service mesh-technologie, die een abstractielaag over het netwerk toevoegt, zoals de Istio-configuratietool. Proberen om een hele stapel lokaal te draaien is simpelweg niet mogelijk. Ik raad ten zeerste aan om een continu leveringsplatform (CD) zoals Spinnaker op Kubernetes te gebruiken. Er komt dus een punt waarop elke opdracht beslist een eigen naamruimte nodig heeft. Elk team kan zelfs meerdere naamruimten kiezen voor de ontwikkelomgeving en de productieomgeving.
Ten slotte zijn er grote ondernemende bedrijven waarin de ene groep ontwikkelaars niet eens op de hoogte is van het bestaan van andere groepen. Zo'n bedrijf kan over het algemeen externe ontwikkelaars inhuren die ermee communiceren via goed gedocumenteerde API's. Elke groep bevat verschillende teams en verschillende microservices. In dit geval moet je alle tools gebruiken waar ik het eerder over had.
Programmeurs mogen services niet handmatig implementeren en mogen geen toegang hebben tot naamruimten die hen niet aangaan. In dit stadium is het raadzaam om meerdere clusters te hebben om de “explosieradius” van slecht geconfigureerde applicaties te verkleinen, om factureringsprocessen en resourcebeheer te vereenvoudigen.
Door het juiste gebruik van naamruimten door uw organisatie kunt u Kubernetes beter beheersbaar, controleerbaar, veilig en flexibel maken.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com