Naarmate je steeds meer Kubernetes-diensten begint te creƫren, worden de aanvankelijk eenvoudige taken complexer. Bijvoorbeeld, ontwikkelteams kunnen geen services of deployments met dezelfde naam maken. Als je duizenden pods hebt, kost het veel tijd om ze simpelweg op te sommen, om nog maar te zwijgen over het adequaat beheren ervan. En dit is nog maar het topje van de ijsberg.
Laten we eens bekijken hoe een namespace het beheer van Kubernetes-resources vergemakkelijkt. Dus, wat is een namespace? Een namespace kan worden gezien als een virtuele cluster binnen je Kubernetes-cluster. Je kunt verschillende onderling geĆÆsoleerde namespaces hebben binnen Ć©Ć©n Kubernetes-cluster. Ze kunnen je en je teams echt helpen met organisatie, beveiliging en zelfs systeemprestaties.
In de meeste Kubernetes-distributies komt een cluster 'out of the box' met een namespace genaamd 'default'. In feite zijn er drie namespaces waarmee Kubernetes omgaat: default, kube-system en kube-public. Tegenwoordig wordt kube-public niet zo vaak gebruikt.
Het is een goed idee om de namespace kube met rust te laten, vooral in een beheerd systeem zoals Google Kubernetes Engine. Het gebruikt de namespace 'default' als plek waar je services en applicaties worden aangemaakt. Er is verder niets bijzonders aan, behalve dat Kubernetes 'out of the box' is ingesteld om het te gebruiken, en je kunt het niet verwijderen. Dit is prima voor de start en voor systemen met beperkte prestaties, maar ik zou niet aanraden de default namespace te gebruiken in grote productiesystemen. In dat geval kan Ć©Ć©n ontwikkelteam eenvoudig de code van iemand anders overschrijven en de werking van een ander team verstoren, zonder zich daarvan bewust te zijn.
Daarom is het raadzaam om meerdere namespaces te creƫren en deze te gebruiken om je diensten in beheerde segmenten te segmenteren. Je kunt een namespace aanmaken met ƩƩn commando. Als je een namespace met de naam test wilt aanmaken, gebruik dan het commando $ kubectl create namespace test of maak gewoon een YAML-bestand en gebruik het zoals elk ander Kubernetes-resource.
Je kunt alle namespaces bekijken met het commando $ kubectl get namespace.
Na het uitvoeren ziet u drie ingebouwde namespaces en een nieuwe namespace genaamd "test". Laten we een eenvoudig YAML-bestand bekijken dat bedoeld is voor het aanmaken van een pod. Het valt op dat er geen vermelding van een namespace in voorkomt.
Als u kubectl gebruikt om dit bestand uit te voeren, zal het de module mypod aanmaken in de huidige actieve namespace. Dit zal de standaardnamespace zijn totdat u deze wijzigt. Er zijn 2 manieren om Kubernetes te laten weten in welke namespace u uw resource wilt aanmaken. De eerste manier is het gebruik van de namespace-vlag bij het aanmaken van de resource.
De tweede manier is om de namespace op te geven in de YAML-declaratie.
Als u een namespace in YAML opgeeft, wordt de resource altijd in deze namespace aangemaakt. Als u probeert een andere namespace te gebruiken met de namespace-vlag, zal de opdracht met een fout eindigen. Nu, als u probeert uw pod te vinden, zult u dat niet kunnen.
Dit gebeurt omdat alle opdrachten buiten de huidige actieve namespace worden uitgevoerd. Om uw pod te vinden, moet u de namespace-vlag gebruiken, maar dat wordt snel vervelend, vooral als u een ontwikkelaar bent in een team dat zijn eigen namespace gebruikt en niet voor elke afzonderlijke opdracht deze vlag wil gebruiken. Laten we eens kijken hoe we dit kunnen oplossen.
Standaard heet uw actieve namespace default. Als u de namespace in de YAML-resource niet specificeert, zullen alle Kubernetes-opdrachten deze actieve default namespace gebruiken. Helaas kan het proberen om de actieve namespace te beheren met kubectl mislukken. Er is echter een zeer goed hulpmiddel genaamd Kubens, dat dit proces aanzienlijk vereenvoudigt. Wanneer u de kubens-opdracht uitvoert, ziet u alle namespaces met de actieve namespace gemarkeerd.
Om de actieve namespace naar de namespace test te schakelen, voert u gewoon de opdracht $ kubens test uit. Als u daarna opnieuw de opdracht $ kubens invoert, ziet u dat nu de nieuwe actieve namespace - test - is gemarkeerd.
Dit betekent dat je geen namespace-vlag nodig hebt om de pod in de namespace test te zien.
Namespaces zijn dus voor elkaar verborgen, maar niet van elkaar geĆÆsoleerd. Een service in de ene namespace kan vrij makkelijk communiceren met een service in een andere namespace, wat vaak zeer nuttig is. De mogelijkheid tot communicatie tussen verschillende namespaces betekent dat de service van jouw ontwikkelaars kan interageren met de service van een ander dev-team in een andere namespace.
Normaal gesproken, wanneer jouw applicatie toegang wil krijgen tot een Kubernetes-service, gebruik je de ingebouwde DNS-service discovery en geef je simpelweg de servicenaam op aan jouw applicatie. Echter, je kunt een service met dezelfde naam in meerdere namespaces creƫren, wat onaanvaardbaar is.
Gelukkig is dit gemakkelijk te omzeilen door de uitgebreide vorm van het DNS-adres te gebruiken. Services binnen Kubernetes tonen hun eindpunten met behulp van een algemeen DNS-sjabloon. Dit ziet er ongeveer zo uit:
Over het algemeen heb je gewoon de servicenaam nodig, en DNS bepaalt automatisch het volledige adres.
Als je echter toegang wilt krijgen tot een service in een andere namespace, gebruik dan gewoon de servicenaam plus de namespace-naam:
Bijvoorbeeld, als je verbinding wilt maken met de database service in de testnamespace, kun je de adresnaam database.test gebruiken.
Als je verbinding wilt maken met de database service in de prod namespace, gebruik je database.prod.
Als je echt toegang tot de namespace wilt isoleren en beperken, stelt Kubernetes je in staat dit te doen met behulp van Kubernetes Network Policies. Hierover vertel ik in de volgende serie.
Ik krijg vaak de vraag, hoeveel namespaces er moeten worden aangemaakt en voor welke doeleinden? Wat is eigenlijk een beheerd gegevensfragment?
Als u te veel namespaces aanmaakt, zullen ze u gewoon in de weg staan. Als er te weinig zijn, verliest u alle voordelen van een dergelijke oplossing. Ik denk dat er vier belangrijke fasen zijn die elke onderneming doorloopt bij het opzetten van haar organisatorische structuur. Afhankelijk van de ontwikkelingsfase waarin uw project of bedrijf zich bevindt, kunt u een passende strategie voor het creƫren van namespaces aannemen.
Stel je voor dat je deel uitmaakt van een klein team dat werkt aan de ontwikkeling van 5-10 microservices en je kunt gemakkelijk alle ontwikkelaars in Ć©Ć©n kamer verzamelen. In deze situatie is het logisch om alle prod-services in de default namespace te draaien. Natuurlijk, voor meer speelruimte kunt u 2 namespaces gebruiken ā apart voor prod en dev. En waarschijnlijk test u uw ontwikkeling op uw lokale computer met iets als Minikube.
Stel dat de omstandigheden zijn veranderd en nu hebt u een snelgroeiend team dat tegelijkertijd aan meer dan 10 microservices werkt. Er komt een moment waarop u verschillende clusters of namespaces moet gebruiken, apart voor prod en dev. U kunt het team in verschillende subgroepen splitsen, zodat elke subgroep zijn eigen microservices heeft en elk van deze teams zijn eigen namespace kan kiezen om het ontwikkel- en uitrolproces te vergemakkelijken.
Naarmate elk lid van het team een beter inzicht krijgt in hoe het systeem als geheel werkt, wordt het steeds moeilijker om elke wijziging met alle andere ontwikkelaars te coƶrdineren. Het proberen om de volledige stack op uw lokale computer te draaien, wordt iedere dag ingewikkelder.
In grote bedrijven weten ontwikkelaars vaak niet wie precies aan welk onderdeel werkt. Teams communiceren via servicecontracten of gebruiken technologieƫn zoals Service Mesh, die een abstractielaag bovenop het netwerk toevoegt, vergelijkbaar met de configuratietool Istio. Het is praktisch onmogelijk om de hele stack lokaal te draaien. Ik raad ten zeerste aan om in Kubernetes een platform voor continue levering (CD) zoals Spinnaker te gebruiken. Zo komt er een moment waarop elk team beslist behoefte heeft aan zijn eigen namespace. Elk team kan zelfs meerdere namespaces kiezen voor de dev- en prod-omgeving.
Er zijn tenslotte grote ondernemingen waar een groep ontwikkelaars zelfs niet weet van het bestaan van andere groepen. Een dergelijk bedrijf kan zelfs externe ontwikkelaars inhuren die communiceren via goed gedocumenteerde API's. Binnen elke groep zijn er meerdere teams en verschillende microservices. In dit geval is het noodzakelijk om alle hulpmiddelen te gebruiken die ik eerder heb genoemd.
Programmers moeten services niet handmatig implementeren en mogen geen toegang hebben tot namespaces die hen niet aangaan. Op dit moment is het zinnig om meerdere clusters te hebben voor het verminderen van de āblast radiusā van slecht geconfigureerde applicaties, om facturering en resourcebeheer te vereenvoudigen.
Op deze manier maakt het juiste gebruik van namespaces door uw organisatie Kubernetes beter beheersbaar, controleerbaar, veilig en flexibel.
Een beetje reclame š
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 ā 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB ā vanaf $99! Lees over hoe
Bron: habr.com
