Introduction to Kubernetes: Container Orchestration Made Simple

As an application grows across multiple machines, operators need a consistent way to schedule containers, replace failed replicas, publish services, and roll out changes. Kubernetes provides APIs and controllers for that work.

What is Kubernetes?

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Originally developed by Google, it's now maintained by the Cloud Native Computing Foundation (CNCF).

Why Do You Need Kubernetes?

The Problem with Manual Container Management

Imagine managing 100+ containers manually:

Deployment: Deploying updates across multiple servers
Scaling: Adding/removing containers based on demand
Health Monitoring: Restarting failed containers
Load Balancing: Distributing traffic efficiently
Service Discovery: Containers finding and communicating with each other

The Kubernetes Solution

Kubernetes automates all of this and more:

Controlled Deployment: Rolling updates with configurable availability; readiness probes, capacity, and disruption settings still determine whether users see downtime
Auto-scaling: Scale based on CPU, memory, or custom metrics
Self-healing: Automatically restart failed containers
Load Balancing: Built-in service discovery and load balancing
Storage Orchestration: Automatically mount storage systems

Core Kubernetes Concepts

1. Pods

The smallest deployable unit in Kubernetes:

Usually contains one container
Shares network and storage
Ephemeral - can be created and destroyed

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app
    image: my-app:latest
    ports:
    - containerPort: 8080

2. Deployments

Manages a set of identical pods:

Ensures desired number of replicas
Handles rolling updates
Provides rollback capabilities

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        ports:
        - containerPort: 8080

3. Services

Provides stable networking for pods:

Load balances traffic across pods
Provides service discovery
Abstracts pod IP addresses

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

4. Namespaces

Logical scopes within a cluster:

Organize resources by team, project, or environment
Scope names and many RBAC permissions
Do not provide a security boundary by themselves; isolation also requires controls such as RBAC, NetworkPolicy, quotas, and workload security settings

Kubernetes Architecture

Control Plane Components

API Server: Frontend for Kubernetes control plane
etcd: Distributed key-value store for cluster data
Scheduler: Assigns pods to nodes
Controller Manager: Runs controller processes

Worker Node Components

kubelet: Agent that runs on each node
kube-proxy: Network proxy for services
Container Runtime: A Container Runtime Interface (CRI) implementation such as containerd or CRI-O. Docker Engine requires an additional CRI adapter because the in-tree dockershim was removed in Kubernetes 1.24.

Getting Started with Kubernetes

Local Development Options

1. Minikube

# Install minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# Start cluster
minikube start

# Check status
kubectl cluster-info

2. Docker Desktop

Enable Kubernetes in Docker Desktop settings
Provides single-node cluster for development

3. Kind (Kubernetes in Docker)

# Install kind
go install sigs.k8s.io/kind@latest

# Create cluster
kind create cluster --name my-cluster

# Use cluster
kubectl cluster-info --context kind-my-cluster

Essential kubectl Commands

# Cluster information
kubectl cluster-info
kubectl get nodes

# Pod management
kubectl get pods
kubectl apply -f pod.yaml
kubectl delete pod <pod-name>
kubectl logs <pod-name>
kubectl exec -it <pod-name> -- /bin/sh

# Deployment management
kubectl get deployments
kubectl create deployment my-app --image=nginx
kubectl scale deployment my-app --replicas=5
kubectl rollout status deployment/my-app

# Service management
kubectl get services
kubectl expose deployment my-app --port=80 --type=LoadBalancer

# Debugging
kubectl describe pod <pod-name>
kubectl get events
kubectl top nodes
kubectl top pods

Worked Example: Deploying a Stateless Web Application

This example keeps the first deployment focused on a stateless workload. A production database needs persistent storage, backup and restore procedures, upgrade planning, credentials from an external secret workflow, and failure testing. It should not be copied from a minimal Deployment snippet.

1. Application Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: registry.example.com/web-app:1.0.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 3
          periodSeconds: 5
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            memory: 256Mi

Use an immutable image digest in production when the registry and release process support it. The readiness probe prevents a Pod from receiving Service traffic until the application reports that it is ready.

2. Application Service

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

Save both resources in web-app.yaml, then apply and verify them:

kubectl apply -f web-app.yaml
kubectl rollout status deployment/web-app
kubectl get pods -l app=web-app
kubectl get service web-app

A ClusterIP Service is reachable only inside the cluster. Add an Ingress, Gateway API implementation, or LoadBalancer Service when external traffic is required, based on the capabilities of the cluster provider.

Advanced Features

1. ConfigMaps and Secrets

Store non-sensitive configuration in ConfigMaps and secret material in Secrets or an external secret provider:

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_host: postgres-service
  app_mode: production

---
# Secret
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  database_password: cGxhY2Vob2xkZXI=  # "placeholder"; do not commit a real credential

Base64 encoding is not encryption. Enable encryption at rest for Kubernetes API data, restrict Secret access with RBAC, and avoid committing real secret values to source control.

2. Horizontal Pod Autoscaler

Automatically scale based on metrics:

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

3. Ingress Controllers

Manage external access to services:

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

Best Practices

1. Resource Management

Set resource requests and limits
Use namespaces for organization
Implement proper RBAC

2. Security

Use least privilege principle
Scan container images
Enable network policies
Use secrets for sensitive data

3. Monitoring and Logging

Implement health checks
Use structured logging
Monitor resource usage
Set up alerting

4. GitOps and CI/CD

Store configurations in Git
Use automated deployments
Implement proper testing
Use rolling updates

Production Considerations

Managed Kubernetes Services

Amazon EKS: AWS managed Kubernetes
Google GKE: Google Cloud managed Kubernetes
Azure AKS: Azure managed Kubernetes
DigitalOcean DOKS: Simple managed Kubernetes

High Availability

Multiple control-plane instances
Node distribution across availability zones
Regular backups of etcd
Disaster recovery planning

Next Steps

Practice: Set up a local cluster and deploy applications
Learn Helm: Package manager for Kubernetes
Explore Operators: Automate complex application management
Study Service Mesh: Istio or Linkerd for advanced networking
Certification: Consider CKA (Certified Kubernetes Administrator)

Conclusion

Kubernetes is useful when its reconciliation and scheduling model addresses a real multi-host operational need. A local cluster is enough to learn the API, but production readiness also depends on identity, networking, storage, observability, upgrades, and failure recovery.

The next useful step is to deploy one stateless service, observe its rollout, deliberately break its readiness check, and inspect the resulting events before adding more platform features.