Kubernetes deployment overview and useful debugging commands
You may have already checked out our lightboarding videos on “Kubernetes Explained” and “Kubernetes vs. Docker: It’s Not an Either/Or Question,” and I’m excited to bring you guys a new video format that is going to take a deeper dive on Kubernetes deployments.
Deploying your applications to Kubernetes doesn’t have to be difficult. I’m going to go over the elements of a deployment, look at how to use a YAML to deploy a sample app, update a deployment, and even delete a deployment. In case you run into any problems along the way, I’ll finish up with some useful Kubernetes deployment debugging commands.
I hope you guys enjoy the video!
Note: We accidentally left some small errors in the YAML during post-production:
The apiVersion shouldn’t change when upgrading your application.
Here’s the valid YAML in a Gist: https://ibm.biz/BdzH48
Learn more about Kubernetes and containers
Full IBM Cloud YouTube lightboarding video playlist here
Kubernetes Deployments: Get Started Fast
Hi everyone, my name is Sai Vennam with the IBM Cloud team. Today, I want to talk about Kubernetes deployments. Deploying your applications to Kubernetes doesn’t have to be difficult, but first, let’s introduce what a pod is.
What is a Kubernetes pod?
A pod is the smallest logical unit that you can deploy into a Kubernetes cluster. However, to really harness the power of Kubernetes, you need to deploy those pods using the Kubernetes deployment resource.
Using YAML to deploy a sample app
Kubernetes resources are managed using YAML. And here, we’ve got some YAML that defines how to deploy a sample application into Kubernetes.
Taking a look at the YAML, starting at the top, we can say things like that kind of resource that it is—so we see that it’s a deployment. In addition, we define some metadata and the name for this artifact. (Link to full YAML in Gist: https://ibm.biz/BdzH48)
Going a little bit lower, we can see that we define the number of replicas that we want this Kubernetes deployment to manage as well as a match selector, which connects the pods to this deployment resource.
Finally, at the bottom, we see the template—this is the most important part of a Kubernetes deployment and defines the pod that it will be deploying. In here, we can see things like the name of the image as well as things like the port that it will listen on and various configuration like environment variables.
We’ll take this YAML, and using kubectl, a CLI tool, we’ll deploy that YAML into a Kubernetes cluster, at which point Kubernetes will create a deployment resource, which in turn creates a ReplicaSet. A ReplicaSet is simply there to manage identical copies of a pod and to make sure they’re running and healthy.
Updating a deployment
Next, let’s talk about updating that deployment. So, we’ll go back to the YAML, and let’s say that we want to up the number of replicas from two to three, and we will also change the image. Maybe we’ll go from v1 of the application to v2.
After we make the changes to the YAML file, we’ll deploy it using kubectl, at which point Kubernetes recognizes the change to that deployment and creates a new ReplicaSet with that new image and the number of replicas. Kubernetes will then do a rolling update to make sure no downtime this happening while those pods are being updated to the new version of that image.
Deleting a deployment
Finally, what about deleting a deployment? With Kubernetes, using the same YAML that you used to actually create that resource, you can also delete those same resources. By using another kubectl command, you can pass that deployment YAML in and delete those resources from Kubernetes.
Kubernetes deployment debugging commands
Life is good when all of your applications are working, but let’s talk about some key debugging techniques to figure out when things go wrong. The first one I like to use is
kubectl logs. You can pass in the idea of a pod that was created by that deployment and find logs from the containers running within it.
In fact, you can even use the
--previous flag to find logs from a previously crashed container, which is generally the case if you’re trying to debug something wrong with your containers.
Next, I like to use the
kubectl describe command along with the pod to find any events that have been thrown to help you figure out what went wrong.
kubectl describe command has a lot of output but at the bottom, by taking a look at these events, you can figure out exactly what happened. For example, maybe the wrong port was defined or the wrong image has been pulled.
If neither of those techniques work for you, you can also SSH directly into a pod in Kubernetes and run things like
ps aux to make sure that the right processes are running. You can also check out the file system to identify any logs that might be coming out from the processes running within that pod.
I think those are three major ways that can help you debug any issue with your Kubernetes deployments.