‫Op basis van wanneer je deze video bekijkt, zal er een
‫iets andere verwachting zijn van het gebruik van de
‫opdracht run. Vanaf versie 1. 12, en dan in ieder
‫geval via de huidige versies van Release 1. 15, en mogelijk in
‫de komende paar, zullen er verschillende berichten zijn
‫op basis van hoe u het run-commando gebruikt
‫of bedient. De staat, en het gebruik
‫ervan, is in de loop der jaren veranderd.
‫Het doel nu met het run-commando
‫is om de functionaliteit ervan te verminderen en veel van de
‫generatoren te depreciëren waarover je zojuist hebt geleerd.
‫Verwerp de meeste daarvan. In feite allemaal op
‫één na, en laat het als een enkele run-opdracht die is
‫ontworpen om gewoon een pod te starten.
‫Een van de doelen hier is om de complexiteit ervan te verminderen, zodat
‫het erg lijkt op en ervaren wordt als de opdracht docker run,
‫alleen voert u het bovenop Kubernetes uit.
‫We willen af van de generatoren die gebruik maken van implementaties
‫en al deze andere soorten generatoren omdat ze nu
‫beschikbaar zijn in de kubectl create opdracht.
‫Dus als u in de toekomst denkt aan
‫het maken van objecten vanaf de one-liner-opdrachtregels, denk
‫dan aan het maken. Dan wordt de run eigenlijk alleen overgelaten aan
‫het doen van pods. Het eenmalig gebruik dat ik
‫echt heb om pods heel snel te laten werken, is wanneer ik
‫gewoon iets wil beginnen. Misschien zit ik
‫op een machine die geen Docker heeft omdat ik
‫containerd of CRI-O gebruik, of een van de andere runtime-engines,
‫en ik heb geen docker-run-gemak voor mij.
‫Maar ik heb Kubernetes geïnstalleerd, dus ik kan een kubectl-run uitvoeren
‫die me een vergelijkbare ervaring geeft.
‫Voor mij is de echte reden, en
‫enige use case voor mij om tegenwoordig run te gebruiken,
‫nu we deze verouderde dingen dagelijks hebben, voor het uitvoeren
‫van eenmalige containers, zoals probleemoplossing of netwerktests, of
‫zoiets zoals dat. Of ik moet gewoon in een containernetwerk
‫springen en om de een of andere reden moet ik daar
‫een opdrachtregel hebben. Dan gebruik ik een run.
‫Maar het is nog steeds belangrijk, in ieder geval voor de
‫komende jaren, om de geschiedenis van hardlopen te begrijpen.
‫Omdat je allerlei voorbeelden zult vinden,
‫inclusief in deze video's die ik je geef,
‫over het gebruik van het run-commando omdat het veel geschiedenis
‫heeft met Kubernetes. Dus als je voorbeelden ziet,
‫moet je misschien vertalen op blogs of andere documentatie,
‫dat zal over een paar jaar achterhaald zijn.
‫Je gaat die dingen zien en
‫je zult moeten vertalen, oké, dat deed ik altijd met het run-commando.
‫Nu moet ik dat doen met een create-commando.
‫Dus, laat me je enkele voorbeelden geven van hoe het run-commando
‫vroeger werkte en nog steeds eerlijk gezegd vandaag doet.
‫De versie die je gebruikt om deze cursus te doen, want als
‫dit niet meer werkt, ga ik deze video verwijderen
‫en vervangen door een soort geheugen
‫van het run-commando.
‫Laten we praten over wat we hebben dat we
‫niet meer hebben.
‫Laten we een paar commando's bekijken.
‫Ik ga ze gewoon in de opdrachtregel gooien, zodat
‫je kunt zien welke generatoren ze gebruikten op basis van het type
‫run-commando dat je gebruikte.
‫Dit maakt deel uit van de verwarring met run,
‫omdat het erg complex begon te worden in zijn
‫gebruikssituaties, omdat verschillende dingen die je op
‫de opdrachtregel zou doen, de manier zouden veranderen waarop het zich gedroeg toen
‫het je bronnen aanmaakte. Met al deze dingen
‫ga ik een test doen om je te laten zien wat
‫het object was dat werd gemaakt. Voor deze opdracht is dit de standaardopdracht
‫die u eerder hebt geleerd om implementaties te maken.
‫Je zult merken dat ik bij deze standaard geen generator specificeer, wat
‫ik kan doen met een --generator.
‫Maar ik ga dat niet gebruiken omdat ik je wil laten zien
‫hoe het run-commando in de loop van de tijd verandert.
‫Zonder de generator vandaag, krijgt u
‫een implementatie.
‫In de toekomst, wanneer ze deze wijziging uiteindelijk
‫doorvoeren, zal de standaarduitvoering een pod maken, geen
‫implementatie, en wordt verwacht dat u create of apply gebruikt
‫om implementaties te maken, die opdrachten, en de uitvoering alleen
‫voor de pods overlaat.
‫Vandaag is dit op 114.
‫U zult zien dat het een implementatie maakt
‫met de naam test. Voor de volgende paar heb
‫je me deze voorbeelden niet zien geven, omdat ik niet wilde dat je
‫alle verschillende nuances van het run-commando zou leren als je ze
‫over een paar jaar niet zou gebruiken.
‫Hier, zoals je in deze zou zien, heb ik een
‫poort toegevoegd en daar blootgelegd, wat in dit geval
‫me de waarschuwing zal geven, zoals normaal, en het
‫zal dan twee verschillende dingen creëren.
‫Het maakt de implementatie- en serviceresources zonder
‫dat u twee verschillende opdrachten hoeft te gebruiken.
‫Het is een erg handige manier om een implementatie te
‫maken en weer te geven. Nogmaals, dat gaat weg omdat
‫je de commando's bloot of aanmaken afzonderlijk kunt gebruiken, en
‫het blijkt dat de automatisering en complexiteit hiervan in
‫de toekomst misschien geen goed idee zijn.
‫Dus daar gaan ze zich van ontdoen.
‫De volgende hier, ik heb het blootliggende gedeelte verwijderd en toen heb
‫ik een herstart toegevoegd bij een fout.
‫Dit zal een ander type bron creëren.
‫Het maakt de batchtaak of alleen het taaktype.
‫Die is er in wezen voor eenmalige
‫containers, dingen die je moet uitvoeren.
‫Misschien moet u een schema-update op uw database doen.
‫Of misschien wilt u een snelle databaseback-up maken en wilt
‫u alleen dat de container opnieuw wordt gemaakt
‫als dit is mislukt. Dat waren dingen die je met
‫hardlopen kon doen, maar die kun je nu ook op andere manieren doen.
‫De volgende hier is dat ik opnieuw opstarten heb ingesteld op nooit
‫in plaats van op mislukking. Dat zal dan het
‫resourcetype veranderen in een pod, wat binnenkort de standaard
‫zal zijn.
‫Dit is een beetje verwarrend.
‫Je kunt dit gedrag forceren en je zult merken dat als
‫we teruggaan naar een van deze eerdere commando's, zoals
‫ik je net liet zien, wanneer ik de herstart doe bij een fout,
‫de reden dat die regel daar is, is dat hij in de toekomst zegt, dit
‫is wat er is gaat gebeuren, standaard.
‫Als je niet wilt dat dat gebeurt, kun je een
‫andere generator forceren, zoals ik hier doe, die
‫de Job V1 gebruikt, of de opdracht create gebruiken.
‫Die ze liever zouden gebruiken.
‫Dus mijn cursus is ontworpen voor dat toekomstig gebruik.
‫Ik leer je niet alle verschillende manieren om het
‫run-commando uit te voeren. Ik ga me gewoon concentreren op
‫het maken en andere opties, zoals toepassen.
‫Dan de laatste hier, voor het geval je gewoon
‫niet wist dat dit bestond. Omdat we cronjob-ondersteuning hebben
‫in Kubernetes, als ik hetzelfde run-commando geef, maar
‫dan geef ik het een schema, zou het de generator veranderen
‫om een cron-job te gebruiken.
‫Wat een beetje anders is dan een Job.
‫De cron-taak is ontworpen om terugkerend te zijn.
‫Dus het zal gebeuren, in dit geval is
‫het één keer per dag. Hopelijk is dat logisch in termen van
‫de geschiedenis van het run-commando. Nogmaals, ik denk echt
‫dat de toekomst voor ons, we ons gewoon moeten
‫gaan gedragen alsof het alleen maar pods maakt, want hier binnenkort, of het
‫nu in 116 of 117 zal zijn, ik weet niet
‫zeker wanneer ze de echte verandering. Al deze zullen op een gegeven moment worden
‫teruggetrokken en zullen niet eens worden gebouwd om deze generatoren te gebruiken.
‫We zullen genoodzaakt zijn om maken en toepassen op andere manieren te
‫gebruiken om de verschillende soorten bronnen te maken.