Kubernetes 101 — Container Orchestration for Production Applications

If you are running containerised applications in production, you have almost certainly encountered Kubernetes (often abbreviated as K8s). Originally developed by Google and now maintained by the Cloud Native Computing Foundation, Kubernetes has become the de facto standard for container orchestration. But the learning curve can be steep, and the ecosystem is vast. In this guide, we will break down the core concepts you need to understand to start deploying applications on Kubernetes.

Why Kubernetes?

Docker containers solved the packaging problem -- your application and all its dependencies bundled into a portable, reproducible unit. But running containers in production introduces a new set of challenges: How do you deploy across multiple servers? How do you handle failures? How do you scale up during traffic spikes and scale down when demand drops? How do you manage networking between services?

Kubernetes answers all of these questions. It provides a declarative framework for defining how your applications should run, and then continuously works to make reality match your desired state. If a container crashes, Kubernetes restarts it. If a node goes down, Kubernetes reschedules the affected workloads. If traffic increases, Kubernetes scales your deployment automatically.

Core Concepts

Pods

A Pod is the smallest deployable unit in Kubernetes. It represents one or more containers that share networking and storage. In most cases, a Pod contains a single container, but there are legitimate use cases for multi-container Pods (such as a sidecar pattern for logging or service mesh proxies).

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  containers:
  - name: my-app
    image: my-app:1.0.0
    ports:
    - containerPort: 3000
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

In practice, you rarely create Pods directly. Instead, you use higher-level abstractions like Deployments that manage Pods for you.

Deployments

A Deployment defines the desired state for your application: which container image to run, how many replicas, resource limits, and update strategy. Kubernetes continuously monitors the actual state and reconciles it with your desired state.

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: my-app
        image: my-app:1.0.0
        ports:
        - containerPort: 3000

This manifest tells Kubernetes to always maintain three replicas of your application. If a Pod crashes or a node fails, Kubernetes will automatically create a replacement to maintain the desired count.

Services

Pods are ephemeral -- they can be created, destroyed, and moved between nodes at any time. Services provide stable networking for a set of Pods. A Service assigns a stable IP address and DNS name, and load-balances traffic across all matching Pods.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 3000
  type: ClusterIP

There are several Service types. ClusterIP exposes the service only within the cluster. NodePort exposes it on a static port on every node. LoadBalancer provisions a cloud load balancer (on AWS, GCP, or Azure) that routes external traffic to your service.

Ingress

For HTTP/HTTPS traffic, Ingress resources provide more sophisticated routing than Services alone. An Ingress controller (like Nginx Ingress or Traefik) handles TLS termination, path-based routing, host-based routing, and rate limiting.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

Scaling

Kubernetes supports both manual and automatic scaling. You can manually adjust replica counts with a single command:

kubectl scale deployment my-app --replicas=5

For automatic scaling, the Horizontal Pod Autoscaler (HPA) adjusts replica counts based on CPU utilisation, memory usage, or custom metrics. The Vertical Pod Autoscaler (VPA) adjusts resource requests and limits for individual Pods. For cluster-level scaling, the Cluster Autoscaler adds or removes nodes based on pending Pod scheduling.

Configuration and Secrets

Kubernetes provides two mechanisms for managing application configuration:

ConfigMaps store non-sensitive configuration data as key-value pairs or files. They can be mounted as environment variables or volumes.
Secrets store sensitive data like API keys, database passwords, and TLS certificates. They are base64-encoded by default (not encrypted -- for real security, enable encryption at rest or use an external secrets manager like HashiCorp Vault).

Managed Kubernetes Services

Running your own Kubernetes control plane is operationally demanding. Every major cloud provider offers managed Kubernetes services that handle the control plane for you:

Amazon EKS (Elastic Kubernetes Service) -- integrates with AWS networking, IAM, and load balancers.
Google GKE (Google Kubernetes Engine) -- the most mature managed offering, with features like autopilot mode.
Azure AKS (Azure Kubernetes Service) -- deep integration with Azure Active Directory and Azure DevOps.

At StrikingWeb, we strongly recommend managed Kubernetes for production workloads unless you have specific requirements that demand self-managed clusters. The operational overhead of maintaining your own control plane is significant and rarely justified.

When to Use Kubernetes

Kubernetes is powerful but complex. It is worth the investment when:

You are running multiple microservices that need to communicate with each other.
You need automatic scaling based on traffic patterns.
You require zero-downtime deployments with rollback capabilities.
You want portability across cloud providers or hybrid environments.
Your team has (or is willing to develop) the operational expertise to manage it.

If you are running a single monolithic application with predictable traffic, a simpler deployment approach (like AWS ECS with Fargate, or even a well-configured VM) may serve you better with far less operational overhead.

Getting Started

The best way to learn Kubernetes is by doing. Set up a local cluster with Minikube or Kind, deploy a sample application, and experiment with scaling, updates, and failure scenarios. Once you are comfortable with the basics, move to a managed service and start deploying real workloads.

At StrikingWeb, we help teams adopt Kubernetes in a way that matches their maturity level -- from initial architecture design to production deployment and ongoing operations. If you are considering Kubernetes for your infrastructure, we would be happy to help you navigate the journey.

Kubernetes DevOps Containers Cloud