‫Het voordeel dat je Docker leert, dan Compose en dan
‫Swarm is dat je hier zoveel basiskennis hebt dat ik
‫niet helemaal opnieuw hoef te beginnen als ik
‫je Kubernetes leer.
‫Sommige terminologieën, vooral als we het hebben over
‫de objecten in Kubernetes die u beheert en gebruikt, kunnen een
‫beetje verwarrend zijn omdat sommige tegenstrijdig zijn
‫en sommige gewoon nieuw zijn.
‫Verreweg het belangrijkste dat je blijft horen,
‫als je ooit iets hebt opgezocht in Kubernetesland,
‫is de pod. De pod is de basiseenheid van implementatie.
‫Technisch gezien implementeren we containers niet rechtstreeks
‫in Kubernetes.
‫We zetten alleen pods in, en
‫we gebruiken daarbovenop dingen die bekend staan als controllers om
‫die pods te besturen.
‫Technisch gezien kun je een pod direct inzetten, maar dat zul
‫je niet echt willen doen.
‫Bijna altijd creëer je een controller die een
‫object is dat daar voortdurend zit en valideert
‫of wat er in Kubernetes gebeurt, is wat
‫je ervan hebt gevraagd.
‫Het is een differentiërende motor die verschillende types heeft.
‫Je begint met Deployments en ReplicaSets die je
‫bijna uitsluitend gaat gebruiken.
‫Implementaties lijken erg op de manier waarop we
‫services in Swarm hebben gedaan en die uw pods op
‫lagere niveaus aansturen. Vervolgens kunt u
‫verschillende soorten controllers wijzigen en gebruiken, zelfs typen
‫controllers van derden, waaronder StatefulSets en DaemonSets, en
‫Jobs, en CronJobs en nog veel meer.
‫Een deel van de flexibiliteit van Kubernetes is dat
‫het ons deze basiseenheid van pods geeft en ons vervolgens in staat
‫stelt om dat op verschillende manieren met controllers te besturen, en
‫ons in staat stelt om echt creatief te worden met hoe we
‫onze systemen inzetten.
‫De service is in Kubernetes net even anders dan je in
‫Swarm gewend was.
‫De service heeft echt niets te maken met het implementeren van
‫applicaties zoals je zou doen in Swarm.
‫De services, met name het eindpunt dat u aan een
‫set pods geeft, vaak wanneer u een controller zoals
‫een implementatiecontroller gebruikt om een set replicapods
‫uit te rollen, zou
‫u daar vervolgens een service op instellen.
‫De service betekent alleen dat je het een persistent eindpunt in
‫het cluster geeft,
‫zodat al het andere toegang heeft tot die
‫set pods op een specifieke DNS-naam en poort.
‫De volgende, heel snel, is een naamruimte.
‫We zullen niet echt veel gebruik maken van naamruimten in
‫Docker Mastery zelf omdat het een optionele, geavanceerde functie is,
‫maar je zult het horen als
‫je in documentatie kijkt of blogs leest en zo.
‫De naamruimte is eigenlijk slechts een filter op uw
‫weergave op de opdrachtregel.
‫Dat is echt alles. Het is geen beveiligingsfunctie.
‫Als u bekend bent met enkele interne onderdelen van Docker,
‫hoort u over naamruimten in Docker.
‫Dit is op geen enkele manier hetzelfde.
‫Dit is gewoon een manier
‫voor u om uw weergaven te filteren wanneer u de kubectrl-opdrachtregel gebruikt,
‫zodat u alleen de dingen ziet die u op
‫dit moment belangrijk vindt. Een goed voorbeeld
‫kan zijn wanneer Docker Desktop wordt gebruikt, het standaard
‫de standaardnaamruimte gebruikt en alle systeemcontainers filtert die Kubernetes
‫op de achtergrond uitvoeren.
‫Omdat u deze normaal gesproken niet wilt zien
‫wanneer u de kubectrl-opdrachtregels uitvoert.
‫Vervolgens kunt u de naamruimte wijzigen om die te zien
‫als u de verschillende weergaven wilt zien.
‫Zie het gewoon als een filter, niet als een beveiligingsfunctie.
‫Natuurlijk is er zoveel meer aan Kubernetes waar we uiteindelijk op
‫in zullen gaan. Er zijn geheimen.
‫Er is ConfigMaps. Er zijn een heleboel dingen van derden.
‫Maar genoeg met de concepten. Laten we commando's typen
‫en resultaten bekijken op de commandoregel en dan gaan
‫we het visualiseren op de tekentafel.