- TechOps Examples
- Posts
- Kubernetes Troubleshooting Commands Every DevOps Engineer Must Know
Kubernetes Troubleshooting Commands Every DevOps Engineer Must Know
Govardhana M K
January 09, 2025
In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.
👋 Before we begin... a big thank you to today's sponsor WRITER
Writer RAG tool: build production-ready RAG apps in minutes
RAG in just a few lines of code? We’ve launched a predefined RAG tool on our developer platform, making it easy to bring your data into a Knowledge Graph and interact with it with AI. With a single API call, writer LLMs will intelligently call the RAG tool to chat with your data.
Integrated into Writer’s full-stack platform, it eliminates the need for complex vendor RAG setups, making it quick to build scalable, highly accurate AI workflows just by passing a graph ID of your data as a parameter to your RAG tool.
IN TODAY'S EDITION
🧠 Use Case
Kubernetes Troubleshooting Commands Every DevOps Engineer Must Know
🚀 Top News
👀 Remote Jobs
Degate is hiring a DevOps Engineer
Remote Location: Worldwide
Canonical is hiring a Site Reliability Engineer
Remote Location: Worldwide
📚️ Resources
📢 Reddit Threads
👋 Everyone says keep up with the latest trends, no one tells you how - I recommend.
|
🛠️ TOOL OF THE DAY
KubeBlocks - open source control plane software that runs and manages multiple popular database engines on K8s.
🧠 USE CASE
Kubernetes Troubleshooting Commands Every DevOps Engineer Must Know
Day in day out from debugging crashing pods to scaling deployments, we the Kubernetes practitioners are tied to running commands.
But here's the catch: Kubernetes commands and logs are inseparable.
While commands help you interact with the cluster, logs are the guiding light in the right direction.
However, many practitioners jump straight into commands without touching on the basics of Kubernetes logs - where they’re stored, how they’re structured, and how to locate the right log for effective troubleshooting.
Here, I’ve made the image below that illustrates the Kubernetes log directory structure - this is your starting point for any troubleshooting journey.
Top Kubernetes Troubleshooting Commands Every DevOps Engineer Must Know
kubectl get pods --all-namespaces: Check pod statuses across all namespaces.
kubectl describe pod <pod_name>: Gather detailed information about a specific pod.
kubectl logs <pod_name> -c <container_name>: View logs of a specific container.
kubectl get events --sort-by='.metadata.creationTimestamp': Review recent events for errors.
kubectl get nodes: Verify the health and status of cluster nodes.
kubectl drain <node_name> --ignore-daemonsets: Safely evacuate pods from a node.
kubectl cordon <node_name>: Mark a node as unschedulable.
kubectl uncordon <node_name>: Mark a node as schedulable again.
kubectl delete pod <pod_name> --grace-period=0 --force: Forcefully delete a crashed pod.
kubectl rollout undo deployment <deployment_name>: Roll back a problematic deployment.
kubectl exec -it <pod_name> -- /bin/sh: Access a container for debugging.
kubectl get componentstatuses: Check the health of core cluster components.
kubectl top nodes: Monitor node resource usage for bottlenecks.
kubectl top pods --all-namespaces: Identify resource-hungry pods.
kubectl delete node <node_name>: Remove a failed node from the cluster.
kubectl get ingress: Verify ingress resources and their statuses.
kubectl describe <resource_type> <resource_name>: Detailed information for a resource.
kubectl port-forward <pod_name> <local_port>:<remote_port>: Forward a local port to a pod.
kubectl get endpoints <service_name>: Verify service endpoints.
kubectl apply -f <backup.yaml>: Restore configurations from a backup manifest.
kubectl taint nodes <node_name> key=value:NoSchedule: Prevent scheduling on a problematic node.
kubectl debug <pod_name>: Launch an ephemeral container for troubleshooting.
kubectl edit <resource_type> <resource_name>: Manually modify resource configurations.
kubectl proxy: Start a proxy to the Kubernetes API for debugging.
Logs are the why, and commands are the how.
By mastering both, you’re not just running commands—you’re orchestrating success.
90% of cloud infrastructure operates on Linux.
1.3% of the top 1M web servers run on Linux.
85% of containers are deployed on Linux.And,
The majority of Kubernetes clusters run on Linux.
The majority of Docker images are built on Linux.In short,
DevOps and Cloud… x.com/i/web/status/1…— Govardhana Miriyala Kannaiah (@govardhana_mk)
3:28 AM • Dec 30, 2024
You may even like: