Kubernetes enables developers and system administrators to deploy containerized applications quickly, scale them on demand, and keep them running without downtime. Almost every Kubernetes workflow revolves around four concepts: nodes, pods, deployments, and services. This tutorial walks through the foundational architecture and the key steps needed to stand up a single-node cluster on Windows 10.
Understanding Kubernetes Architecture
Before running any commands, it helps to understand what each piece of a Kubernetes cluster does and why it exists.
Nodes and Pods
A node is a physical or virtual server that runs your containerized workloads. A pod is the smallest deployable unit in Kubernetes — it wraps one or more containers that share a network namespace and storage. Pods live on nodes.
A master node (also called the control plane) oversees and manages all worker nodes. It tracks every Kubernetes object in the cluster and continuously works to reconcile the actual cluster state with the desired state you have defined.
Control Plane Components
The control plane consists of four major components:
- etcd — A distributed, lightweight key-value store. etcd is the source of truth for all cluster configuration data. Every node in the cluster can read from it, and the control plane writes cluster state to it. It can be deployed across multiple nodes for high availability.
- kube-apiserver — The RESTful front-end of the control plane. Tools like
kubectlcommunicate with the cluster exclusively through the API server. It validates and processes API requests, then updates the corresponding objects in etcd. - kube-controller-manager — Runs a set of controllers that watch cluster state via the API server and take corrective action whenever the actual state diverges from the desired state — for example, restarting a pod that has crashed or adjusting the number of replicas in a deployment.
- kube-scheduler — Assigns newly created pods to nodes. It evaluates resource requirements, hardware/software constraints, affinity rules, and current node utilization before making a scheduling decision.
Node (Worker) Components
Each worker node runs three key components that allow the control plane to manage it:
- Container runtime — The software responsible for pulling container images and running containers. Docker was the original default runtime; modern clusters commonly use containerd or CRI-O via the Container Runtime Interface (CRI).
- kubelet — An agent that runs on every node. It receives pod specifications from the API server and ensures the containers described in those specs are running and healthy. If a container fails, the kubelet reports this back to the control plane.
- kube-proxy — A network proxy that maintains network rules on each node. It forwards traffic to the correct pod and provides basic load balancing for services, enabling pods to communicate with each other and with external clients.
Key Kubernetes Concepts Before You Begin
- Deployment — A higher-level abstraction that manages a ReplicaSet, ensuring a specified number of pod replicas are always running. Deployments also handle rolling updates and rollbacks.
- Service — An abstract way to expose an application running on a set of pods as a network endpoint. Services give pods a stable IP address and DNS name, even as underlying pods are created and destroyed.
- Namespace — A logical partition within a cluster, useful for separating environments (e.g., dev, staging, production) or teams within the same physical cluster.
Setting Up a Single-Node Cluster on Windows 10
The easiest way to run Kubernetes locally on Windows is with Minikube, which spins up a single-node cluster inside a virtual machine. You also need kubectl, the Kubernetes command-line tool, to interact with the cluster.
Step 1 — Install Chocolatey (Windows Package Manager)
Chocolatey simplifies installing both kubectl and Minikube on Windows. Open PowerShell as Administrator and run:
Set-ExecutionPolicy Bypass -Scope Process -Force;
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))Code language: PHP (php)
Step 2 — Install kubectl
kubectl is the primary CLI for running commands against Kubernetes clusters — creating resources, inspecting cluster state, viewing logs, and more. Install it with Chocolatey:
choco install kubernetes-cli
Verify the installation:
kubectl version --client
Step 3 — Install Minikube
Minikube creates and manages a local Kubernetes cluster. It requires a hypervisor such as Hyper-V (built into Windows 10 Pro/Enterprise) or VirtualBox. Install Minikube:
choco install minikube
Step 4 — Start the Cluster
Start Minikube with your chosen hypervisor. For Hyper-V:
minikube start --driver=hyperv
For VirtualBox:
minikube start --driver=virtualbox
Once the cluster is running, confirm kubectl can reach it:
kubectl cluster-info
kubectl get nodesCode language: JavaScript (javascript)
Step 5 — Deploy a Containerized Application
Create a simple deployment using a public image. The example below runs an Nginx web server:
kubectl create deployment nginx-demo --image=nginx
kubectl get deployments
kubectl get podsCode language: JavaScript (javascript)
Step 6 — Expose the Deployment as a Service
To access the application from outside the cluster, expose the deployment as a NodePort service:
kubectl expose deployment nginx-demo --type=NodePort --port=80
minikube service nginx-demo
Minikube will open the service URL directly in your default browser, or print the URL for you to open manually.
Step 7 — Scale the Deployment
One of Kubernetes’ core strengths is horizontal scaling. Scale the Nginx deployment to three replicas:
kubectl scale deployment nginx-demo --replicas=3
kubectl get podsCode language: JavaScript (javascript)
The kube-scheduler will place the new pods on the available node (in this single-node setup, all three pods run on the same node). In a multi-node cluster, the scheduler distributes pods across nodes for resilience.
Step 8 — Clean Up
When you are finished, remove the resources and stop the cluster:
kubectl delete service nginx-demo
kubectl delete deployment nginx-demo
minikube stopCode language: JavaScript (javascript)
Essential kubectl Commands Reference
| Command | Purpose |
|---|---|
kubectl get nodes | List all nodes in the cluster |
kubectl get pods | List all pods in the current namespace |
kubectl get deployments | List all deployments |
kubectl get services | List all services |
kubectl describe pod <name> | Detailed information about a pod |
kubectl logs <pod-name> | Print logs from a container in a pod |
kubectl apply -f <file.yaml> | Create or update resources from a YAML file |
kubectl delete -f <file.yaml> | Delete resources defined in a YAML file |
Next Steps
A single-node Minikube cluster is an excellent learning environment, but production Kubernetes clusters involve additional considerations:
- ConfigMaps and Secrets — Externalise application configuration and sensitive data from container images.
- Persistent Volumes — Provide durable storage that survives pod restarts.
- Ingress controllers — Route external HTTP/HTTPS traffic to services inside the cluster.
- Resource requests and limits — Prevent runaway pods from starving other workloads.
- Role-Based Access Control (RBAC) — Control who can do what within the cluster.
- Managed Kubernetes services — Cloud providers such as AWS (EKS), Google Cloud (GKE), and Azure (AKS) take on control-plane management, letting teams focus on workloads rather than infrastructure.
Working through this local setup builds the muscle memory for kubectl and gives you a safe environment to experiment with deployments, rolling updates, and service configurations before applying them to a shared or production cluster.