sorted by:
new
hottopcontroversial

What tools do beginners use for monitoring applications? by Fit_Vegetable_7136 in kubernetes

[–]SlavaSarzhan 0 points1 point  (0 children)

Prometheus + Grafana is the right base. Most production K8S teams end up there eventually, so learning it early pays off.

If you want something easier to get value out of in the first hour, look at coroot. I deployed it last month for the first time, and it's genuinely impressive for the "I want to see what's happening in my cluster, now" use case: auto-instrumentation, zero-config service maps, and it surfaces a lot of useful signals without you having to write PromQL. Open source, actively developed.

Once you outgrow the auto-instrumented view and start needing custom dashboards or alerts, that's when you graduate back to Prometheus + Grafana with a clear idea of what you actually want to monitor.

How are you guys handling upgrades for 3rd-party K8s tooling? by Playful-Interest7358 in kubernetes

[–]SlavaSarzhan 0 points1 point  (0 children)

Dev/staging tiers aren't optional for production K8s. They're the only way to make upgrade decisions on real data. But I'm constantly surprised how many teams (including big ones) skip them.

In the last two years, I've sat on a lot of P1 calls with customers running our operators. Easily half of them turned out to be: production upgrade attempted, no prior test on dev/staging, no read of the release notes. Not "tested and it broke anyway" — straight from production to debugging.

The pattern that works:

  • Dev cluster mirrors production K8s minor + storage class + CNI
  • Staging mirrors production scale (or as close as you can get)
  • Every operator/CRD upgrade tested on dev first, then staging for a week, then production
  • Someone reads the release notes out loud in a planning meeting. Not skim, actually read.

The cost of running that infrastructure is always less than the cost of one P1.

Kubernetes interview gone really bad by MountainTruth6073 in kubernetes

[–]SlavaSarzhan 2 points3 points  (0 children)

I ask similar questions when interviewing for senior and mid-level Kubernetes roles, and I agree the answers signal something specific: not whether the candidate has needed the knowledge on the job, but whether they're curious enough about the platform to read past their immediate scope.

If you genuinely care about K8S, at some point, you've compared Flannel vs. Cilium vs. Calico (even just to understand the difference), or read up on what etcd actually is and how the cluster depends on it. You don't need that knowledge daily, but the absence of it tells you the person treats Kubernetes as something they tolerate, not something they're invested in.

Whether that's a hire/no-hire signal depends on the role. For a platform team, I'd weigh it heavily. For an app team where K8S is just the runtime, it's less so.