eksctl create cluster gets you a running Kubernetes cluster in about fifteen minutes. It does not get you a production-ready platform. The gap between those two things is where most of the pain in Kubernetes adoption actually lives, and it's almost entirely a set of design decisions that have to be made deliberately, not left to defaults.
Namespace and tenancy design comes first
Before any workload runs, decide how teams and environments will be isolated. A single shared namespace is the fastest way to start and the fastest way to end up with RBAC you can't reason about and resource contention you can't diagnose. Namespace-per-team (or namespace-per-service, depending on your org's shape) with enforced RBAC and network policy boundaries is more setup work upfront and dramatically less operational pain later.
Resource governance is not optional at scale
Without default resource requests and limits, one misbehaving workload can starve every other workload on a node. Admission policies (via OPA/Gatekeeper, Kyverno, or built-in LimitRanges) that enforce sane defaults — rather than relying on every engineer remembering to set them — are the difference between "a bug in one service" and "an incident affecting every service on that node."
Decide your deployment model before you have ten services
Retrofitting a deployment strategy after ten teams have each built their own way of shipping to the cluster is far more expensive than choosing one early. Whether that's GitOps via Argo CD, Helm-based CI pipelines, or something else, the platform team should own this decision and provide it as a paved path, not leave every team to reinvent it.
Autoscaling has two layers, and both need tuning
Pod-level autoscaling (HPA, based on CPU, memory or custom metrics) and node-level autoscaling (Cluster Autoscaler, Karpenter) are separate systems that need to agree with each other. A common failure mode: HPA scales pods up correctly, but node autoscaling is too conservative or too slow to provision capacity for them, so pods sit pending during exactly the traffic spike they were meant to handle. Both layers need to be tuned against real traffic patterns, and revisited as those patterns change.
Secrets management is a platform decision, not a per-team one
Kubernetes Secrets are base64-encoded, not encrypted, by default. A production platform needs a real secrets strategy — external secret managers integrated via something like External Secrets Operator, envelope encryption at the etcd level, or a managed cloud secrets service — decided once, at the platform level, rather than left to whatever each team improvises.
Developer self-service is what makes the platform actually used
A platform that requires a ticket to the platform team for every new service will get worked around. The teams we've seen succeed build "golden paths" — templated, opinionated starting points (a Helm chart, a CI template, a namespace provisioning flow) that get a new service running correctly by default, with escape hatches for teams that need something different. This is more platform engineering work upfront, and it's what determines whether the platform gets adopted or bypassed.
None of this is about picking the right YAML
Every one of these is a design decision, not a configuration default. Kubernetes itself doesn't make any of these choices for you — which is exactly why two companies running the same version of the same distribution can have wildly different operational experiences. The platform is the sum of these decisions, made deliberately, not the cluster itself.
Related service