Kubernetes Lab Setup

Setting Up a Local Kubernetes Lab

Before learning Kubernetes deeply, you need a safe place to build, break, inspect, and rebuild clusters. This lab starts from a clean Windows machine and walks through WSL 2, Ubuntu, Docker Desktop, kubectl, kind, and your first local Kubernetes cluster.

What this lab gives you

This lab sets up a local Kubernetes cluster on your own machine. The goal is not to build a production environment. The goal is to create a safe practice environment where you can learn Kubernetes commands, deploy workloads, break things, and reset quickly.

For this series, the standard local lab uses:

  • WSL 2 for Linux support on Windows
  • Ubuntu as the local Linux distribution
  • Docker Desktop using the WSL 2 backend
  • kubectl, the Kubernetes command-line tool
  • kind, which stands for Kubernetes in Docker
  • Visual Studio Code or another editor for YAML files
  • PowerShell or Windows Terminal
Field note: A good lab is disposable. You should be able to create it, test with it, break it, delete it, and rebuild it without worrying about damaging anything important.

Why start local?

Cloud Kubernetes platforms are useful, but they add extra moving parts: cloud networking, IAM, billing, load balancers, managed node pools, private endpoints, and provider-specific behavior.

Those things matter later. At the beginning, they can distract from the core Kubernetes model.

A local lab keeps the first learning goal simple:

  • Can you install the tools?
  • Can you create a cluster?
  • Can kubectl talk to the Kubernetes API?
  • Can you see the nodes?
  • Can you see the system pods?
  • Can you delete and rebuild the cluster?

Lab options

There are several ways to run Kubernetes locally. The main options are:

  • kind: Lightweight and easy to rebuild. Good for this training series.
  • minikube: Also popular for local Kubernetes learning.
  • Docker Desktop Kubernetes: Convenient if you already use Docker Desktop.
  • kubeadm: Better for learning real cluster administration later, but heavier for the first lab.

We are starting with kind because it is fast, disposable, and easy to use for repeatable labs.

Before you start

This walkthrough assumes you are starting from a Windows machine that does not already have WSL 2, Ubuntu, Docker Desktop, kubectl, or kind configured.

You should have:

  • A Windows 10 or Windows 11 machine that supports WSL 2
  • Local administrator rights
  • Internet access
  • PowerShell or Windows Terminal
  • Enough disk space for Docker images and lab containers

If you are using a corporate-managed device, some of these installs may be blocked by policy. In that case, you may need help from your endpoint or desktop support team.

Step 1: Open PowerShell as Administrator

Start by opening PowerShell with administrator rights.

  • Click Start.
  • Search for PowerShell.
  • Right-click it.
  • Select Run as administrator.

Some of the WSL setup commands require elevated permissions.

Step 2: Install WSL

Run this command from the administrator PowerShell window:

wsl --install

This installs the Windows Subsystem for Linux components and enables the Windows features needed for WSL. On many Windows systems, it will also install Ubuntu as the default Linux distribution. On some systems, it may only install the WSL components first and require a reboot before a Linux distribution is installed.

If Windows tells you that changes will not take effect until the system is rebooted, restart the machine before continuing.

Restart-Computer

Step 3: Check whether a Linux distribution is installed

After rebooting, open PowerShell again and run:

wsl -l -v

If Ubuntu installed successfully, you should see a distribution listed with version 2.

  NAME      STATE           VERSION
* Ubuntu    Stopped         2

If you see a message that WSL has no installed distributions, that is okay. It means WSL is enabled, but no Linux distribution has been installed yet.

Step 4: List available Linux distributions

To see which Linux distributions are available, run:

wsl --list --online

You should see a list of available distributions. For this lab, we will use Ubuntu because it is common, well documented, and works well with Docker Desktop and Kubernetes tooling.

Step 5: Install Ubuntu

Install Ubuntu with:

wsl --install -d Ubuntu

If the command says Ubuntu is already installed, continue to the next step.

