Kubernetes with Minikube
Learn Kubernetes from the ground up with minikube — a compact cluster that runs right on your machine. The series covers the architecture, Pods, Deployments, Services, ConfigMap/Secret, storage, Ingress, health checks, autoscaling and the workload types, closing with a complete deployment project. Every command runs for real on minikube; manifests at github.com/nghiadaulau/kubernetes-minikube-series. Grounded in the official docs at kubernetes.io.
What Is Kubernetes and Why Orchestration
Series opener: from a single container to running dozens of containers across multiple machines — the problem Kubernetes was built to solve. Why 'orchestration' and 'desired state' are the two most important ideas, what minikube is, and the roadmap for the whole series.
Kubernetes Architecture: Control Plane and Node
Lifting the hood on a Kubernetes cluster: the control plane (api-server, etcd, scheduler, controller-manager) is the brain, the node with kubelet and kube-proxy is where applications run. This article explains each component's role at a high level — and watches them run for real in minikube.
Installing minikube + kubectl, Your First Cluster
Getting hands-on: install kubectl and minikube, start your first cluster with the Docker driver, understand kubeconfig and context, then run your first pod as a 'hello world'. With all the real output from minikube.
Pod: The Smallest Unit in Kubernetes
The Pod is the foundational brick of Kubernetes — not a container, but a group of containers sharing network and storage. This article: write a pod in YAML, apply it, check its state, read logs, exec in, port-forward, and the lesson on why nobody runs bare pods in production.
Deployment and ReplicaSet: Keeping Your App Alive
Deployment is the object you use most to run applications: it keeps N pod copies alive (via ReplicaSet), rebuilds them when they die, scales up/down, and updates versions gradually with no downtime — plus rollback. This article proves each property with real commands.
Service: A Stable Address and Load Balancing
Pods come and go, IPs change constantly — so how do you call them? A Service gives you a stable address in front of a group of pods and load-balances automatically. This article: how ClusterIP, NodePort and LoadBalancer differ, how internal DNS lets you call a service by name, and kube-proxy behind it all.
Namespaces, Labels and Selectors
Two foundational organizing mechanisms in Kubernetes: namespaces split the cluster into separate compartments, while labels/selectors are how you tag and select resources — the very 'glue' that Deployment and Service use to find pods. This article makes both clear with real examples.
ConfigMap and Secret: Separating Configuration from the Image
The same image must run in dev, staging, production — meaning configuration cannot be baked into the image. ConfigMap holds ordinary configuration, Secret holds sensitive data. This article: creating and injecting them into a pod via environment variables and files, with an important warning about 'a Secret is just base64'.
Storage: Volumes, PV, PVC and StorageClass
Data inside a pod evaporates with the pod — no good for a database or user files. Kubernetes separates the 'storage request' (PVC) from the 'real disk' (PV), with StorageClass for dynamic provisioning. This article proves data outlives the pod with a delete-then-recreate experiment.
Ingress: Routing HTTP Into the Cluster
NodePort gives each service a weird port — no good when you have many services. Ingress is a single HTTP entry point, routing by domain and path to the right service, with TLS. This article: enable minikube's ingress addon, write an Ingress rule, and test Host-based routing.
Health Checks: Liveness and Readiness Probes
How does Kubernetes know a 'Running' pod is actually healthy and ready to take traffic? Through probes. A liveness probe restarts a hung container; a readiness probe keeps traffic away from a pod that isn't ready. This article demos both with deliberately broken pods and watches K8s react.
Resource Requests/Limits and Autoscaling (HPA)
Every pod has to state how much CPU/RAM it wants — that's how the scheduler places pods correctly and the cluster doesn't fall over because one pod hogs everything. Once declared, the HorizontalPodAutoscaler raises and lowers replica count with load. This article generates real load and watches HPA scale from 1 up to many pods.