What Kubernetes feature looked great on paper but hurt you in prod?

# What Kubernetes feature looked great on paper but hurt you in prod? ## What started the discussion there are features in Kubernetes that look amazing on paper. but in real environments they sometimes introduce more complexity than value. For us a few were * PodDisruptionBudgets that blocked node upgrades * CPU limits causing throttling under burst traffic * Overusing liveness probes → cascading restarts None of these are bad features But they’re easy to misuse. curious what others have experienced. what feature did you initially love… and later regret (or heavily adjust)? ## What stood out in the comments ### Discussion point 1 Allowing developers to set requests & limits. A lot of them were unsure how they should be set and set them the same as the specs of the VMs that the apps were originally running on. We had entire nodes blocked out by pods that were basically sitting idle. ### Discussion point 2 Maybe not k8s specifically but I feel like helm charts are unnecessarily annoying to keep up to date or easily manage at scale ### Discussion point 3 Helm definitely feels simple at first then you end up with 500 line values files, nested overrides nobody remembers and upstream charts that silently break on minor version bumps. Worth trying Kustomize for your own stuff and only keeping Helm for third-party apps. plain YAML is easier to debug ### Discussion point 4 Disagree. DevOps is the way. If the developers are bad at dealing with the running systems, then they need to learn ### Discussion point 5 finalizers are sneaky. everything works fine until you delete something and it just sits there forever waiting for a controller that’s already gone. ## Thread snapshot - Original subreddit: r/kubernetes - Original author: u/Shoddy_5385 - Reddit score: 152 - Comment count: 150 - Original thread: https://www.reddit.com/r/kubernetes/comments/1r9q60h/what_kubernetes_feature_looked_great_on_paper_but/