If you receive an error, run the online list command again and use the exact Ubuntu distribution name shown in your output.

wsl --list --online

For example, your available list may show names such as Ubuntu, Ubuntu-24.04, or another versioned Ubuntu entry. Use the exact name shown.

wsl --install -d Ubuntu-24.04

Step 6: Launch Ubuntu and finish first-run setup

Launch Ubuntu:

wsl -d Ubuntu

Ubuntu should ask you to create a Linux username and password.

These credentials are for your local Linux environment. They do not need to match your Windows username and password.

Field note: WSL is the platform. Ubuntu is the Linux distribution running on that platform. You need both before moving on to Docker Desktop and Kubernetes tooling.

When Ubuntu setup finishes, exit the Linux shell:

exit

Step 7: Confirm Ubuntu is running on WSL 2

Back in PowerShell, run:

wsl -l -v

You should see Ubuntu listed with version 2.

  NAME      STATE           VERSION
* Ubuntu    Stopped         2

If Ubuntu shows version 1, set WSL 2 as the default:

wsl --set-default-version 2

Then convert Ubuntu to WSL 2:

wsl --set-version Ubuntu 2

If your distribution name is different, use the exact name shown by wsl -l -v.

Step 8: Update Ubuntu packages

Open Ubuntu from the Start menu, or run this from PowerShell:

wsl -d Ubuntu

Inside the Ubuntu shell, run:

sudo apt update
sudo apt upgrade -y

This updates the package list and installed packages inside your WSL Linux environment.

When it finishes, return to PowerShell:

exit

Step 9: Install Docker Desktop

Docker Desktop is the easiest Docker setup for this Windows-based lab. It provides the Docker engine that kind will use to create Kubernetes node containers.

From PowerShell, install Docker Desktop with winget:

winget install Docker.DockerDesktop

If winget asks you to accept package terms or source agreements, accept them if they are appropriate for your machine.

After the install finishes, start Docker Desktop from the Windows Start menu.

Docker may ask you to log out, reboot, or accept its service agreement. Follow the prompts.

Step 10: Enable Docker Desktop's WSL 2 backend

Open Docker Desktop and check these settings:

  • Go to Settings.
  • Go to General.
  • Make sure Use the WSL 2 based engine is enabled if the option is visible.
  • Go to Resources.
  • Go to WSL Integration.
  • Enable integration with your Ubuntu WSL distribution.
  • Select Apply & Restart if Docker prompts you.

On some current Docker Desktop installations, the WSL 2 engine is enabled automatically when the system supports WSL 2, and the setting may not be visible. The important part is that Docker Desktop is running with WSL 2 support and Ubuntu integration is enabled.

If Docker says WSL integration is not available, Docker may be in Windows container mode. Switch Docker to Linux containers and check again.

Field note: For this lab, Docker needs to run Linux containers. Kubernetes workloads in this series will use Linux container images.

Step 11: Confirm Docker is working

Open a new PowerShell window and run:

docker version

Then run:

docker ps

The first command checks whether the Docker client and server are responding. The second command lists running containers.

It is okay if no containers are running yet. What matters is that Docker responds without an error.

If this fails

  • Start Docker Desktop.
  • Confirm Docker Desktop is using the WSL 2 backend.
  • Confirm Docker Desktop is using Linux containers.
  • Confirm WSL integration is enabled for Ubuntu.
  • Restart PowerShell after installing Docker.
  • Restart Docker Desktop if the Docker engine is not responding.

Step 12: Install kubectl

kubectl is the command-line tool used to talk to the Kubernetes API server.

On Windows, you can install kubectl with winget:

winget install -e --id Kubernetes.kubectl

If kubectl is already installed, winget may show a message like:

Found an existing package already installed.
No available upgrade found.
No newer package versions are available from the configured sources.

That is not an error. It means kubectl is already installed and winget did not find a newer version to apply.

After installation, close and reopen PowerShell. Then run:

kubectl version --client

What you should see

You should see client version information for kubectl.

What this means

