$ cat post/compile-errors-clear-/-memory-i-can-not-free-/-disk-full-on-impact.md

compile errors clear / memory I can not free / disk full on impact


Title: Kubernetes Wars and the Joy of Debugging


May 16, 2016. It’s a typical day in tech-land, with Kubernetes still warring for its container crown against Docker Swarm and others. I’m sitting at my desk, sipping on an early morning coffee, as I dive into some code that’s been bugging me all week.

The Setup

We’re using Kubernetes to manage our cluster of microservices, but lately, something’s not right. The application logs are spilling secrets about misbehaving pods, and the pain is slowly creeping up my spine. Every time I try to resolve a bug, it feels like I’m fighting an uphill battle—except this one seems particularly stubborn.

Debugging a Pod

I start by checking the Kubernetes dashboard for any anomalies. The pod’s logs reveal cryptic messages: Error starting health probe and Failed to create container. It’s not clear what’s going on, but it feels like I’m chasing a ghost.

Deciding to take a different approach, I fire up my terminal and SSH into one of the nodes where the problematic pods are running. Once inside, I start by checking the system logs using journalctl -u kubelet, hoping to find any clues. The output is dense with information, but nothing immediately jumps out.

The Eureka Moment

After some more digging, a thought hits me: it could be a resource limit issue. Kubernetes allows you to set limits on CPU and memory for containers, but if those limits are too tight, the application might not start properly. I check the kube-state-metrics pod in our cluster and see that its requests and limits are set quite low.

I update the deployment configuration file with more generous resource requests and limits. After applying the changes, the problematic pods suddenly come back to life. It’s a relief to see them up and running again, but it also highlights how important it is to have robust monitoring in place.

The Kubernetes Ecosystem

As I sit here reflecting on this debug session, my mind wanders to the broader Kubernetes ecosystem. Helm is gaining traction as a package manager for deploying applications on Kubernetes, making life easier for many teams. Istio and Envoy are also emerging as key players in service mesh, promising better networking and security.

But amidst all this excitement, it’s easy to forget about the basics—like debugging a single pod. I think back to how far we’ve come since the early days of Docker, where everything seemed simpler but was often more difficult to manage at scale.

Lessons Learned

This experience is a reminder that even in today’s complex world of microservices and container orchestration, the fundamentals still matter. Whether it’s writing good code or setting proper resource limits, these are the building blocks that make all the difference.

As I save my work and move on to other tasks for the day, I feel a sense of satisfaction. Debugging is never easy, but sometimes, solving a problem can be its own reward.


That’s it for today. The world keeps spinning, and Kubernetes continues to evolve, but for now, let’s just focus on making our cluster work a little better each day.