‫Oh man. Ik wed dat je
‫al een tijdje wacht om naar de Kubernetes-opdrachtregel te gaan.
‫Maar gelukkig hebben we een aantal van de concepten uit de weg.
‫Laten we dus naar de opdrachtregel gaan.
‫Het eerste dat we moeten controleren, is dat wat
‫je ook hebt gedaan met het instellen van Kubernetes, dat het werkt.
‫De manier waarop we dat kunnen doen is vergelijkbaar met de Docker-versie
‫en de Compose-versie en dat soort dingen.
‫We kunnen naar de shell gaan en kubectl
‫typen, dat is de K U B E C
‫T L-versie. Je zou terug moeten gaan naar versies.
‫Dit is net als bij Docker waar u de clientversie
‫krijgt en vervolgens de serverversie.
‫Onthoud dat al deze opdrachtregelprogramma's praten met
‫een externe API.
‫In dit geval is dit waarschijnlijk de API op uw computer.
‫Net als bij Docker en Swarm en Compose
‫kan de kubectl-opdrachtregel ook communiceren met de
‫externe Kubernetes-API.
‫Nu je de client-serverversies hebt teruggekregen, kun
‫je aan de slag. Als u een foutmelding krijgt, komt dit
‫waarschijnlijk omdat de serverversie niet wordt weergegeven en zegt dat er geen
‫verbinding kan worden gemaakt. Dat betekent dat je
‫op de een of andere manier verkeerd geconfigureerd bent en je lokale CLI niet
‫kan praten met de Kubernetes-servers. Ik zou ofwel controleren hoe je het
‫hebt geïmplementeerd om er zeker van te zijn dat het werkt.
‫Als je Docker Desktop gebruikt, moet je misschien Docker
‫starten en vervolgens in de instellingen controleren
‫of Kubernetes actief is. Als het op een andere manier
‫is, bekijk dan de installatievideo. Als je daar problemen mee hebt, neem dan contact op
‫in de Q & A of in Slack.
‫Oke. Er zijn eigenlijk twee manieren om pods
‫in Kubernetes te implementeren. Je doet het op
‫de opdrachtregel waar je alle opties op de opdrachtregel
‫specificeert. Of er wordt gebruik gemaakt van YAML.
‫Dit kan qua concept vergelijkbaar zijn met services en stacks in
‫Swarm, maar als je er echt aan begint, zijn
‫er natuurlijk veel verschillende dingen
‫onder de dekens. Dus ik haat het om die analogie te
‫maken, maar dat zijn echt de twee opties die je hebt: de opdrachtregel of YAML.
‫Laten we ons een paar minuten concentreren op de opdrachtregel.
‫Het eerste commando dat we hier gaan uitvoeren
‫is kubectl run.
‫Het is dus vergelijkbaar met een docker-run.
‫Mijn Nginx, en je kunt het noemen wat je wilt.
‫Dit is de naam van uw implementatie. En dan --image, en we
‫zullen hier de naam van de afbeelding specificeren.
‫Laten we gewoon Nginx gebruiken zoals we gewend zijn en op Return drukken.
‫Laten we de waardeverminderingswaarschuwing even negeren als u die
‫krijgt in enkele van de recente versies
‫van Kubernetes. We zullen er zo over praten.
‫Maar laten we nu eens kijken wat er net is gebeurd.
‫We kunnen dat gebruiken met het kubectl get commando.
‫kubectl krijgt peulen.
‫Wat je daar zou moeten zien, is dat je een
‫genoemd object bent, samen met enkele tekens aan het einde ervan, en
‫je zult zien dat 1 op 1 draait.
‫Dit lijkt erg op het services-concept in
‫Swarm, waar we standaard slechts één
‫replica draaiden.
‫Daar zie je zijn naam.
‫Waarom hebben we die rare naam?
‫Welnu, dit heeft te maken met de manier waarop de
‫opdracht kubectl run werkt.
‫Wanneer u de run gebruikt zoals deze nu
‫is in versie 1. 14, dat is technisch
‫gezien het gebruik van een Deployment-controller.
‫Die implementatiecontroller maakt een ReplicaSet-controller.
‫Die ReplicateSet-controller maakt vervolgens de pods.
‫In dit geval is het slechts één replica.
‫Het is dus maar één pod.
‫Als we een kubectl hadden om alles te krijgen,
‫zou je alle objecten daar zien staan.
‫Je zult peulen zien.
‫Negeer de service voor nu.
‫We zullen er zo over praten.
‫De implementatie en in de ReplicaSet.
‫Je kunt deze verschillende lagen van het
‫objectmodel en Kubernetes hier zien verschijnen waar we slechts een enkele opdracht
‫hebben uitgevoerd, maar het heeft in feite meerdere objecten
‫voor ons gemaakt.
‫Laten we naar mijn tekentafel gaan en beschrijven hoe deze
‫objecten zich tot elkaar verhouden.
‫Zoals je in Kubernetes hebt gezien, hebben we
‫meer abstractie- en controleniveaus dan we eerder hadden in Swarm
‫of in Docker zelf.
‫In dit geval, toen we de kubectl-run uitvoerden, creëerde
‫het op de achtergrond automatisch meerdere,
‫verschillende abstracties voor ons.
‫Het creëerde de pod, maar het creëerde ook daaromheen een
‫ReplicaSet en daaromheen een Deployment.
‫Laten we naar de tekentafel gaan en ik zal je laten zien hoe
‫deze abstracties zich tot elkaar verhouden.
‫Ter herinnering, we hebben Docker eronder draaien.
‫Dan hebben we een aantal containers draaien die Kubernetes beheren, en daar zal ik
‫het nu niet over hebben.
‫Laten we even weten dat we hier een andere
‫set containers hebben om Kube te gebruiken.
‫Toen we de kubectl-run deden, creëerde het
‫duidelijk onze Nginx-container, dat was het deel
‫waarvan we weten.
‫Maar de verschillende niveaus van controle, of abstracties, zijn het
‫interessante deel.
‫De eerste hier is de pod.
‫Nogmaals, het kan een of meer containers in deze pod laten lopen.
‫Als onderdeel van die pod had het volumes kunnen creëren als
‫we het nodig hadden. Het creëerde de NIC
‫voor de pod.
‫De manier waarop het die pod maakte,
‫was toen we kubectl run typten, het creëerde
‫een implementatie.
‫Een implementatiecontroller beheert ReplicaSets.
‫We hebben meerdere abstractieniveaus.
‫Die implementatie is gemaakt en doet dingen
‫als doorlopende updates, of Blue/Green Deploys, en een heleboel
‫andere dingen waar je aan denkt als je
‫denkt aan orkestratieservices zoals we hadden in Swarm-services.
‫Toen die implementatie werd gemaakt, werd een ReplicaSet van
‫één gemaakt.
‫Dat zelf is een andere controller.
‫Het is de taak van de ReplicaSet om ervoor te zorgen dat het
‫aantal pods waar we om hebben gevraagd momenteel actief is.
‫In dit geval hebben we alles op de standaard gelaten.
‫Dus onze implementatie heeft één ReplicaSet gemaakt en die
‫ReplicaSet heeft één pod gemaakt.
‫We zouden elk van deze verschillende
‫abstractieniveaus kunnen beheersen. We kunnen commando's typen
‫om de implementatie te besturen. De ReplicaSet, of de
‫pod zelf, maar meestal in deze situaties, beheert
‫u altijd de implementatie zelf.
‫Dan regelt het de rest.
‫Om u een idee te geven waarom de
‫ReplicaSet zelf in het midden bestaat, is als
‫we nog een kopie van deze pod willen maken,
‫net zoals wanneer we Swarm-servicereplica's maken.
‫In mijn tekening hier heb ik een kopie
‫van die pod gemaakt.
‫Dat zou zijn als we de replica's naar twee zouden schalen.
‫Zeer vergelijkbaar met hoe Swarm het doet.
‫De taak van de ReplicaSet is
‫wederom om ervoor te zorgen dat twee pods worden uitgevoerd
‫met dezelfde sjabloon. De taak van de
‫implementatie is het beheren van de ReplicaSet-configuratie.
‫Voordat we naar de volgende lezing gaan, laten we al deze bronnen die we
‫zojuist hebben gemaakt met de opdracht run verwijderen door de
‫opdracht delete te gebruiken.
‫Dit is anders dan Docker waar Docker
‫de verwijderopdracht had.
‫Nu gebruiken we een delete-opdracht met kubectl.
‫U zult merken dat we het type object specificeren en vervolgens
‫de naam van zichzelf. Dus we doen aan implementatieruimte, de
‫naam van de implementatie.
‫Als je dat doet, worden alle
‫dingen eronder verwijderd. De ReplicaSet, de pods zelf en
‫de containers erin.
‫We kunnen dat snel verifiëren met hetzelfde commando 'alles krijgen'.
‫U ziet daar alleen het cluster-IP, de
‫Kubernetes-server zelf.