This confirms kubectl is installed locally. It does not mean you have a Kubernetes cluster yet. It only means the command-line tool exists and can run.

Step 13: Install kind

kind is the tool we will use to create local Kubernetes clusters.

On Windows, try installing kind with winget:

winget install Kubernetes.kind

After installation, close and reopen PowerShell. Then run:

kind version

If winget cannot find kind on your machine, install it using the official kind release binary later. For most beginner Windows labs, winget is the simplest starting point.

What you should see

You should see the installed kind version.

Step 14: Create your first cluster

Now create a local Kubernetes cluster named stealth-k8s-lab:

kind create cluster --name stealth-k8s-lab

This may take a few minutes the first time because kind needs to pull the required node image.

What this command does

This creates a Kubernetes cluster using Docker containers as the cluster nodes. For the first lab, this is usually a single-node cluster.

kind also updates your local Kubernetes configuration so kubectl can talk to the new cluster.

Field note: In Kubernetes, kubectl talks to a cluster through a context. A context is basically a saved connection profile that tells kubectl which cluster to use.

Step 15: Verify your kubectl context

Run:

kubectl config current-context

You should see:

kind-stealth-k8s-lab

That tells you kubectl is pointed at your new kind cluster.

Step 16: Check cluster information

Run:

kubectl cluster-info

This checks whether kubectl can reach the Kubernetes control plane.

What you should see

You should see cluster information showing the Kubernetes control plane endpoint.

Step 17: Check the nodes

Run:

kubectl get nodes

This asks the Kubernetes API for the list of registered nodes.

What you should see

You should see one node with a status of Ready.

NAME                            STATUS   ROLES           AGE   VERSION
stealth-k8s-lab-control-plane   Ready    control-plane   2m    v1.xx.x

What this means

The cluster exists, the node registered successfully, and the control plane can report node status.

Step 18: Check all pods

Run:

kubectl get pods -A

The -A means all namespaces.

Kubernetes system components do not usually run in the default namespace. They often run in namespaces such as kube-system, so using -A gives you a broader view.

What you should see

You should see several system pods. In a kind cluster, these may include components for DNS, the API server, the scheduler, the controller manager, etcd, and networking.

Field note: Do not just check whether the command worked. Look at the namespaces, pod names, and statuses. Kubernetes learning comes from noticing what is running and asking why it exists.

Step 19: Create a test deployment

Now deploy a simple nginx workload:

kubectl create deployment nginx-lab --image=nginx:latest

Check the deployment:

kubectl get deployments

Check the pod:

kubectl get pods

What this means

You did not directly create a pod. You created a Deployment. The Deployment created and manages the pod for you.

Step 20: Delete the test deployment

Remove the nginx deployment:

kubectl delete deployment nginx-lab

Confirm it is gone:

kubectl get pods

If the pod briefly shows a terminating status, that is normal.

Step 21: Delete and rebuild the lab

One of the best parts of a local kind lab is that it can be destroyed and rebuilt quickly.

Delete the cluster:

kind delete cluster --name stealth-k8s-lab

Recreate it:

kind create cluster --name stealth-k8s-lab

Check the nodes again:

kubectl get nodes

This rebuild process matters. It teaches you that the lab is disposable and gives you confidence to experiment.

Common setup problems

WSL installed but no Linux distributions are listed

This is the issue many beginners hit first. It means WSL is enabled, but Ubuntu has not been installed yet.

Run:

wsl --list --online
wsl --install -d Ubuntu

If Ubuntu is not listed exactly as Ubuntu, use the exact name shown by the online list command.

WSL install requires a reboot

This is normal. Reboot, then run wsl -l -v. If no distribution is installed, install Ubuntu with wsl --install -d Ubuntu.

Ubuntu does not show version 2

Check the distribution name:

wsl -l -v

Then set that distribution to WSL 2:

wsl --set-version Ubuntu 2

Replace Ubuntu with the exact distribution name shown in your output.

Docker is not running

If kind cannot create the cluster, check Docker first.

