There are people who work with Kubernetes sometimes.
Then there are Kubernetes people who work with it and think about it all the time.
Kubernetes people have opinions about resource requests. They see an upgrade deadline and start thinking about API changes, add-ons, workload dependencies, testing, and rollback plans. They hear that a cluster is fine and ask a follow-up question: Fine how?
Fairwinds is full of Kubernetes people. It’s what we work on every day, and it is the foundation for how we think about managing Kubernetes for our clients.
Getting a cluster running is an accomplishment. Keeping it healthy, secure, current, and usable for application teams is the actual work.
That work doesn’t fit neatly inside a box. A Kubernetes environment has workloads, networking, identity, policies, observability, deployment workflows, and of course all the people trying to ship applications without opening an infrastructure ticket for every change.
A cluster can serve traffic today while piling up technical debt for tomorrow.
Maybe version upgrades keep moving down the roadmap. Maybe add-on updates have fallen behind. Maybe every application team has developed its own way of configuring things. Maybe one person has become the default owner of a platform that now supports a large part of your business.
We’re Kubernetes people, and we recognize those patterns because we have seen them before. We know which question to ask first, which backlog item can wait, and which small problem is about to become everyone’s Friday afternoon headache.
CPU and memory requests are just numbers in a YAML file until the scheduler uses them to decide where your application can run.
A workload might be using relatively little CPU while its request tells the scheduler that the node has no room left. That can affect placement, capacity decisions, and cloud spend. The problem doesn’t always look dramatic in a dashboard. Sometimes it shows up as a cluster adding capacity that doesn’t make sense until you look at the requests.
This is the part where Kubernetes people start asking to see the YAML.
They want to know how resources are configured, how workloads are distributed, whether requests match actual use, and what those settings mean for the wider cluster. They know a resource guess in one manifest can affect placement, capacity, and cloud spend farther downstream.
CTO Andy Suderman created Goldilocks because someone has to question whether that 4 CPU request actually makes sense. Goldilocks gives teams automated resource recommendations, replacing guesswork with a clear, data-driven starting point.
Kubernetes releases keep coming, and each one eventually puts an upgrade on your calendar. Let a few versions stack up, and you are not just catching up on Kubernetes. You’re checking deprecated APIs, add-on compatibility, node versions, workload behavior, and whether each environment is ready for the next step.
That’s before anyone asks about the rollback plan.
Kubernetes people don’t panic at the sight of an upgrade.
They do ask whether anyone has checked the add-ons.
They ask which APIs are in use, who owns the testing, and what the rollback plan looks like. They ask whether the team has time to complete the work before the upgrade becomes urgent.
This might sound like a lot of questions. It is. Kubernetes has earned them.
When add-ons fall behind, the question is rarely just whether a newer version exists. It is whether that version works with the cluster, the other add-ons, and the workloads depending on them.
Fairwinds has spent enough time with this problem to know that Kubernetes add-ons need some love. Somebody has to keep track of the components everyone relies on, otherwise an upgrade might make them the most stressful part of the week.
Most people look at dashboards, logs, and alerts when something happens in a Kubernetes cluster. Kubernetes people sometimes ask whether the cluster could make a sound instead.
Could sound provide another way to understand what is happening in a Kubernetes cluster?
That question led Stevie Caldwell, Fairwinds’ Senior Technical Lead for Cloud Platforms and Kubernetes, to turn live Kubernetes events into sound for a KubeCon EU demo. Pods starting, pods stopping, deployments scaling, and crash loops each get their own audio behavior. A crash loop gets a repeating pattern that builds as the restart count rises.
You can hear Kubernetes sing for yourself in her post outlining the experiment.
Yes, there really are Kubernetes people.
Kubernetes turned 10 in 2024.
Fairwinds marked the occasion by writing a Kubernetes birthday song, set to the tune of Come On Eileen.
The team recorded it with electronic drums, guitar, recorder, and bass. You can listen to the Kubernetes ditty if you’d like to hear it.
This may not appear in every standard Kubernetes operations playbook.
It does say something about the people who work here, though. They care about the technical work, they know the history, and they have spent enough time with the platform to enjoy writing, recording, and performing a song about it.
That’s a specific kind of dedication.
A single SRE can do a remarkable amount of work.
They can manage clusters, respond to incidents, work through upgrades, review vulnerabilities, support developers, answer compliance questions, and help the business move faster. They can also become the person everyone calls when something, somewhere in the platform needs attention.
That arrangement usually works until it doesn’t.
Fairwinds has worked with organizations where developers were able to create their own Kubernetes environments, but nobody had the bandwidth to manage the ongoing operational work across those clusters.
Kubernetes people notice when all that expertise is sitting with one person.
They also notice when that person is on vacation, because suddenly everyone is looking for another person with answers.
A platform decision isn’t just about the initial implementation.
A new cluster needs ongoing maintenance. A policy needs to work with how developers actually deploy. A security control needs evidence for auditors. An add-on needs an owner and a plan for upgrades. A workload pattern that made sense six months ago may need another look after the environment grows or changes.
The ongoing work is where platform teams spend the most time.
Fairwinds helps teams manage that work. We support Kubernetes operations, upgrades, patching, add-on management, policy and compliance needs, and the day-to-day questions that come with running Kubernetes in production. The goal is to give your internal teams more room for the platform work that supports your developers and your business.
You might be a Kubernetes person too...
If you’ve ever opened a manifest during a meeting that was supposed to be about something else because you just had to see what was going wrong.
If an upgrade plan made you ask about add-ons before anyone said the word timeline.
If you know that the difference between a working cluster and a workable platform is usually a lot of attention over time.
If you built an audio system so you could hear pods start, crash loop, and scale.
And you might be a Kubernetes person if you wrote a birthday song for Kubernetes.
That’s Fairwinds. We’re the Kubernetes people. And if you’d rather build your product than wrestle with cluster upgrades, resource limits, and add-on matrixes, we’re here to take care of the platform for you.