The cluster is the easy part
Standing up a Kubernetes cluster takes an afternoon with modern tooling, whether that is EKS, AKS, or a managed offering from a smaller provider. Getting a team to run production workloads on it confidently takes considerably longer, and this gap is where most adoption timelines fall apart. I earned my CKA certification specifically because I kept seeing organizations treat the cluster build as the project, when the cluster build is closer to the easiest ten percent of the work.
Looking back at rollouts I have been part of, the first ninety days tend to surface the same handful of problems, almost regardless of industry or team size.
1. Nobody owns the platform
Three teams investigating the same cluster-level incident in parallel, each certain it is someone else’s component, is the clearest sign that platform ownership was never actually assigned. Kubernetes is often introduced as a shared platform that multiple application teams will use, but ownership of the platform itself frequently gets left ambiguous in the rush to get the first workload live. A named platform team, even a small one, before the first production workload goes live turns a confusing incident into a known escalation path instead of a three way finger pointing exercise over Slack at midnight.
2. Resource requests and limits are guessed, not measured
Teams moving their first application to Kubernetes usually set CPU and memory requests based on a rough guess or whatever the old virtual machine was sized at. This produces either aggressive over-provisioning that defeats the cost case for containers, or a memory limit set too tight, which gets a pod OOMKilled the moment traffic spikes rather than gracefully throttled. A separate and easily confused failure mode comes from the request side rather than the limit side: setting memory requests too low relative to what a pod actually consumes lets the scheduler pack more pods onto a node than it can really sustain, and once real usage across those pods exceeds what the node can support, the kubelet starts evicting pods under memory pressure to protect the node itself. Both failure modes look similar from a dashboard, a pod restarting or disappearing, but the fix is different: right size limits against real load test data for the OOMKill case, and right size requests against actual measured usage, not the old VM’s spec sheet, for the eviction case. I have found it worth the extra week to load test and tune both properly before declaring an application production ready, rather than discovering the right numbers during an incident at two in the morning.
3. Secrets and configuration management are an afterthought
A plan to fix secrets handling before production almost never survives contact with a deadline. It is common to see teams start with secrets stored directly in manifests or environment variables during early testing, intending to clean it up later, and then watch that intention quietly disappear once the go-live date gets close. A proper secrets management approach, whether that is a cloud provider’s native secrets manager or a tool like Vault, belongs on the day one requirement list rather than the cleanup backlog. On an Azure-based rollout, that usually means Key Vault wired through the Secrets Store CSI driver from the start, not retrofitted after a security review flags plaintext credentials sitting in a ConfigMap six months in.
4. Observability gets bolted on after the first incident
The most common pattern I see is a team that waits until the first serious production incident to realize they cannot actually see what is happening inside the cluster. Logs are scattered, metrics are not centralized, and nobody has a dashboard that shows pod health at a glance. Investing in Prometheus and Grafana, or a managed equivalent, before go live, not after the first outage, is one of the clearest predictors of whether a team trusts the platform six months later.
5. Developers are not trained on the new deployment model
Moving from deploying a build to a virtual machine to deploying through a Kubernetes manifest and a CI pipeline is a real shift in daily workflow for developers, not just for operations. Teams that skip structured onboarding end up with developers who copy and paste manifests they do not fully understand, which creates configuration drift and makes troubleshooting much harder. A short, hands-on training session before the first team migrates, covering what a request, a limit, and a liveness probe actually do and what happens when each one is set wrong, pays for itself within the first incident it prevents. I run this as a half day session with the team’s own manifests on screen rather than a generic slide deck, because developers retain the lesson better when the example that breaks is the exact YAML they will push next week.
What I tell teams before they start
None of these five problems are about Kubernetes itself being difficult. They are about treating the platform as infrastructure instead of as an operating model that the whole organization needs to adapt to. The teams that have the smoothest first ninety days are the ones that budget time for ownership, tuning, secrets, observability, and training before the first production workload moves, rather than treating those as nice to have items once things are already running and the incident count is climbing.
Leave a Reply