Kubernetes Deployment Guide for Beginners: Building a K8s Cluster from Scratch

Kubernetes Deployment Guide for Beginners: Building a K8s Cluster from Scratch

With two or three servers, Docker Compose is usually enough. But once the application splits into a dozen services, needs automatic scaling, and has to survive node failures, single-machine container orchestration starts to strain. Kubernetes (K8s) was built for exactly that scale — it handles container scheduling, scaling, self-healing, and rolling updates, and has become the "operating system" of the cloud-native era. This article starts with the concepts and walks you through standing up a hands-on cluster locally with minikube.

1. Core Concepts

Start with a minimal mental model. These are the objects you will touch day in, day out:

Understanding Pods is the foundation for everything else. A Pod is the smallest unit of scheduling, and containers inside one Pod share a single IP. A Service converges the ever-changing Pod IPs into one stable entry point, so clients only need to remember the Service name.

2. Local Setup (Minikube)

No need to buy three servers first. Minikube runs a single-node cluster locally — more than enough for learning and experimentation:

# Install minikube
brew install minikube

# Start cluster (with CPU and memory limits)
minikube start --cpus 4 --memory 8192

# Check status
kubectl cluster-info
kubectl get nodes

kubectl is the command-line tool for operating the cluster; every "do something to the cluster" instruction goes through it. The first minikube start downloads images — if it is slow, switch the image registry or just wait patiently.

3. Deploy Your First Application

Use one Deployment plus one Service to run Nginx. The Deployment says "I want 3 replicas using the nginx image"; the Service says "give these Pods a fixed entry point, type NodePort":

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: NodePort

Apply it and verify:

kubectl apply -f deployment.yaml
kubectl get pods
kubectl get services
minikube service nginx-service

apply is the heart of the declarative model: you write the desired state into YAML, and Kubernetes makes it real. If a Pod dies, the controller spins up a replacement automatically — that is "self-healing." To inspect what is running, kubectl get all lists the main resources in the current namespace in one shot; with kubectl port-forward svc/nginx-service 8080:80 you can map a cluster-internal service to a local port and reach it directly, which is very handy when debugging.

4. Common Commands

describe is the first step in troubleshooting: if a Pod will not start, the events tell you whether it is an image pull failure, insufficient resources, or a failed probe.

5. Rolling Updates and Rollbacks

Change the image version and kubectl apply again — K8s upgrades with a rolling update: it starts new Pods, waits for them to become ready, then replaces the old ones one by one, so the service never goes down. Watch the process with kubectl rollout status deployment/nginx-deployment; if the upgrade goes wrong, kubectl rollout undo deployment/nginx-deployment returns to the previous version in one step. Deployment strategies can also be configured as Recreate (stop old, start new) or as finer-grained blue-green and canary approaches — for most applications, the default rolling update is plenty. This combination of zero-downtime upgrades and one-step rollback is the hardest thing to replicate with manual deployment, and one of the most tangible values Kubernetes brings to daily operations.

6. Production Recommendations

Local clusters and real production differ a lot. When moving from minikube to production, keep these in mind:

• Use managed services: prefer EKS, AKS, or GKE. The control plane is operated for you, and upgrades and backups are far less work.
• Set resource requests and limits: declare CPU/memory requests and limits for every container so one service cannot exhaust a node and starve its neighbors.
• Set up HPA auto-scaling: scale replica counts automatically from CPU or custom metrics, with no human intervention during traffic spikes.
• Use Helm for releases: package your YAML files as Charts, making versioning, rollback, and parameterization much easier.

A Scenario

A news site with hundreds of thousands of daily active users splits its backend into four services: gateway, user, content, and push. During peak hours the gateway CPU hits 80%, and HPA automatically scales the replica count from 6 to 18; late at night it scales back down. When one node fails, Pods are rescheduled to healthy nodes and users barely notice. Achieving this with Compose is very hard — this is the typical reason to adopt Kubernetes.

Common Questions

• Pods stuck in Pending? Likely insufficient node resources or unsatisfiable scheduling — run kubectl describe pod and read the events.
• Service unreachable? First confirm the Service selector matches the Pod labels, then check the port type (ClusterIP/NodePort/LoadBalancer).
• Local and production behavior differ? Minikube is single-node with no persistent storage; many production features (multi-zone, dynamic PVC provisioning) are not visible locally. Do not treat it as a production substitute.
• How do you manage many nodes? Use namespaces to isolate teams and applications, use labels/taints to control scheduling, and concentrate operational changes in the hands of a few authorized people.

Reference: Kubernetes documentation https://kubernetes.io/docs/ ; Minikube docs https://minikube.sigs.k8s.io/docs/