Kubernetes

Every platform team eventually asks: should we build an Internal Developer Platform? The answer is probably yes. The question is how. I’ve seen platforms that cost millions and never got adopted. I’ve also seen scrappy internal tools that transformed developer productivity overnight. The difference isn’t budget or technology — it’s approach. What Is an Internal Developer Platform? An Internal Developer Platform (IDP) is a self-service layer that abstracts infrastructure complexity from developers. Instead of writing Kubernetes YAML, developers describe what they need. The platform handles how. ...

You have Grafana. You have Prometheus metrics. You have logs in Loki and traces in Tempo. You also have 47 dashboards that nobody looks at. Dashboard rot is real. Teams create dashboards for every possible metric, every service, every potential issue. Six months later, nobody remembers what half of them show or why they exist. Good dashboards are different. They get opened daily. They answer questions before you ask. They help you understand your system, not just display numbers. ...

Your cluster looks healthy. Pods are running. Metrics are green. Everything works. Until a node fails during peak traffic. Or the database connection pool exhausts. Or that one service nobody remembers deploying starts consuming all available memory. You can wait for these things to happen in production at 3 AM. Or you can break things intentionally, on your terms, and fix the weaknesses before they become outages. This is chaos engineering. ...

You don’t need a cloud provider to run Kubernetes. You don’t need expensive servers. You need three mini-PCs and an afternoon. This is how I built my homelab cluster — the same cluster that runs my GitLab, monitoring, home automation, and everything else I refuse to trust to someone else’s computer. Why K3s? K3s is Kubernetes, simplified: Single binary — ~70MB, includes everything Low resource — Runs on Raspberry Pi, runs great on mini-PCs Production ready — Same API, same workloads, less overhead Batteries included — Built-in ingress, load balancer, storage It’s not “Kubernetes lite.” It’s Kubernetes without the enterprise cruft. ...

Every Kubernetes cluster eventually needs persistent storage. The question is: which solution? For self-hosted clusters without cloud provider storage classes, two options dominate: Longhorn and Rook-Ceph. Both are CNCF projects. Both provide replicated block storage. Both work well. But they’re very different in philosophy, complexity, and use cases. I’ve run both in production. Let me share what I’ve learned. The Fundamental Difference Longhorn: Simple distributed block storage built for Kubernetes. Each volume is replicated across nodes using standard Linux storage primitives. ...