Kubernetes

Kubernetes is a container orchestration platform. It runs your Docker containers at scale, handles updates, scales up and down automatically, and replaces failed containers. It's powerful but complex, and most startups don't need it.

What Is Kubernetes?

Kubernetes (K8s) solves the problem of running containers at scale. You have 100 Docker containers running across 20 servers. One server fails—Kubernetes automatically moves containers to other servers. You deploy a new version—Kubernetes replaces containers gradually. Traffic spikes—Kubernetes starts more containers. Traffic drops—Kubernetes stops containers.

Without Kubernetes, you manually manage all this. You figure out which containers run on which servers. You manually restart failed containers. You manually scale. This becomes overwhelming quickly.

Kubernetes automates all this. You declare "I want 10 copies of my app running" and Kubernetes makes it happen. This is powerful but comes with complexity.

Key Kubernetes Concepts

Pods: The smallest unit in Kubernetes. A pod typically contains one Docker container (sometimes multiple containers that work together). You don't run containers directly in Kubernetes; you run pods.

Services: Pods are ephemeral—they come and go. Services provide stable network endpoints. A service represents "my API" (which might run on 5 different pods). Users connect to the service; Kubernetes routes traffic to pods behind it.

Deployments: Describe how many replicas of your app should run, which image to use, how to update them. You define a deployment; Kubernetes maintains the desired state.

Namespaces: Logical partitions within a cluster. Different teams' applications can run in different namespaces without interfering.

ConfigMaps and Secrets: Configuration and secrets management within Kubernetes. Similar to environment variables but managed by Kubernetes.

A Simple Kubernetes Deployment

Define a deployment in YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: myregistry/my-app:1.0
        ports:
        - containerPort: 3000

This says: run 3 copies of `myregistry/my-app:1.0`. Each pod exposes port 3000. Kubernetes ensures 3 pods are always running. If one dies, it starts a new one.

Then create a service:

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
  type: LoadBalancer

This creates a load balancer that distributes traffic across the 3 pods. Deploy with `kubectl apply -f deployment.yaml` and you're running.

Kubernetes Cluster Architecture

A Kubernetes cluster has a control plane (manager) and worker nodes (where pods run). The control plane has multiple components: API server, scheduler, controller manager, etcd (database).

You don't typically run Kubernetes yourself. Managed services handle it:

• EKS (AWS Elastic Kubernetes Service): AWS-managed Kubernetes. You provide the nodes; AWS manages the control plane.
• GKE (Google Kubernetes Engine): Google-managed Kubernetes. Integrated with Google Cloud.
• AKS (Azure Kubernetes Service): Microsoft-managed Kubernetes.

Managed services take the pain out of Kubernetes. You don't worry about control plane upgrades or security. That said, you still need to understand Kubernetes concepts.

Rolling Deployments

With traditional deployment, you replace all servers at once. If something is wrong, everything is broken. Kubernetes does rolling deployments: replace old pods gradually.

Update your deployment image version. Kubernetes starts new pods with the new version while old pods continue serving traffic. When new pods are healthy, Kubernetes stops old pods. If new pods fail health checks, Kubernetes rolls back.

This means zero-downtime deployments. Your app is always running. This is how modern teams deploy multiple times per day without incidents.

Horizontal Pod Autoscaling

Tell Kubernetes to automatically scale based on CPU usage:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

This keeps CPU usage at 70%. If traffic spikes and CPU goes to 85%, Kubernetes starts more pods. If traffic drops and CPU goes to 50%, Kubernetes stops pods. Min 2 pods, max 10.

This is powerful: your infrastructure automatically adapts to traffic. You don't need to provision for peak traffic; you start with minimal resources and scale as needed.

When You Need Kubernetes

High traffic, multiple services: Running 50+ containers across multiple servers. Manually managing this is untenable. Kubernetes handles it.

Need for zero-downtime deployments: Rolling deployments, automatic rollbacks. Kubernetes excels here.

Auto-scaling requirements: Traffic varies wildly. Kubernetes auto-scaling saves money and ensures reliability.

Complex orchestration: Multiple services that need to communicate, different scaling policies for different services. Kubernetes manages this.

Compliance/security: Enterprise requirements for network isolation, RBAC, audit logging. Kubernetes supports these.

When You Don't Need Kubernetes

Single application: If you have one application, Kubernetes adds unnecessary complexity. Use a VPS or managed container service.

Predictable traffic: If your application consistently uses the same resources, a fixed server size is simpler and cheaper.

Small team without DevOps expertise: Kubernetes requires operational knowledge. If your team is focused on features, Kubernetes is a distraction.

Startup phase: You're moving fast, changing directions. Infrastructure should be boring. Kubernetes is not boring.

Most startups don't need Kubernetes initially. They use Docker on VMs or managed container services. As they grow and hire DevOps engineers, they might migrate to Kubernetes.

Kubernetes vs Docker Compose

Helm Charts

Writing Kubernetes YAML is verbose. Helm is a package manager for Kubernetes. Helm Charts are templated Kubernetes manifests. Instead of writing 50 lines of YAML, you use a Chart.

Many third-party applications (databases, monitoring tools) provide Helm charts. `helm install postgresql bitnami/postgresql` installs a production-ready PostgreSQL on Kubernetes.

Helm abstracts complexity and reduces copy-paste.

The DevOps Reality

Kubernetes assumes you have DevOps engineers. People who understand networking, Linux, container architecture. If your team doesn't have this expertise, Kubernetes becomes a liability. You spend more time managing infrastructure than building features.

Managed platforms (Vercel, Railway, Render) or managed Kubernetes (EKS, GKE) reduce the operational burden but don't eliminate it. You still need to understand what you're doing.

The Reality

Kubernetes is powerful. It's the standard for large-scale deployments. But it's not a requirement for success. Many successful companies don't use Kubernetes. They use managed platforms or simple container deployments.

Choose based on your actual needs, not hype. If you don't need it, don't use it. Kubernetes adoption should be driven by operational needs, not FOMO.

When you're ready (team size, traffic volume, complexity), Kubernetes will be there. Learn it then. For now, focus on shipping.