docker version
docker ps

Docker is in Windows container mode

Switch Docker Desktop to Linux containers. This option is usually available from the Docker Desktop tray icon or Docker Desktop settings.

Docker WSL integration is not enabled

Open Docker Desktop and check:

  • Settings
  • Resources
  • WSL Integration
  • Enable integration for Ubuntu

kubectl is installed but cannot connect

Check your current context:

kubectl config current-context

Then check all known contexts:

kubectl config get-contexts

The node is not ready

Run:

kubectl get nodes
kubectl describe node stealth-k8s-lab-control-plane

The describe command gives more detail about what Kubernetes knows about the node.

The install worked, but PowerShell does not recognize the command

Close and reopen PowerShell. If that does not work, confirm the install path is available in your PATH environment variable.

What this lab is good for

  • Learning kubectl
  • Practicing Kubernetes objects
  • Testing YAML files
  • Breaking and rebuilding workloads
  • Learning deployments, services, config, and basic troubleshooting

What this lab is not good for

  • Production hosting
  • Cloud load balancer behavior
  • Real multi-zone availability testing
  • Production security validation
  • Enterprise identity and networking patterns

Those topics come later. The point of this lab is to build the muscle memory you need before adding cloud-specific complexity.

Quick lab checklist

Before moving to the next lesson, make sure you can run each of these successfully:

wsl -l -v
wsl --list --online
wsl -d Ubuntu
docker version
docker ps
kubectl version --client
kind version
kind create cluster --name stealth-k8s-lab
kubectl config current-context
kubectl cluster-info
kubectl get nodes
kubectl get pods -A
kubectl create deployment nginx-lab --image=nginx:latest
kubectl get pods
kubectl delete deployment nginx-lab
kind delete cluster --name stealth-k8s-lab
Bottom line: You now have a disposable Kubernetes lab. That is the foundation for the rest of the Kubernetes Field Notes series.

Check your understanding

Use these questions to test whether the lab concepts made sense. The goal is not memorization. The goal is to make sure you understand what each tool is doing.

  1. What is the difference between WSL and Ubuntu in this lab?
  2. Why might wsl --install enable WSL but not immediately install a Linux distribution?
  3. What command lists available Linux distributions for WSL?
  4. Why do we install WSL 2 before Docker Desktop in this Windows lab?
  5. Why does Docker Desktop need to use Linux containers for this lab?
  6. What role does Docker play when using kind?
  7. What does kubectl do?
  8. What does kind create for you?
  9. Why do we check the current kubectl context?
  10. What does kubectl get nodes confirm?
  11. What does the -A flag mean in kubectl get pods -A?
  12. When you run kubectl create deployment nginx-lab --image=nginx:latest, did you directly create a pod?
  13. Why is it useful that the lab can be deleted and rebuilt?
  14. Why is this kind lab not the same as a production Kubernetes environment?
Answer key
  1. WSL is the Windows platform that allows Linux environments to run. Ubuntu is the Linux distribution running inside WSL.
  2. Some systems install the WSL components first and require a reboot or a separate distribution install step before Ubuntu appears.
  3. wsl --list --online.
  4. WSL 2 provides the Linux environment and backend support that Docker Desktop can use on Windows.
  5. The Kubernetes workloads in this series use Linux container images, so Docker needs to run Linux containers.
  6. Docker provides the container runtime environment where kind runs Kubernetes nodes as containers.
  7. kubectl is the command-line tool used to communicate with the Kubernetes API server.
  8. kind creates a local Kubernetes cluster.
  9. The context tells kubectl which cluster it is currently pointed at.
  10. It confirms that the cluster has registered nodes and reports their status.
  11. It means all namespaces.
  12. No. You created a Deployment, and the Deployment created and manages the pod.
  13. It encourages experimentation and makes it easy to recover from mistakes.
  14. It lacks production-grade cloud networking, availability, identity, security, scaling, and operational controls.
← Previous: What Kubernetes Actually Does Series index Next: Containers vs VMs →