Back to Blog
Kubernetes•August 2024•6 min read

Why Kubernetes Wins: The Technical Case for Container Orchestration

By Nadav Erell, CEO

explainerkubernetesbeginnerfor-developers
Why Kubernetes Wins: The Technical Case for Container Orchestration

Your app runs fine on a single server until it doesn't. Then you need three servers. Then ten. Then you need them spread across availability zones. Suddenly you're writing bash scripts to track which container runs where, building health check loops, and waking up at 3am because a node died and nobody noticed.

Kubernetes solves this. It's not magic - it's a declarative system that turns your infrastructure into code: you describe what you want, and Kubernetes makes it happen.

What Kubernetes Actually Does

At its core, Kubernetes is a control loop. You declare a desired state ("I want 3 replicas of my API server, each with 512MB of memory"), and Kubernetes continuously reconciles reality to match that state. If a container crashes, Kubernetes restarts it. If a node dies, Kubernetes reschedules those containers elsewhere.

This isn't theoretical. Here's what a basic deployment looks like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/myorg/api:v2.1.0
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /livez
              port: 8080
            periodSeconds: 10

This YAML file replaces hundreds of lines of deployment scripts. Change the replicas field from 3 to 10, apply it, and Kubernetes spins up 7 new pods automatically. Change the image tag, and Kubernetes performs a rolling update - replacing pods one at a time so your service never goes down.

The Real Benefits (With Specifics)

Self-Healing Infrastructure

When a container dies, Kubernetes restarts it. When a node fails, Kubernetes moves workloads elsewhere. But the key insight is how fast this happens.

With restartPolicy: Always and properly configured probes, a crashed container typically restarts within 10-30 seconds. Compare this to a traditional VM setup where you might not notice a failure for 5-10 minutes (until monitoring alerts), then spend another 10-15 minutes manually restarting the service.

livenessProbe:
  httpGet:
    path: /livez
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3  # After 3 failures (15 seconds), restart the container

Autoscaling That Works

Kubernetes Horizontal Pod Autoscaler (HPA) watches metrics and adjusts replica counts automatically:

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

When CPU hits 70% utilization, Kubernetes adds pods. When traffic drops, it scales down. This isn't a cron job checking metrics every 5 minutes -HPA evaluates every 15 seconds by default and can scale up by 100% of current replicas every 15 seconds during traffic spikes.

Actual Portability

"Run anywhere" is often marketing speak. With Kubernetes, it's closer to reality - but with caveats.

Your Deployment, Service, and ConfigMap YAML files work identically on:

  • Amazon EKS
  • Google GKE
  • Azure AKS
  • Self-managed clusters on bare metal

What doesn't transfer cleanly: LoadBalancer services (each cloud has different annotations), storage classes, IAM integrations, and cloud-specific features like AWS ALB Ingress Controller.

The honest answer: you can move between clouds, but budget 2-4 weeks of engineering work to adapt cloud-specific integrations. That's still better than rewriting your entire deployment system.

Resource Efficiency

Kubernetes bin-packs containers onto nodes based on requested resources. A node with 8GB RAM can run multiple containers that each request 512MB, rather than dedicating entire VMs to each service.

Real-world example: a team running 15 microservices moved from 15 t3.medium EC2 instances (one per service) to a 3-node Kubernetes cluster using t3.xlarge instances. Monthly compute costs dropped from ~$750 to ~$300 - a 60% reduction - while gaining self-healing, autoscaling, and declarative deployments.

What Makes Kubernetes Different From Alternatives

vs. Docker Swarm

Docker Swarm is simpler to set up. You can have a cluster running in 15 minutes. But:

  • No built-in support for custom resource definitions (CRDs) - you can't extend the API
  • Limited ecosystem - no Helm charts, no operators, no Argo CD
  • Smaller community means fewer battle-tested patterns

Swarm works for small, static deployments. Kubernetes wins when you need to grow.

vs. Amazon ECS

ECS is deeply integrated with AWS. If you're all-in on AWS and never plan to leave, ECS is simpler for basic use cases. But:

  • No portability -ECS task definitions don't run anywhere else
  • Weaker ecosystem - no equivalent to Helm, operators, or the CNCF landscape
  • Less community knowledge - harder to hire, fewer Stack Overflow answers

vs. HashiCorp Nomad

Nomad is lightweight and supports non-container workloads (VMs, Java JARs, binaries). It's a solid choice for mixed workloads. But:

  • Smaller ecosystem than Kubernetes
  • Fewer managed offerings (you'll likely run it yourself)
  • Less momentum in the industry

The Honest Tradeoffs

Kubernetes isn't free. Here's what you're signing up for:

Complexity

A minimal production Kubernetes setup requires:

  • The cluster itself (managed or self-hosted)
  • An ingress controller for routing traffic
  • cert-manager for TLS certificates
  • A monitoring stack (Prometheus + Grafana or similar)
  • Log aggregation
  • Secret management

That's 5-6 systems to understand, configure, and maintain before you deploy your first app.

Learning Curve

Kubernetes has its own vocabulary: Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, PersistentVolumeClaims, StatefulSets, DaemonSets, Jobs, CronJobs, ServiceAccounts, RBAC...

Expect 2-4 weeks for a developer to become productive, and 2-3 months for someone to become truly proficient.

Operational Overhead

Even with managed Kubernetes (EKS, GKE, AKS), you're responsible for:

  • Keeping node images updated
  • Managing cluster upgrades (Kubernetes releases every 4 months)
  • Monitoring cluster health and resource usage
  • Debugging networking issues (and there will be networking issues)

Small teams without dedicated DevOps often underestimate this. A team of 5-10 engineers might spend 20-30% of one engineer's time on Kubernetes operations.

When Kubernetes Makes Sense

Kubernetes is worth it when:

  • You're running 5+ services that need to scale independently
  • You need self-healing and automated rollouts
  • You want consistent deployments across environments
  • You're planning for growth (headcount or traffic)

Kubernetes is overkill when:

  • You have 1-2 services with stable traffic
  • Your team is small (< 5 engineers) with no DevOps capacity
  • You're still validating product-market fit

Reducing the Complexity

The Kubernetes learning curve is real, but it doesn't have to block your team. Platforms like Skyhook abstract the operational complexity - handling ingress, TLS, monitoring, and deployments - while keeping your workloads on standard Kubernetes. Your team writes the same Deployment YAML, but you skip the 2-3 months of infrastructure setup.

The goal isn't to hide Kubernetes. It's to get the benefits (self-healing, autoscaling, declarative deployments) without drowning in YAML files for cert-manager, ingress-nginx, and Prometheus.