‫Voor uw eerste cluster, misschien zelfs uw eerste paar clusters,
‫hoeft u zich niet al te veel zorgen te maken
‫over dit concept van naamruimten en contexten.
‫Maar het is iets waarvan u zich bewust moet
‫zijn dat het bestaat voor het geval u het moet gebruiken.
‫Naamruimten zijn in wezen virtuele clusters, of virtuele
‫views, binnen een enkel cluster.
‫Het filtert niet alleen de weergave van het commando, zodat je
‫alleen bepaalde dingen ziet wanneer je commando's
‫typt, maar het kan ook, met de juiste plug-ins
‫voor netwerkbeleid, het netwerk besturen.
‫Dit is een beetje anders dan Swarm, waar
‫Swarm, out-of-the-box, verschillende overlay-netwerken zou maken en alles
‫in wezen privé was.
‫In Kubernetes zijn netwerken en beheer van apps en hun
‫privacy, en wat ze kunnen zien en openen,
‫en wat daar fysiek wordt gecontroleerd, echt afhankelijk van
‫uw netwerkplug-in.
‫Naamruimten zelf zijn niet gerelateerd aan Docker-naamruimten, waar je misschien
‫van hebt gehoord, wat in feite een onderdeel is
‫van het Linux-subsysteem, en dat is een beetje
‫hoe containers werken. Dit heeft daar niets mee te maken.
‫Dit is gewoon Kubernetes die zegt, hey, je hebt misschien een heleboel
‫dingen aan de hand in je cluster, en ik geef je
‫de mogelijkheid om kleine miniclusters te maken waar je
‫de naamruimte met een context instelt en dat is
‫jouw mening is door je context veranderen.
‫Je kunt veranderen wat je ziet.
‫Dan bestaat de naamruimte uit verschillende segmenten voor
‫het filteren van de opdrachten, evenals mogelijk voor
‫het netwerken. Op mijn systeem hier op mijn
‫bureaublad zie ik gewoon dat kubectl naamruimten krijgt en dat commando
‫laat me 4 zien. Dat is een beetje,
‫out-of-the-box, de standaard die je gaat zien.
‫Standaard is waar je tot nu toe mee hebt gewerkt.
‫Dat is gemaakt voor de standaardnaamruimte van
‫uw apps. Het enige dat het je
‫echt laat zien wanneer je een kubectl
‫hebt gedaan om alles te krijgen, is het Kubernetes API-eindpunt zelf, toch.
‫Totdat we begonnen met het toevoegen van apps, zagen we
‫daar niet echt iets. Technisch gezien draaien al
‫deze dingen op de achtergrond, toch. Dat is wat de kubectl alle
‫--all namespaces krijgt.
‫Met die opdracht kunt u alle
‫API-containers en wat niet binnen Kubernetes
‫zelf zien. Als ik alle naamruimten
‫tegelijk bekijk, krijg ik alles inclusief systeemdingen.
‫Dit is een weergave van hoe het eruit zou
‫zien op minikube, die alles in hun eigen pods stopt om het cluster
‫zelf te laten draaien.
‫Er gebeurt daar veel.
‫Het besef is dat wanneer u
‫normaal Kubernetes gebruikt, de opdrachtregel zich standaard richt
‫op de standaardnaamruimte.
‫Je zult je apps daar alleen echt zien,
‫behalve het API-eindpunt.
‫Dat is een goede zaak, toch. Het verbergt de
‫complexiteit van wat er op de achtergrond gebeurt
‫voor je dagelijkse commando, omdat je dat spul
‫niet echt hoeft te zien, tenzij je het moet upgraden of veranderen, of
‫als je een probleem hebt. Context speelt een rol
‫bij het instellen van uw weergave voor wanneer u opdrachten uitvoert.
‫De kubectl doet veel dingen, toch.
‫Het kan verbinding maken met verschillende clusters.
‫Het kan de authenticatie of de gebruiker wijzigen die u
‫gebruikt om met het cluster te praten, waar we het
‫nog niet over hebben gehad, of de naamruimte.
‫Er zijn dus eigenlijk deze drie delen van een context.
‫Dat is cluster, de authenticatie of de gebruiker, en
‫vervolgens de naamruimte die u wilt zien.
‫Alles wat standaard is gedefinieerd in een
‫bestand in de . kube-map van uw
‫thuismap.
‫Er zit een bestand in met de naam config,
‫en het zal in feite een YAML-bestand zijn van alle, drie van die delen.
‫Je kunt er meerdere items in hebben en je kunt het
‫bewerken zoals je wilt.
‫Je zou een heleboel verschillende clusters kunnen hebben en zolang je de certificaten
‫hebt om met ze te praten, de juiste authenticatie, kun je
‫al die dingen in dat bestand stoppen, en het is iets dat
‫je geheim wilt houden. Het is
‫niet iets dat u echt wilt delen, omdat
‫het doorgaans uw authenticatiesleutels heeft om met
‫een cluster te praten. Als je de
‫opdracht kubectl config gebruikt met de subopdracht van get contexts, dat is
‫meervoud, kun je in feite de uitvoer
‫van dat bestand zien. In plaats van het
‫rauw te dumpen, kun je een kleine
‫mooie lijst zien van wat erin zit.
‫In mijn geval heb ik mijn standaard Docker Desktop
‫op mijn lokale computer. Die vermelding staat er twee
‫keer in voor de laatste paar edities van Docker Desktop omdat ze de
‫naam hebben veranderd, zodat ze beide daar behouden voor compatibiliteit.
‫Dan heb ik een lokale minikube en
‫een externe instantie van micro K8's die op
‫een Ubuntu-server draaien.
‫Dus je kunt je voorstellen dat als
‫ik veel andere servers beheerde, ik niet altijd naar
‫die machines wil ssh-en. Ik wil gewoon op mijn lokale computer zitten
‫en met die externe API praten.
‫U kunt de opdracht kubectl config gebruiken met een
‫van de ingestelde opties. Je wilt zeker
‫de hulp daar bekijken. Maar er zijn vaste opties voor
‫het instellen van de standaardwaarden voor elk van deze,
‫dus u kunt de gebruiker mogelijk wijzigen om een
‫andere authenticatie te hebben. Dus misschien heb je God-rechten
‫in plaats van slechts een subset van de opdrachten die Kubernetes
‫zou kunnen uitvoeren. Of misschien gaat u het cluster
‫wijzigen waarmee u praat.
‫Er zijn zelfs opdrachtregel-plug-ins als je op Google
‫rondkijkt, zodat je in
‫je shell kunt zien welke context je gebruikt.
‫Dat is best handig als je uiteindelijk een heleboel verschillende
‫clusters gaat beheren. Wil je weten,
‫met wie heb ik het nu? Je kunt dat eigenlijk instellen,
‫een beetje zoals hoe de get-prompts je vertellen in welke
‫branche je zit. Deze zullen u in uw prompt vertellen
‫welke context u heeft.