‫If you didn't come directly from the last lecture on this
‫one, go back to the previous lecture to make sure that you
‫have the proper Deployment running so that you will have
‫the logs that we're going to see here in a second.
‫Snce we have that Apache Deployment running in the
‫background, and it has two pods because we scaled
‫the replicas to two. We should be able to do a kubectl
‫get pods and see the results.
‫Of course, your pod names will be slightly different than
‫mine because they'll have the numbers and random characters
‫on the end there. Whenever I am typing it, just
‫realize the last two blocks you will be typing something
‫different based on what your Deployment is showing.
‫There's a few commands, just like with Swarm and with
‫Docker itself. In this case, they're different commands
‫for understanding what's going on in a container and what
‫the orchestrator is doing with containers.
‫The first one is logs.
‫The second one is describe.
‫We don't technically have an inspect command in Kubernetes,
‫but describe does much more than that.
‫First, let's try a logs command.
‫Your output might be slightly different than mine.
‫You'll notice that the first line after we typed in
‫the logs deployment /my-apache.
‫It says found two pods and using
‫a pod name, it gave a specific pod name there.
‫That is because the default log command won't
‫pull all the different pods and combine
‫them together like you would with the Docker or Swarm
‫commands. It's only by default going to pull one of those.
‫Lke other log commands you've been used to in this course,
‫there are lots of options including --follow,
‫--tail.
‫Those are common things for logging commands in any Linux
‫system.
‫If we did that same command with -- just follow,
‫it will then wait for anything new to show up in the logs
‫of that pod. Then --tail, 1
‫just means return the last line only.
‫That way you don't get a huge dump of the logs.
‫You can control C out of that.
‫What if you wanted to see the logs combined for multiple
‫pods?
‫You can certainly do that. That's just not the default logs
‫command. In this case, we're going to have to use something
‫called a Selector in Kubernetes, which is a technique
‫to grab multiple pods based on a label
‫that they all share.
‫The nice thing here is when you use the kubectl run
‫command, it automatically added a label
‫of the name of the Deployment to all these pods.
‫So, we can use that same Deployment name my Apache
‫for selecting all the pods with that label.
‫Note that this is just a simple matching of a
‫label here. So, if you had other Deployments or pods that
‫happen to have this label, they would also be caught up in
‫this too. So, you have to be careful with your labeling and
‫your naming.
‫We're using a -l here to
‫specify the label, and we're specifying the label
‫that the run command applied,
‫which was my Apache.
‫Just like Swarm and Docker itself, these log
‫commands can be very handy for quick troubleshooting
‫but are not the replacement for a full log system.
‫In Kubernetes, by default, it can only pull up
‫to five pods at a time when it uses the
‫selector type of pulling in the logs.
‫You can always increase that, but the reality is it's
‫taxing on the system to pull from all the different nodes
‫these log files.
‫In production, you're going to want a third-party logging
‫system that would collect all these logs and store them
‫over time for quicker retrieval.
‫That's true of really any container orchestration system,
‫whether it's Docker, Swarm or Kubernetes.
‫The next command here would be to describe command.
‫The describe command, in this case, is where we want to
‫specify the pod itself.
‫We want to get a very specific pod, but then we need to
‫know the names of those pods first.
‫So, let's get pods first.
‫Then we can copy and paste one of those names into
‫a describe command.
‫Type pod first.
‫I'll get back that pod.
‫I don't necessarily have to specify that one pod.
‫I could say pods and it would show all pods, which could be
‫a little dangerous if you have lots of pods.
‫You can certainly describe other resources and get back
‫various types of results based on the object.
‫What I wanted to highlight here was that this would
‫be similar to the inspect command in Swarm, or in Docker
‫itself. But, it gives it a little bit nicer display
‫on the screen rather than in JSON.
‫As you scroll down the results, you'll notice that it's not
‫just a description about the different object,
‫but also pulls up things like events at
‫the bottom, which is a great way to get quick status
‫on the current reality of that object.
‫So, in case you were having a problem, maybe with a
‫pod pulling an image, you would see that event
‫here where it would say unable to pull image.
‫That's a common one for when you're accidentally
‫mistyping an image name or something like that.
‫This can be pretty handy for a quick troubleshooting
‫technique without having to go turn on some events
‫or debugging logs.
‫All right. For this last little bit, I'm going to show you
‫how Kubernetes is resilient similar to
‫Swarm where if you delete one of the lower
‫levels of abstraction, in this case if you delete a pod,
‫the higher level abstraction, the Deployment and the
‫ReplicaSet, will make sure that that pod is recreated.
‫That's similar to the way a container or task in Swarm,
‫if you delete it, would be recreated by the service.
‫We're going to do this in two different windows.
‫In the first window, we're going to use a get with a -w.
‫That is going to give us a similar experience
‫to the watch command. If you've ever seen me use the watch
‫command in this course to watch any Linux
‫command, which essentially means to run that thing in the
‫background and you could do that in Linux.
‫But, that watch command is not always available on all
‫OS's. Here, we can do a
‫kubectl get pods
‫but add a -w which will let it sit
‫there and refresh every few seconds.
‫Now, we can go to a different
‫terminal. We're going to delete one of those pods.
‫First. we'll need to copy the name and
‫use a kubectl
‫pod /the name of the pod.
‫You'll notice that it's deleting it.
‫We'll then get this running log up
‫top of the things that are changing.
‫I also like this a little bit better than the watch command
‫because the watch command refreshes the screen, where this
‫shows an ongoing iteration
‫of the changes, which is pretty neat. Down at the bottom,
‫if we did another kubectl get pods,
‫you'll see that we're back to two.
‫Again, this is sort of the self healing aspect of an
‫orchestrator. That's one of the main goals of having one.
‫Lastly, I want to point out something here where you
‫might have been protected in the past from doing certain
‫damaging things in Docker a Swarm, where if you tried to
‫change something or delete something that you shouldn't, it
‫might warn you ahead of time.
‫Kubernetes tends to fall on the other side where it's
‫a little less opinionated about how you use it.
‫Which means that you can sometimes do
‫things that you shouldn't, such as my example earlier of
‫modifying a ReplicaSet instead of modifying the
‫Deployment above it.
‫The same could be true of changing a pod when you
‫really shouldn't be doing that. You should change the object above it.
‫That just stresses that you need to understand the
‫specifics of what you're doing so that you don't accidentally
‫delete, change or modify the wrong thing in the wrong
‫order.
‫Remember to do a kubectl delete deployment my-apache
‫to clean up from this lecture.