‫Based on when you watch this video, there's going to be
‫a slight different expectation of how to use the
‫run command. Starting in the Version 1.12, and
‫then at least through the current versions of Release 1.15,
‫and possibly in the next few, there's going to be different
‫messages based on how you use, or operate, the
‫run command. It's state, and it's uses, has
‫changed over the years.
‫The goal now with the run command is to
‫reduce it's functionality and deprecate many
‫of the generators that you just previously learned about.
‫Deprecate most of those. In fact, all of them but one, and
‫leave it as a single run command
‫that's designed to just start a pod.
‫One of the goals here is to reduce it's complexity so that
‫it's very similar and experienced to the docker
‫run command, only you're running it on top of Kubernetes.
‫We want to get rid of the generators that use deployments
‫and all these other types of generators because they're
‫now available in the kubectl create command.
‫So, when you think about, in the future, creating
‫objects from the one-liner command lines, think of the
‫create. Then the run is really just going to be left
‫to doing pods. The single use, really, that I
‫have for running pods really quickly is when I just want to
‫get something started. Maybe I'm on a machine that doesn't
‫have Docker because I'm using containerd or CRI-O,
‫or one of the other runtime engines, and I
‫don't have docker run convenience for me.
‫But, I do have Kubernetes installed, so I can do a kubectl
‫run which gives me a similar experience.
‫For me, the real reason, and only use case for
‫me to use run nowadays, now that we have this deprecated
‫stuff on a day-to-day basis, is for running one
‫shot containers, like troubleshooting, or network testing,
‫or something like that. Or, I just need to jump into a
‫container network, and I need to have a command line there
‫for some reason. That's when I use a run.
‫But, it's kind of important, still, at least for the next
‫few years, to understand the history of run.
‫Because, you're going to find all sorts of examples,
‫including in these videos that I'm giving you, on using
‫the run command because it's had a lot of history
‫with Kubernetes. So, when you're seeing examples,
‫you might have to translate on blogs, or different
‫documentation, that's going to be outdated in a few years.
‫You're going to see that stuff and you're going to have to
‫translate, OK, I used to do that with the run command.
‫Now, I've got to do that with a create command.
‫So, let me give you some examples of how the run command
‫used to work and still frankly, does today.
‫The version you're using to do this course because when
‫this stops working, I'm going to take this video out and
‫replace it with a sort of in memory
‫of the run command.
‫Let's talk about this thing we have that we no longer have
‫anymore.
‫Let's look at a few commands.
‫I'm just going to throw them in at the command line so that
‫you see what generators they were using based
‫on the type of run command you were using.
‫This is part of the confusion with run is it started to get
‫really complex in its use cases because of
‫various things you would do at the command line would
‫change the way it behaved when it created
‫your resources. With all of these, I'm just going to do a
‫dry run to show you what the object that was created
‫was. For this command, this is the standard one you learned
‫how to create Deployments earlier.
‫You'll notice that this default, I'm not specifying a
‫generator here, which I can do with a --generator.
‫But, I'm not going to use that because I want to show you
‫how the run command changes over time.
‫Without the generator today,
‫it's going to give you a Deployment.
‫In the future, when they finally make this change, the
‫default run will create a pod, not a Deployment, and it
‫will be expected that you use create or apply
‫to create Deployments, those commands, and
‫leave the run only for the pods.
‫Today, this is on 114.
‫You'll see that it creates a Deployment right there named
‫test. For these next few, you've not seen me give
‫you these examples because I didn't want you learning all
‫the different nuances of the run command if you weren't
‫going to be using them in a few years.
‫Here, you would see in this one, I added a port
‫and expose there, which in this case,
‫it will give me the warning, like normal, and it will then
‫create two, different things.
‫It'll create the Deployment and the service
‫resources without having to use two, different commands.
‫It's a really handy way to create and expose
‫a Deployment. Again, that's going away because you can use
‫the expose or the create commands separately, and it
‫turns out that the automation and complexity of this may
‫not be a good idea going forward.
‫So, they're going to get rid of that.
‫The next one here, I took out the expose part, and then
‫I added a restart on failure.
‫This will create a different type of resource.
‫It'll create the batch job or just the Job type.
‫That one there is essentially
‫for one-shot containers, things that you need to run.
‫Maybe you need to do at a schema update on your database.
‫Or maybe you want to do a quick database backup,
‫and you only want it to recreate the container if it
‫failed. Those were things you could do with run, but you
‫can also now do those with other ways.
‫The next one here is I set restart to never instead
‫of on failure. That will then change the resource
‫type to a pod, which will soon be
‫the default.
‫This is a little confusing.
‫You can force this behavior and you'll notice if we go back
‫to one of these previous commands like I just showed you,
‫when I do the restart on failure, the reason that line
‫is there is it's saying in the future, this
‫is what's going to happen, by default.
‫If you don't want that to happen, you can either force
‫a different generator, like I'm doing here, which is
‫using the Job V1, or use the create command.
‫Which they would prefer you use.
‫So, my course is designed for that future use.
‫I'm not teaching you all the different ways to run the
‫run command. I'm just going to focus on the create
‫and other options like apply.
‫Then the last one here, in case you just didn't know this
‫existed. Because we have cron job support in
‫Kubernetes, if I gave the same run command, but then
‫I gave it a schedule, it would change the generator
‫to use a cron job.
‫Which, a little bit different than a Job.
‫The cron job is designed to be reoccurring.
‫So, it will happen, in this case, it's once a
‫day. Hopefully, that makes sense in terms of the history of
‫the run command. Again, I think, really, the future for us
‫we should just start behaving as if it's only creating pods
‫because here soon, whether it's going to be in possibly 116
‫or 117, I'm not sure when they're going to force the real
‫change. All of these will be pulled out at some
‫point and won't even build to use these generators.
‫We'll be forced to use create and apply in other ways to
‫create the different types of resources.