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

New 4th Gen Intel Xeon profiles and dynamic network bandwidth shake up the IBM Cloud Bare Metal Servers for VPC portfolio

3 min read - We’re pleased to announce that 4th Gen Intel® Xeon® processors on IBM Cloud Bare Metal Servers for VPC are available on IBM Cloud. Our customers can now provision Intel’s newest microarchitecture inside their own virtual private cloud and gain access to a host of performance enhancements, including more core-to-memory ratios (21 new server profiles/) and dynamic network bandwidth exclusive to IBM Cloud VPC. For anyone keeping track, that’s 3x as many provisioning options than our current 2nd Gen Intel Xeon…

IBM and AWS: Driving the next-gen SAP transformation  

5 min read - SAP is the epicenter of business operations for companies around the world. In fact, 77% of the world’s transactional revenue touches an SAP system, and 92% of the Forbes Global 2000 companies use SAP, according to Frost & Sullivan.   Global challenges related to profitability, supply chains and sustainability are creating economic uncertainty for many companies. Modernizing SAP systems and embracing cloud environments like AWS can provide these companies with a real-time view of their business operations, fueling growth and increasing…

Experience unmatched data resilience with IBM Storage Defender and IBM Storage FlashSystem

3 min read - IBM Storage Defender is a purpose-built end-to-end data resilience solution designed to help businesses rapidly restart essential operations in the event of a cyberattack or other unforeseen events. It simplifies and orchestrates business recovery processes by providing a comprehensive view of data resilience and recoverability across primary and  auxiliary storage in a single interface. IBM Storage Defender deploys AI-powered sensors to quickly detect threats and anomalies. Signals from all available sensors are aggregated by IBM Storage Defender, whether they come…

IBM Newsletters

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