What is Kubernetes? A Practical Introduction for Teams Adopting Containers

Containerisation solved the “works on my machine” problem - an application packaged in a container behaves identically on a developer’s laptop and a production server. But one container is manageable. The challenge starts when you have 20, 50, or 200 of them - distributed across multiple servers, needing to communicate with each other, automatically restart after failures, and scale under load.

That is what Kubernetes does: it manages the lifecycle of containers at a scale where manual management becomes impractical.

Where Kubernetes Came From

Kubernetes was created at Google in 2014 as an open-source version of their internal Borg system, which had managed containers at Google-scale for over a decade. In 2015 the project moved under the stewardship of CNCF (Cloud Native Computing Foundation) and has since become the de facto standard for container orchestration.

Today Kubernetes is available as a managed service from all major cloud providers:

• Amazon EKS (Elastic Kubernetes Service)
• Azure AKS (Azure Kubernetes Service)
• Google GKE (Google Kubernetes Engine)

For a detailed comparison of these services in the context of production deployments, see our article on AWS vs Azure container deployment strategies.

Core Kubernetes Concepts

Pod - the Smallest Unit

A pod is the smallest deployable unit in Kubernetes. It contains one or more containers that share networking and storage. In practice most pods contain exactly one container - but sidecar use cases exist (e.g. an Envoy proxy container alongside your application container).

apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  containers:
    - name: api
      image: myapp/api:v2.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"

You do not create pods directly in production. Instead, you use higher-level abstractions.

Deployment - Declarative Pod Management

A Deployment defines the desired state of your application: how many replicas (pods) should run, which container image to use, and how to perform updates. Kubernetes continuously reconciles actual state with the declaration.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: myapp/api:v2.1.0
          ports:
            - containerPort: 8080
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

If a pod dies - Kubernetes automatically spins up a new one. If you update the container image - Kubernetes performs a rolling update with zero downtime.

Service - a Stable Endpoint for Pods

Pods are ephemeral - they come and go. A Service provides a stable network address (ClusterIP, NodePort, or LoadBalancer) at which pods are reachable regardless of which specific instances are currently running.

apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Other services in the cluster communicate with api-server via DNS: http://api-server.default.svc.cluster.local.

Ingress - External Traffic

Ingress manages access from the internet to services inside the cluster. It defines HTTP/HTTPS routing rules - e.g. api.example.com routes to the API service while app.example.com routes to the frontend service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-server
                port:
                  number: 80

Namespace - Logical Isolation

Namespaces divide a cluster into logical groups. Typical approach: production, staging, monitoring. Each namespace gets separate resource limits (ResourceQuota) and network policies (NetworkPolicy).

Autoscaling in Kubernetes

Kubernetes offers three levels of autoscaling:

HPA is the most commonly used. Example: if API pod CPU exceeds 70%, HPA adds replicas. When load drops - it removes the surplus.

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

Kubernetes in Practice - When to Use, When Not To

Adopt Kubernetes when:

• You have 5+ microservices communicating with each other
• You need zero-downtime deployments (rolling updates, canary releases)
• Your application requires elastic scaling (e.g. e-commerce with seasonal peaks)
• You work in a DevOps/GitOps model and want declarative infrastructure
• You plan multi-cloud or want to avoid vendor lock-in at the orchestration layer

Skip Kubernetes when:

• You have 1–3 services with no growth plans → Fargate, Cloud Run, or App Service will suffice
• Your team lacks container experience → containerise first, then K8s
• Budget is tight and the cluster would be undersized (<3 nodes) → K8s operational overhead outweighs the benefits
• Your application is monolithic and you don’t plan to break it into microservices

Managed Kubernetes vs Self-Managed

Recommendation: for production, almost always managed Kubernetes. Self-managed makes sense in edge computing, air-gapped environments, or when compliance requires full control over the control plane.

The Kubernetes Tooling Ecosystem

Kubernetes itself is a platform - for production use you need additional tools:

• Helm - package manager (charts defining sets of K8s resources)
• ArgoCD / Flux - GitOps (cluster state = code in a Git repository)
• Cert-Manager - automatic TLS certificates (Let’s Encrypt)
• Prometheus + Grafana - monitoring and dashboards
• Karpenter - node autoscaling (faster than Cluster Autoscaler)
• Istio / Linkerd - service mesh (mTLS, observability, traffic management)
• Kyverno / OPA Gatekeeper - cluster security policies

For more on how Infrastructure as Code (Terraform) works alongside Kubernetes in production, read our article on building a scalable architecture with AWS, Terraform, and Kubernetes.

First Step: From Docker Compose to Kubernetes

If you run your application today with docker-compose up, moving to K8s requires:

1. Containerisation - every service has a Dockerfile and an image in a registry (ECR, ACR, GCR, Docker Hub)
2. K8s manifests - Deployment + Service for each service (replacing docker-compose.yml)
3. Ingress - instead of exposing ports on the host
4. ConfigMaps / Secrets - instead of .env files
5. Persistence - PersistentVolumeClaims instead of host volumes

For teams migrating from Docker Compose, the kompose tool generates initial K8s manifests - but treat them as a starting point, not production configs.

Kubernetes Costs in the Cloud

Kubernetes cost consists of:

A typical minimal production cluster (3× m5.large nodes, EKS): ~$350–450/mo. This covers control plane, 3 instances, LB, and baseline storage.

Kubernetes cost optimisation is a separate topic. Key techniques: Spot/Preemptible instances for interruptible workloads, right-sizing nodes, and Savings Plans for stable baseline. More on AWS discount mechanisms in our article on Savings Plans vs Reserved Instances.

Summary

Kubernetes is not a tool - it is a platform on which you build production infrastructure. It solves real problems: zero-downtime deployments, automatic scaling, self-healing, declarative state management. But it also introduces operational complexity that only makes sense above a certain scale (5+ services, HA requirements, need for elasticity).

If your team is at the containerisation stage - start by understanding container engines. If you already have containers in Docker Compose and are wondering how to scale in the cloud - Kubernetes (managed: EKS, AKS, or GKE) is the natural next step.

Planning a Kubernetes deployment?

We design EKS, AKS, and GKE clusters from architecture through GitOps. Book a free 30-minute technical consultation.

Book a call

Frequently Asked Questions

Is Kubernetes free?

Kubernetes as an open-source project is free. Costs arise from infrastructure: servers (nodes), load balancers, storage. In managed K8s (EKS, GKE) there is a control plane fee (~$73/mo). AKS offers a free control plane in the standard tier.

How long does it take to deploy Kubernetes?

For a team with container experience: 2–4 weeks for a production cluster with CI/CD. For a team new to K8s: 6–8 weeks including learning and migrating first services.

Kubernetes vs Docker - what is the difference?

Docker creates and runs containers. Kubernetes manages many containers across many servers - deciding where to run them, how to scale, how to handle failures, and how to distribute traffic. Docker is the container engine; Kubernetes is the orchestrator.

Do I need Kubernetes for microservices?

Not required, but it is the most popular choice. Alternatives: AWS ECS/Fargate, Azure Container Apps, Google Cloud Run. Kubernetes gives the most control and portability across clouds, at the cost of higher operational complexity.

How do I start learning Kubernetes?

1. Master Docker and containerisation
2. Install minikube or kind locally
3. Practice creating pods, deployments, and services with kubectl
4. Deploy a simple application (frontend + backend + database)
5. Add Ingress, HPA, and monitoring