‫Sommige van de commando's die je tot nu
‫toe hebt gebruikt, hebben een beetje automatisering achter zich,
‫ook wel generatoren genoemd. Generatoren die je kunt bedenken als sjablonen.
‫Ze creëren in wezen de specificatie, of de specificatie,
‫die moet worden toegepast op het Kubernetes-cluster op
‫basis van uw opdrachtregelopties.
‫Je denkt aan commando's als uitvoeren, en
‫bloot, en creëren. Ze hebben vaak generatoren achter
‫zich die de benodigde sjabloon geven
‫met alle velden en de standaardinstellingen die u niet
‫per se opgeeft op de opdrachtregel.
‫In wezen is het doel van deze generatoren
‫om het voor u gemakkelijker te maken om éénregelige opdrachten te gebruiken, zoals u
‫gewend bent met Docker en Docker Compose en Swarm.
‫Om die eenregelige commando's in Kubernetes te gebruiken, terwijl
‫sommige van de meer geavanceerde instellingen op de standaardwaarden blijven.
‫Echt, Swarm doet dit ook.
‫Swarm heeft veel standaardinstellingen wanneer u services en stacks
‫maakt die allemaal op de achtergrond plaatsvinden.
‫Je weet het gewoon niet. Deze generatoren zijn zo.
‫Hier is een voorbeeld waarbij we een implementatie maken met
‫de opdracht create, en we geven het
‫een aantal opties om aan de minimumvereisten te voldoen.
‫Het vult de rest van de specificatie
‫met een generator.
‫Deze generatoren zijn verschillend voor elk type ding dat
‫je aan het maken bent. Of het nu gaat om een service,
‫of implementatie, of een job, of een cronjob.
‫Over andere dingen zullen we het later hebben.
‫Die generatoren kunnen in de loop van
‫de tijd veranderen naarmate elke versie van Kubernetes uitkomt.
‫Ze kunnen een of twee eigenschappen van die
‫specificatie wijzigen.
‫Deze hebben dus versies.
‫Soms, als je in documentatie hebt gezien, zie
‫je misschien wat YAML voor Kubernetes, en het zegt iets over bèta.
‫Dat is vaak wanneer een generator voor het eerst wordt gemaakt, deze
‫kan een bètaversie hebben en als deze overgaat naar
‫een volwassen generator, heeft deze een V1.
‫We kunnen niet echt een lijst met generatoren op
‫de opdrachtregel krijgen, omdat deze verschillende opdrachten en
‫verschillende opties omvat die generatoren kunnen gebruiken.
‫De gemakkelijkste manier om bij al deze verschillende opdrachten te
‫zien wat er zou worden gegenereerd als u
‫die opdracht tegen een cluster typt, is door twee opties te gebruiken.
‫De droge run, wat een heel nette manier is om de uitvoer
‫te laten zien van wat je hebt getypt, en
‫dat zullen we zo zien. Dan de -o, wat
‫output betekent. We zeggen dat we een uitvoer in YAML willen.
‫We zeggen in wezen dat u deze opdracht moet uitvoeren, maar
‫technisch gezien niet op het cluster.
‫Probeer het gewoon uit om te zien wat er zou gebeuren als ik het deed.
‫Laat me dan tegelijkertijd de YAML-uitvoer zien van wat er
‫zou worden gegenereerd als ik deze opdracht voltooi.
‫Je krijgt in wezen leuke kleine sjablonen.
‫Je zou dat zelfs kunnen gebruiken om je eigen YAML te maken die
‫we in latere colleges zullen gebruiken.
‫Eindelijk generatoren hier.
‫Je zou ze ook kunnen beschouwen als eigenzinnige standaarden.
‫Ze zijn echt niet eigenwijs.
‫Ze zijn super klein.
‫Het zijn meestal 10 tot 15 regels YAML.
‫Gewoon het absolute minimum om iets op gang te krijgen.
‫Ze hebben echter wel meningen, daarom hebben
‫ze versies. Mogelijk ziet u
‫een bètaversie afgestudeerd en zo. Ik vind ze eigenwijs, maar ze
‫zijn prima, toch. Ze zullen voor de meeste
‫gebruikssituaties werken wanneer je dingen gewoon uitprobeert voor ontwikkeling en testen.
‫Laten we een paar voorbeelden doornemen om deze generatoren
‫op de opdrachtregel te zien.
‫De eerste hier is een implementatie zoals we eerder hebben gebruikt.
‫De implementatie maken.
‫Je zult merken dat ik de --dry-run aan het einde heb gezet.
‫Als je gewoon een droge run doet, zal het alleen
‫het type bron uitspugen dat het zou creëren.
‫Dit is vergelijkbaar met de naam van de resource die we
‫zien wanneer we deze opsommen met een kubectl get-opdracht.
‫Als ik daar op de pijl omhoog druk en aan het
‫einde -o yaml typ, zal het
‫me de YAML-uitvoer laten zien die het met die opdracht heeft gegenereerd.
‫We gaan de YAML-specificaties
‫later doornemen. Voor nu kun je de belangrijkste
‫delen zien van wat er op de achtergrond is gedaan toen we de
‫opdracht Create Deployment deden.
‫Ten eerste toont het de API-versie, de versie van
‫dit type bron.
‫We gebruiken hier dus een
‫apps/v1-versie. Het soort is de implementatie, en
‫dat komt omdat we een implementatie maken.
‫Als het een baan was, was het een baan.
‫Als het een Service was, zou het service zeggen.
‫Dat soort dingen. De metadata zullen er
‫altijd zijn voor elke bron die u maakt.
‫Het heeft het tijdstempel, wat optioneel is, omdat het
‫dat automatisch genereert wanneer je dit
‫ding echt maakt. Dan heb je labels
‫en dan een naamattribuut hier dat je kunt specificeren.
‫In dit geval zie je dat het veel hiervan heeft ingevuld
‫met wat ik het op de opdrachtregel heb gegeven.
‫Ik zei dat ik het een test wilde noemen.
‫Dus, het geeft het een testnaam.
‫Het wijst het een app toe omdat we hier een
‫implementatie gebruiken, het beschouwt het als een app, geen service
‫of iets anders. Het noemt die labeltest.
‫Dit zijn gewoon standaardinstellingen.
‫Dan is de specificatie voor de implementatie
‫replica's van één.
‫De selector waar we later op in zullen gaan, maar dat
‫is in wezen hoe dit ding bepaalt om de pods in deze
‫implementatie te selecteren. Het is eigenlijk wat
‫overeenkomt met die implementatie met zijn pods.
‫Dan strategie. Die we leeg laten.
‫De sjabloon hier is voor de ReplicaSet.
‫Dan zie je onder die specificatie de containers die
‫het zal maken. Er is hier dus een beetje
‫een geneste laag van specs aan de hand. Dat komt door de complexiteit
‫van deze lagen, toch. We hebben pods, dan ReplicaSets
‫en daarbovenop implementaties.
‫Je kunt zien dat het dat allemaal on-the-fly creëert,
‫en we zullen dat toepassen op de API wanneer we op
‫deze opdracht drukken.
‫Laten we er hier nog een paar maken. De tweede gebruikt Jobs in
‫plaats van implementaties. Het is meestal ontworpen wanneer
‫u een set pods wilt maken die één keer wordt uitgevoerd.
‫Het heeft de neiging om ze standaard in te stellen om niet opnieuw op te starten.
‫In dit geval gebruiken we dezelfde afbeelding,
‫dezelfde naam. We gaan het
‫droog uitvoeren met de -output yaml. Je zult zien hoeveel anders het is.
‫In dit geval hebben we, omdat we niet de meerdere
‫niveaus van een implementatie met ReplicaSet erin genest, de
‫meerdere niveaus van specificatie niet nodig.
‫Je zult allereerst zien dat deze veel korter is.
‫Dat is grotendeels te wijten aan het feit dat
‫het met implementaties een geneste ReplicaSet maakt die
‫vervolgens de pod maakt. Er zijn dus meerdere niveaus.
‫Waar we hier eigenlijk gewoon deze batchtaak hebben om pods rechtstreeks
‫voor ons te maken.
‫Je kunt bovenaan zien dat de API-versie en de soort
‫beide zijn gewijzigd.
‫De metadata lijken erg op elkaar, hoewel er in
‫dit geval geen app-label is gemaakt.
‫De specificatie is alleen voor de banen en dan eronder,
‫de specificatie erin, in die sjabloon,
‫is de specificatie
‫voor elke containerpod, toch.
‫Deze ene specificatie zou worden gemaakt voor hoeveel ik er
‫ook om vroeg.
‫We hebben er standaard maar één gemaakt.
‫Het zal dus één container hebben met Nginx
‫met de naamtest. U zult merken dat het
‫herstartbeleid nooit is. Dat is echt de verandering
‫met de meeste van deze andere manieren om containers
‫in Kubernetes te maken. Ze zullen automatisch proberen opnieuw te maken of
‫opnieuw op te starten. Bij een
‫taak, of later bij een cron-taak, ziet u dat het
‫herstartbeleid is ingesteld op nooit. Omdat een taak doorgaans
‫is voltooid, is deze gewoon klaar en wilt u niet
‫dat die container deze opnieuw maakt. Laten we ten slotte een exposure-opdracht uitvoeren.
‫Ook al is er hier een droge run, wanneer u de implementatie
‫van de blootstelling uitvoert, gaat het controleren op die
‫implementatie en realiseren zich dat het niet bestaat, dus het
‫kan u geen voorbeelduitvoer geven omdat het niet echt de
‫geldige invoer heeft .
‫In dit geval moeten we technisch gezien een implementatie maken.
‫In deze hebben we het niet nodig om droog te lopen en
‫uit te voeren. We willen gewoon dat het het creëert.
‫Laten we dat dus gewoon doen.
‫Laten we dan teruggaan naar dat exposure-commando en het
‫opnieuw proberen. Dan zal die
‫droge run deze keer werken. We hebben een API-versie van V1.
‫U zult merken dat de Service nu van het soort is in
‫plaats van Implementatie of Job.
‫Dan hebben we andere vergelijkbare labels.
‫Je zult zien dat de specificatie draait om poorten en protocollen, want
‫dat is echt wat een service is.
‫Het is de combinatie van netwerkroutes en
‫IP-subnetten en TCP- of UDP-poorten, en dat
‫soort dingen. Generatoren zijn niet per se
‫een groot probleem. U hoeft ze niet uit het hoofd te leren
‫of de verschillen tussen ze allemaal te leren. Omdat je zult merken
‫dat veel van hen met het kubectl run-commando verdwijnen, zoals je
‫zo zult ontdekken. In een latere
‫lezing zullen we meer praten over de
‫soorten manieren waarop u containers maakt en misschien waarom u
‫niet heel veel run-and-creates gebruikt in uw productieworkloads.
‫Vergeet niet om de testimplementatie te verwijderen als u deze
‫hebt gemaakt voor onze laatste opdracht waarbij we de blootstelling hebben getest.