Home pageGimlet

Your first three kubectl commands when troubleshooting Kubernetes applications

Laszlo Fogas
Laszlo Fogas

Troubleshooting is an inevitable part of the Kubernetes journey. It's the art of identifying and resolving issues that might disrupt the smooth operation of your applications.

In this guide, we're showing you our first three kubectl commands when we start troubleshooting Kubernetes applications.

Starting point - kubectl get pods

Every troubleshooting journey begins with understanding your environment. The kubectl get pods command is your first step to gathering insights about the status of pods in your cluster.

Important variants:

  • The kubectl get pod <pod-name> -o yaml command provides a comprehensive YAML description of a pod, including all its fields.
  • The -A switch. kubectl get pods -A allows you to view pods across all namespaces.
  • Use the -w switch for continuous watching for changes.
  • And of course, don't be afraid to feed the results into a grep command. kubectl get pods -A | grep <app-name> to efficiently filter pods with a specific name or kubectl get pods -A | grep -v "Running" to look at all pods that are not in a running state.

Dive into logs - kubectl logs

The kubectl logs command gives you access to container logs within pods.

It takes the well known -f argument to stream the latest log entries and you can call kubectl logs on pods and deployments. kubectl logs -f deploy/<your-app> has the advantage over just looking at the logs of a single pod that it shows logs from all pods of the deployment at once. Also, you don't have to reference the exact name of a pod.

There is a twist to logs: Kubernetes pods often host multiple containers. You may need to provide the -c switch to the logs command to look at the logs of the desired container. You can use kubectl describe to learn about the names of the containers in a pod.

In-depth analysis - kubectl describe

Sometimes, logs alone don't tell the whole story. That's where the kubectl describe pod <pod> command comes in. It provides an in-depth description of your pod, including container statuses, events, and conditions.

Most importantly, it reveals Kubernetes events that can hold the key to finding the root cause of issues. However, keep in mind that pod events disappear after an hour. If you don't stream Kubernetes events to a logging aggregator, the best chance you have to catch the Kubernetes event that reveals the root cause is to restart your application then run kubectl describe periodically to see error events rolling in.

To restart an application:

  • You can delete a single pod with kubectl delete pod - the Kubernetes scheduler will start a new one for you, so essentially you restarted a pod.
  • Or you can restart all pods of a deployment with kubectl rollout restart deploy/<deployment>

Try them out

With these troubleshooting techniques, you're well-equipped to handle Kubernetes challenges. Troubleshooting is a skill that gets better with practice, so apply what you've learned to your Kubernetes deployments.

More from our blog

Clickops over gitops

Doing cloud operations by clicking on a dashboard that generates a stream of infrastructure as code changes.

The how and why we built our SaaS platform on Hetzner and Kubernetes

Hetzner is 5 times cheaper for us than the hyperscalers. This blog posts enumerates the how and why we built our SaaS on a discount bare metal provider. Gotchas included.

Announcing the Gimlet SaaS Early Access

We have something really exciting to share with you: Gimlet is going SaaS. In other words, you will be able to use Gimlet's unparalleled Kubernetes deploy experience with even fewer clicks than before.

How Flux broke the CI/CD feedback loop, and how we pieced it back together

A green build used to mean a successful deploy. But then gitops came and broke this heuristic.

Are you sure none of your containers run as root?

The Kyverno policy engine just arrived in Gimlet Stack. Let's see how you can be certain that none of the containers run as root in your Kubernetes cluster.