April 19, 2019 By Sai Vennam 5 min read

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:

  1. The apiVersion shouldn’t change when upgrading your application.

  2. Here’s the valid YAML in a Gist: https://ibm.biz/BdzH48

Learn more about Kubernetes and containers

Video Transcript

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.

The 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.

Was this article helpful?
YesNo

More from Cloud

Enhance your data security posture with a no-code approach to application-level encryption

4 min read - Data is the lifeblood of every organization. As your organization’s data footprint expands across the clouds and between your own business lines to drive value, it is essential to secure data at all stages of the cloud adoption and throughout the data lifecycle. While there are different mechanisms available to encrypt data throughout its lifecycle (in transit, at rest and in use), application-level encryption (ALE) provides an additional layer of protection by encrypting data at its source. ALE can enhance…

Attention new clients: exciting financial incentives for VMware Cloud Foundation on IBM Cloud

4 min read - New client specials: Get up to 50% off when you commit to a 1- or 3-year term contract on new VCF-as-a-Service offerings, plus an additional value of up to USD 200K in credits through 30 June 2025 when you migrate your VMware workloads to IBM Cloud®.1 Low starting prices: On-demand VCF-as-a-Service deployments begin under USD 200 per month.2 The IBM Cloud benefit: See the potential for a 201%3 return on investment (ROI) over 3 years with reduced downtime, cost and…

The history of the central processing unit (CPU)

10 min read - The central processing unit (CPU) is the computer’s brain. It handles the assignment and processing of tasks, in addition to functions that make a computer run. There’s no way to overstate the importance of the CPU to computing. Virtually all computer systems contain, at the least, some type of basic CPU. Regardless of whether they’re used in personal computers (PCs), laptops, tablets, smartphones or even in supercomputers whose output is so strong it must be measured in floating-point operations per…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters