‫Hopelijk beginnen deze YAML-dingen een beetje logisch te worden,
‫en dit is waar we leren hoe we deze YAML
‫in wezen helemaal opnieuw kunnen maken.
‫Toen ik begon met het leren
‫van het Kubernetes YAML-formaat, begon ik eerst met
‫het gebruik van documentatievoorbeelden uit hun documenten
‫op de kubernetes. io-site, of misschien van andere plaatsen.
‫Het ding met andere plaatsen is, net als Docker, dat
‫die blogs en andere dingen allemaal verouderd raken.
‫Het ding met Kubernetes is dat sommige van deze dingen
‫in de loop van de tijd zijn veranderd,
‫vooral als het gaat om zaken als implementaties en pods en
‫andere kernzaken. Ze hebben hun formaten aangepast.
‫De versies in de API zijn gewijzigd.
‫We willen bij de
‫huidige dingen blijven, wat betekent dat je moet weten
‫hoe je helemaal opnieuw moet beginnen. Hoe weet u wanneer uw bestanden moeten
‫worden gewijzigd in plaats van de documentatie willekeurig opnieuw te lezen
‫om te zien of er iets is veranderd, toch?
‫Dit deel is, denk ik, een vaardigheid die het me een
‫tijdje kostte om dit uit te zoeken, en hoe ik
‫een bestand kon bouwen zonder een of ander
‫reeds bestaand sjabloon te gebruiken. We hebben in de laatste
‫lezing over de vier typen gesproken, en op
‫die soort rootsleutel, het resourcetype, wil ik
‫me eerst concentreren. Omdat je een lijst van die in een cluster kunt krijgen.
‫In onze setup-testclusters zullen de meeste hiervan voor
‫ons allemaal hetzelfde zijn.
‫Naarmate u in productie gaat en u
‫dingen van derden aan uw cluster begint toe te voegen,
‫wordt deze lijst langer, afhankelijk van wat u gebruikt,
‫omdat hulpprogramma's van derden nieuwe bronobjecten aan de API
‫kunnen toevoegen.
‫Laten we een kubectl api-resources doen.
‫Je krijgt minstens tientallen verschillende objecten terug waar
‫we doorheen kunnen bladeren en uren over
‫kunnen praten.
‫Dat gaan we niet doen.
‫We hebben er al een paar
‫genoemd, zoals implementaties en pods en replicasets en services.
‫Dat zijn de standaard out-of-the-box dingen.
‫Veel van de rest mag je nooit aanraken.
‫Dat is het ding over Kubernetes, er
‫is gewoon zoveel aan dat je misschien nooit
‫alle kracht ervan nodig hebt. Het is niet zo belangrijk
‫dat u deze allemaal doorneemt en onthoudt.
‫U ziet deze vriendelijke kolom aan de rechterkant.
‫Dat staat in ons YAML-bestand.
‫Als we een pod willen maken, kun je zien dat er hier
‫een soort pod is. Als we een implementatie
‫willen maken, is er een soort genaamd implementatie.
‫U ziet ook de API-groep.
‫Die API-groep is gerelateerd aan de
‫API-versie. Dat zie je zo.
‫Dit geeft ons niet noodzakelijkerwijs een
‫prescriptieve handleiding. Maar als ik hier zat
‫en ik zei: ik moet een pod maken, dan zou ik door deze lijst kijken
‫naar pods in het type bronnen.
‫Ik zou het soort zien dat het is.
‫Dat is wat ik weet dat ik in mijn YAML moet zetten.
‫Ik zou kijken of er een API-groep is, want die
‫zal me vertellen waar ik de versies kan vinden die ik
‫kan gebruiken, omdat je waarschijnlijk verschillende
‫documentatie hebt gezien voor laten we zeggen een implementatie.
‫Omdat implementaties in de loop van de tijd meerdere versies hadden.
‫Er was een v1beta1, een v1beta2.
‫Het is zelfs verplaatst in de API omdat er oude dingen en
‫nieuwe dingen zijn, dus het kan een beetje verwarrend zijn.
‫Als je naar deze lijst kijkt, zul je
‫zien dat er hier implementaties zijn,
‫en implementaties hier beneden.
‫Het enige verschil tussen de twee is
‫deze middelste rij, de API-groep.
‫Die API-groep is waar in de API dit
‫type bron kan worden geopend, gemaakt,
‫verwijderd, enz.
‫Dit raakt een beetje in het onkruid, maar als je eenmaal met
‫dit spul begint te werken, zul je
‫wat tijd moeten besteden aan gevallen zoals het zien van
‫twee soorten implementaties hier.
‫Welke gebruik ik?
‫Nou, je begint onderzoek te doen en je zult
‫vinden, ofwel in de documentatie, of in de API-gids zelf,
‫die we zo dadelijk zullen bekijken.
‫Je zult dat spul zien waar het je zal vertellen dat
‫de ene verouderd is en dat de ene naar
‫de andere gaat en in dit geval met implementaties, de nieuwe versie
‫ervan, in de nieuwste versie, is de API van de app.
‫De volgende opdracht die daarbij hoort, om
‫ons te helpen een beter beeld te krijgen
‫van de soort, plus de API-versie, is de opdracht
‫kubectl API-versies.
‫Dat geeft ons een kortere lijst met alleen de
‫verschillende versies van API's waar we ons zorgen
‫over moeten maken. In het geval van
‫implementaties zul je hier zien dat er iets bekends is.
‫Vergeet niet dat we zagen dat er een apps-versie was
‫en een extensie-versie voor implementaties.
‫Die zullen we hier zien verschijnen.
‫Technisch gezien zijn er de extensies
‫van v1beta1 API. Er is de apps-API waarvan
‫je daar drie verschillende versies kunt zien.
‫U wilt waarschijnlijk de V1-apps gebruiken, niet
‫de oudere bèta's.
‫Maar u kunt zien waar de API min of
‫meer vasthoudt aan verouderde versies van deze API terwijl er
‫nieuwe worden uitgerold.
‫Op die manier is je oude YAML in principe niet kapot totdat er
‫veel versies voorbij zijn en ze dingen uit de API halen
‫zodra het niet langer nodig is.
‫Wat meestal gebeurt tijdens de levensduur van
‫uw YAML, als u zich in de begindagen
‫van Kubernetes bevond, is dat u mogelijk een
‫YAML-bestand hebt gebruikt
‫met de extensies/v1beta1 voor de API-versie, en het soort
‫implementaties was.
‫Maar aangezien die API is
‫veranderd en ze het nu de apps-API noemen,
‫en de versie anders is, zou je nog
‫steeds een soort van implementatie hebben, maar je zou
‫die API-versie nu veranderen in apps/v1.
‫De manier waarop ik dat weet is omdat ik moest zoeken
‫en jij de documentatie zou bekijken.
‫Je ziet in de voorbeelden dat, oh hey.
‫Er staat nu apps. Er staan geen extensies meer.
‫Dat is vreemd. Laat me het opzoeken. Dan vind
‫je enkele Kubernetes-problemen in GitHub die erover praten.
‫Het is een beetje rommelig. Er is niet
‫altijd een duidelijke lijst met beëindigingen van alles
‫wat voortdurend verandert, dus het kan een probleem zijn.
‫De manier waarop u weet dat dit niet werkt,
‫is wanneer u een oude YAML neemt en deze op een
‫nieuw cluster toepast, en u zult zien dat ik
‫deze API-versie niet meer ondersteun. Of ik weet niet wat voor soort dit is.
‫Dus het geeft je leuke fouten die je laten weten dat,
‫dat is het probleem. Dan kunt u waarschijnlijk
‫wat snel zoeken en erachter komen wat er verouderd is.
‫Het punt dat ik wil maken
‫is dat de soort, plus de API-versie, samen worden gebruikt
‫om te beslissen welke bron je gaat krijgen en welke
‫API-versie je voor die bron kunt gebruiken.
‫Dat zijn de eerste twee dingen die je moet uitzoeken voordat
‫je zelfs een YAML maakt.
‫Als je dat eenmaal hebt, ga
‫je het metadata-gedeelte maken. Het enige dat u daar hoeft te hebben,
‫is de naam van de bron die u gaat maken.
‫Geef het maar een mooie naam.
‫Dan ga je naar de specificatie. Dat is waar alle
‫actie zich bevindt, omdat de specificatie compleet anders zal zijn op basis
‫van de bron die u aan het maken bent.
‫Als u opslag creëert versus een implementatie, kunt u zich voorstellen hoe
‫de YAML er heel anders uit
‫zou zien, toch.
‫In de volgende lezing gaan we enkele kubectl-commando's
‫doornemen om je te helpen de API te verkennen
‫voor alle verschillende spec-dingen die je in je YAML
‫kunt stoppen voor verschillende bronnen.