Whether you are debugging a crashing pod a scheduling delay or a sudden cluster issue you need to know exactly where to look. This can save hours and protect your production.

Most engineers stop at container logs or use only kubectl logs.

Experienced engineers go deeper. They check node logs kubelet logs control plane logs container runtime logs and CNI plugin logs.

To make this easier I have broken down Kubernetes logging into two practical views.

First I have shared a table that outlines the main Kubernetes log types their file paths and what each one means.

Use it as a quick reference when you are troubleshooting.

Download a high resolution copy of this diagram here for future reference.

Next I have included a visual layout of how these logs are structured under the var log directory.

This helps you follow the issue from the container level to the control plane.

Download a high resolution copy of this diagram here for future reference.

My experience says:

➤ Always check both container logs and pod logs when diagnosing container issues

➤ Review error log files under kubelet the API server and the scheduler to uncover hidden problems

➤ For pods stuck in the ContainerCreating state inspect CNI logs such as flannel log or calico log

➤ Use syslog messages dmesg log and auth log to examine node level or system problems

➤ For access and permission issues check the audit logs of the API server especially with RBAC

When you know where the logs are you stop guessing and start fixing

Many Cloud Engineers don’t fully understand AWS Data Transfer costs, their complications, and implications.
Here, We’ve made this to help you better understand.
45K+ read our free newsletter: techopsexamples.com/subscribe
What do we cover:
DevOps, Cloud, Kubernets, IaC, GitOps,
— TechOps Examples (@techopsexamples)
4:31 AM • Apr 24, 2025

Looking to promote your company, product, service, or event to 45,000+ Cloud Native Professionals? Let's work together.