‫Oh man. I bet you've been waiting to just get to
‫the Kubernetes command line for a while now.
‫But luckily, we've got some of the concepts out of the way.
‫So, let's get to the command line.
‫The first thing we need to make sure is that whatever
‫you've done with setting up Kubernetes, that it's running.
‫The way we can do that is similar to the Docker version
‫and the Compose version and stuff like that.
‫We can go to the shell and type in kubectl,
‫that's K U B E C T
‫L version. You should get back to versions.
‫This is just like with Docker where you get the client
‫version and then the server version.
‫Remember that all these command line tools are doing
‫is talking to a remote API.
‫In this case, it's probably the API on your machine.
‫Just like with Docker, and Swarm, and Compose,
‫the kubectl command line can also talk to remote
‫Kubernetes API.
‫Now that you've gotten back the client server versions,
‫you're good to go. If you got an error, it would probably
‫be because the server version doesn't show up and it says
‫it can't connect. That means that somehow, you're
‫misconfigured and your local CLI can't talk
‫to the Kubernetes servers. I would either check how you
‫deployed it to make sure that it's running.
‫Maybe if you're on Docker Desktop, you need to start Docker
‫and then also make sure in the settings that Kubernetes is
‫running. If it's some other way, just check the install
‫video. If you have any issues with that, reach out in the Q
‫& A or in Slack.
‫All right. There's two ways to deploy pods in
‫Kubernetes, really. There's doing it at the command line
‫where you're specifying all the options at the command
‫line. Or, there's using YAML.
‫This might be similar in concept to services
‫and stacks in Swarm, but of course, when you really get
‫down to it, there's a lot of different stuff under the
‫covers. So, I hate to make that analogy, but that's really
‫the two options you have is either command line or YAML.
‫Let's focus on the command line for a few minutes.
‫The first command we're going to run here is
‫kubectl run.
‫So, it's similar to a docker run.
‫My Nginx, and you can call it whatever you want.
‫This is the name of your deployment. And then --image,
‫and we'll specify the image name here.
‫Let's just use Nginx like we're used to and hit return.
‫For a minute, let's ignore the depreciated warning if
‫you're getting that in some of the recent versions of
‫Kubernetes. We'll talk about that in a little bit.
‫But for now, let's see what just happened.
‫We can use that with the kubectl get command.
‫kubectl get pods.
‫What you should see there is you're
‫named object, along with some characters
‫on the end of it, and you'll see that 1 in 1 is running.
‫This is very similar to the services concept
‫in Swarm where we by default just
‫ran one replica.
‫You can see it's name there.
‫Why do we have that weird name?
‫Well, this has to do with the way that the kubectl
‫run command works.
‫When you're using the run as it is right now in Version
‫1.14, that is technically
‫using a Deployment controller.
‫That Deployment controller creates a ReplicaSet controller.
‫That ReplicateSet controller then creates the pods.
‫In this case, it's just one replica.
‫So, it's only one pod.
‫If we did a kubectl get all, you
‫would then see all the objects there listed.
‫You'll see pods.
‫Ignore the service for now.
‫We'll talk about that in a little bit.
‫The Deployment and in the ReplicaSet.
‫You can see these different layers of the
‫object model and Kubernetes coming out here where we just
‫did a single command, but it actually created multiple
‫objects for us.
‫Let's go to my drawing board and describe how
‫these objects relate to each other.
‫As you've seen in Kubernetes, we have more levels
‫of abstraction and control than we did previously
‫in Swarm or in Docker itself.
‫In this case, when we did the kubectl run,
‫it, in the background, created multiple,
‫different abstractions automatically for us.
‫It created the pod, but it also created around that a
‫ReplicaSet, and around that, a Deployment.
‫Let's go to the drawing board, and I'll show you how these
‫abstractions relate to each other.
‫As a reminder, we have Docker running underneath.
‫Then we have some containers running that are managing
‫Kubernetes, and I won't talk about those right now.
‫Let's just know that we have this different set
‫of containers over here just to run Kube.
‫When we did the kubectl run,
‫what it created was obviously our Nginx container, that
‫was the part that we know about.
‫But, the different levels of control, or abstractions,
‫are the interesting part.
‫The first one here is the pod.
‫Again, it can run one or more containers inside this pod.
‫As a part of that pod, it could have created volumes if
‫we needed it. It created the NIC
‫for the pod.
‫The way it created that pod was when we typed
‫kubectl run, it created
‫a Deployment.
‫A Deployment controller manages ReplicaSets.
‫We have multiple levels of abstraction.
‫That Deployment was created, and it does things like
‫rolling updates, or Blue/Green Deploys, and
‫a lot of other things that you think about when you think
‫about orchestration services like we had in Swarm services.
‫When that Deployment was created, it created a ReplicaSet
‫of one.
‫That itself is another controller.
‫The ReplicaSet's job is to make sure that the number of
‫pods we asked for are currently running.
‫In this case, we left everything at the default.
‫So, our Deployment created one ReplicaSet, and that
‫ReplicaSet created one pod.
‫We could control each one of these different levels
‫of abstraction. We could type commands to control the
‫Deployment. The ReplicaSet, or the pod itself directly, but
‫usually in these situations, you're always going to be
‫managing the Deployment itself.
‫Then it will take care of the rest.
‫To give you an idea of why the ReplicaSet itself
‫in the middle exists, is if we wanted to
‫create another copy of this pod, just like
‫when we do Swarm service replicas.
‫In my drawing here, I created a copy
‫of that pod.
‫That would be if we scaled the replicas to two.
‫Very similar to how Swarm does it.
‫The ReplicaSet's job, again, is to
‫ensure that two pods are running with the identical
‫template. The Deployment's job is to manage
‫the ReplicaSet configuration.
‫Before we jump to the next lecture, let's delete all
‫of these resources we just created with the run command by
‫using the delete command.
‫This is different than Docker where Docker had the remove
‫command.
‫Now, we're using a delete command with kubectl.
‫You'll notice that we're specifying the type of object and
‫then the name of itself. So, we're doing deployment space,
‫the name of the Deployment.
‫When you do that, it will delete all the things underneath
‫it. The ReplicaSet, the pods themselves and the containers
‫in them.
‫We can verify that quickly with the same get all command.
‫You'll only see the cluster IP there, which is the
‫Kubernetes server itself.