Kubernetes Explained: Pods, Services, Deployments and When You Actually Need It

Kubernetes (often "K8s") is the dominant platform for running containers at scale. It schedules containers across a cluster of machines, keeps them running, scales them, routes traffic to them and rolls out new versions safely. It's also complex, and many teams adopt it long before they need it.

This guide explains the core concepts in plain language, then gives an honest answer to "do we need Kubernetes?"

#Key takeaways

• Kubernetes is a container orchestrator: you declare the desired state, and controllers continuously work to make reality match it.
• Core objects: Pods (running containers), Deployments (manage replicas and rollouts), Services (stable networking), Ingress/Gateway (external HTTP routing), ConfigMaps/Secrets (configuration).
• Set resource requests and limits, health probes and autoscaling for reliable workloads.
• Use a managed Kubernetes service rather than running the control plane yourself.
• For many small teams, simpler platforms are a better fit until complexity justifies Kubernetes.

#The core idea: declarative desired state

Instead of running commands like "start 3 containers on server A", you declare:

"I want 3 replicas of api:1.4.2, each with 500m CPU and 512 MiB of memory, reachable at api.internal."

Kubernetes stores that desired state, and controllers continuously reconcile it. If a node dies, pods are rescheduled elsewhere. If you change the image version, a rolling update begins.

#Cluster architecture (briefly)

textControl plane: API server · scheduler · controller manager · etcd (cluster state)
Worker nodes:  kubelet (runs pods) · container runtime · kube-proxy / networking

With managed services, the cloud provider runs the control plane. You manage workloads, and often node pools.

#Core objects

#Pod

The smallest deployable unit: one or more containers that share networking and storage. Pods are ephemeral: they come and go, and get new IPs when they do. You rarely create them directly.

#Deployment

Manages a set of identical pods (via ReplicaSets), and handles scaling and rolling updates:

yamlapiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxUnavailable: 0, maxSurge: 1 }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8000 }]
          envFrom:
            - configMapRef: { name: api-config }
            - secretRef: { name: api-secrets }
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits: { memory: "512Mi" }
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 8000 }
            periodSeconds: 5
          livenessProbe:
            httpGet: { path: /healthz/live, port: 8000 }
            periodSeconds: 10

#Service

Pods change; Services provide a stable virtual IP and DNS name that load-balances to healthy pods matching a label selector:

yamlapiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector: { app: api }
  ports: [{ port: 80, targetPort: 8000 }]

Other pods can now call http://api.

#Ingress / Gateway API

Routes external HTTP(S) traffic to Services by host and path, with TLS termination, through an ingress controller or Gateway API implementation (how load balancers work).

#ConfigMaps and Secrets

Configuration and sensitive values injected as environment variables or files. Note that Kubernetes Secrets are only base64-encoded by default. Enable encryption at rest, restrict access with RBAC, or integrate an external secret manager.

#Other workload types

• StatefulSet: pods with stable identities and storage (databases, brokers). Running stateful systems on Kubernetes is possible, but managed databases are usually simpler.
• DaemonSet: one pod per node (log collectors, monitoring agents).
• Job / CronJob: run-to-completion and scheduled tasks.

#Health probes

• Readiness probe: is the pod ready to receive traffic? Failing pods are removed from Service endpoints. Essential for zero-downtime rollouts (zero-downtime deployments).
• Liveness probe: is the process stuck? Failing pods are restarted. Keep it simple, and don't check external dependencies, or a database hiccup will restart every pod.
• Startup probe: gives slow-starting apps time before liveness checks begin.

#Resources: requests and limits

• Requests: what the scheduler reserves for the pod, which determines placement.
• Limits: the maximum a container can use. Exceeding the memory limit gets it killed (OOMKilled); CPU is throttled.

Set requests based on observed usage. Missing requests lead to noisy-neighbor problems and poor scheduling; overly tight CPU limits can cause throttling and latency spikes.

#Autoscaling

• Horizontal Pod Autoscaler (HPA): adjusts replica counts based on CPU, memory or custom metrics (requests per second, queue depth).
• Cluster autoscaler / node autoprovisioning: adds or removes nodes when pods can't be scheduled or nodes sit idle.
• Vertical Pod Autoscaler: recommends or adjusts resource requests.

See horizontal vs vertical scaling. Remember the downstream limits: more pods mean more database connections (connection pooling explained).

#The ecosystem you'll need

A production cluster involves more than Kubernetes itself:

• Packaging and deployment: Helm charts, Kustomize, and GitOps tools that sync cluster state from git.
• Observability: metrics, logs and traces (observability explained).
• Security: RBAC, network policies, pod security standards, image scanning, secret management.
• Certificates and DNS automation.
• Service mesh (optional) for mTLS, traffic shifting and advanced routing.

This ecosystem is where much of Kubernetes' operational cost lives.

#Do you actually need Kubernetes?

Kubernetes is a good fit when:

• You run many services (dozens or more) and want a consistent deployment platform.
• You need fine-grained control over scaling, networking, scheduling and multi-tenancy.
• You have (or can build) platform engineering capacity to operate it well.
• You want portability across clouds or on-premises environments.

Consider simpler options when:

• You have a few services and a small team.
• A PaaS or managed container service (serverless containers, app platforms) can run your containers with autoscaling and zero cluster management.
• A VPS with Docker Compose meets your needs today (deploying React + FastAPI on a VPS).
• Your workload is event-driven and spiky, which may suit serverless (serverless explained).

Kubernetes solves real problems, but it's rarely a startup's most important problem. Many teams move to it later, once they've outgrown simpler platforms. Containerizing early (Docker explained) keeps that path open.

#FAQ

#Is Kubernetes hard to learn?

The core concepts (pods, deployments, services) are approachable. Operating production clusters securely and reliably, with networking, storage, upgrades, security and observability, takes significant expertise. Managed services reduce, but don't eliminate, that burden.

#Should I run databases on Kubernetes?

It's possible with StatefulSets and operators, and some teams do it well. For most teams, managed database services are simpler and safer, and keep stateful complexity out of the cluster.

#What's the difference between Docker and Kubernetes?

Docker builds and runs containers (typically on one machine). Kubernetes orchestrates containers across many machines: scheduling, scaling, networking, self-healing and rolling updates.

#Is Kubernetes expensive?

The control plane cost is often modest on managed services, but clusters can be expensive through over-provisioned nodes, idle resources and the engineering time needed to operate them. Right-sizing requests and autoscaling nodes help control costs.