Why Teams Struggle With Kubernetes — And How to Fix It

2025-01-27 Henrik Jess
Kubernetes DevOps Infrastructure Team Management Cloud Architecture

47 clusters. €92,000/month in cloud spend. A team on the brink of burnout.

I recently read a compelling article about a DevOps team that ditched Kubernetes after years of struggling with its complexity. Their deployment success jumped 89%. Infrastructure costs dropped 62%. Team morale transformed overnight.

Their story resonated because I've lived both sides of it. I've seen teams abandon Kubernetes in frustration. I've also optimized poorly-managed clusters to save 30% monthly while improving reliability. The difference? Understanding why Kubernetes fails — and addressing root causes instead of symptoms.

The Pattern Behind Kubernetes Failures

When teams abandon Kubernetes, the narrative is always similar: too complex, too expensive, team exhausted. But when you dig into specifics, a different pattern emerges.

The team that ran 47 clusters wasn't drowning because of Kubernetes. They were drowning because of architectural decisions that would have created problems on any platform:

The same team spending €23,000/month on control planes alone could have run the same workloads on 3-5 well-architected clusters with proper namespace isolation.

This isn't a Kubernetes problem. It's an adoption problem.

The Hidden Cost of "Simplifying"

Moving away from Kubernetes feels like relief — until you hit the ceiling of simpler alternatives.

What you gain immediately:

What you lose over time:

The migration savings are real. But they come with technical debt that compounds as your architecture grows.

When Kubernetes Is the Wrong Choice

Let's be clear: Kubernetes isn't for everyone. The team that moved to ECS made a rational decision for their context.

You probably don't need Kubernetes if:

For these scenarios, simpler alternatives win:

There's no shame in choosing simplicity when it matches your requirements.

When Kubernetes Is the Right Choice

But if your architecture looks like this, walking away from Kubernetes creates different problems:

You need Kubernetes if:

For distributed systems at scale, alternatives require building custom tooling that replicates what Kubernetes provides.

How to Succeed With Kubernetes

The teams that win with Kubernetes follow patterns that prevent the problems others encounter.

1. Start with Managed Control Planes

Don't run your own control plane. Use EKS, AKS, or GKE.

The team spending €23,000/month on 47 control planes could have run managed Kubernetes for €450-€1,400/month total with proper consolidation.

Benefits of managed Kubernetes:

2. Design for Multi-Tenancy, Not Cluster Proliferation

One cluster per environment, not per service.

Use namespace isolation with resource quotas and RBAC:

apiVersion: v1
kind: Namespace
metadata:
  name: team-alpha
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-alpha-admin
  namespace: team-alpha
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: Group
  name: team-alpha
  apiGroup: rbac.authorization.k8s.io

Result: Isolated teams sharing infrastructure without duplication.

3. Implement Observability From Day One

The team that abandoned Kubernetes ran five monitoring tools with 147 false positive alerts. That's not observability — that's alert fatigue.

Start with the essentials:

# Deploy Prometheus + Grafana on day one
helm install prometheus prometheus-community/kube-prometheus-stack \
  --set prometheus.prometheusSpec.retention=30d \
  --set alertmanager.enabled=true \
  --set grafana.enabled=true

Focus on metrics that matter:

Consolidate tooling: One logging solution (Loki or CloudWatch), one metrics solution (Prometheus), one tracing solution (Tempo or Jaeger).

4. Automate Cost Optimization

The €16,500 cluster I optimized to €11,500 came down to three changes:

Rightsized instance types:

# Before: m5.4xlarge (16 vCPU, 64GB RAM)
# After: m5.xlarge (4 vCPU, 16GB RAM)
# Based on actual utilization data

Implemented autoscaling:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Set resource limits:

resources:
  requests:
    cpu: 200m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Deploy cost monitoring:

# Kubecost for real-time cost allocation (supports EUR pricing)
helm install kubecost kubecost/cost-analyzer \
  --set kubecostToken="your-token-here" \
  --set prometheus.server.global.external_labels.currency="EUR"

5. Invest in Team Training

The learning curve is real. Engineers need structured training, not "figure it out."

Our approach:

ROI: Trained engineers build reliable systems. Untrained engineers create the complexity that drives teams away.

6. Adopt GitOps for Infrastructure as Code

Every change should be declarative, reviewable, and reversible.

# ArgoCD Application manifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-api
spec:
  project: production
  source:
    repoURL: https://github.com/company/k8s-manifests
    targetRevision: main
    path: apps/api
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Benefits:

The Real Choice: Right-Sizing vs. Walking Away

The team that moved from 47 Kubernetes clusters to ECS made a smart decision for their situation. But their problems were solvable without abandoning orchestration.

If they had:

They would have achieved:

What I'd Tell Teams Considering Kubernetes

Start with these questions:

  1. Do we need orchestration? If you have < 10 services, probably not.
  2. Do we have the expertise? If not, can we invest in training?
  3. What's our scale trajectory? Growing fast or relatively stable?
  4. What are our compliance requirements? Audit trails, multi-cloud, zero-trust?
  5. What's our team size? Small teams benefit from simplicity; larger teams need structure.

If you're already using Kubernetes and struggling:

  1. Audit your architecture - Are you over-engineered? (47 clusters is a red flag)
  2. Measure actual costs - Break down control plane, compute, networking, and human time
  3. Assess team capability - Is the problem Kubernetes or lack of training?
  4. Look for quick wins - Consolidate clusters, implement autoscaling, set resource limits
  5. Consider alternatives - But understand what you're trading away

Key Takeaways

Different problems require different tools. For small teams with simple workloads, European PaaS providers like Scalingo or Hetzner Cloud make sense. For distributed systems at scale with multi-cloud and data sovereignty requirements, Kubernetes provides capabilities that alternatives can't match.

The question isn't "Kubernetes vs. no Kubernetes." It's "What problems am I solving, what are my compliance requirements, and what's the right tool for my context?"

About the author: Henrik Jess is a DevOps & MLOps engineer who has seen both successful Kubernetes implementations and expensive mistakes. This article reflects lessons from teams on both sides of the orchestration debate.

← Back to Articles ← Back to Home