vagrant-kubeadm-kubernetes builds a three node cluster for exam practice

A throwaway cluster for exam candidates

The project exists to solve one problem: giving a Kubernetes certification candidate a cluster they can break on purpose. The repository description says it plainly, Vagrantfile and Scripts to setup Kubernetes Cluster using Kubeadm for CKA, CKAD and CKS practice environment, and the README calls it a fully automated setup for practice labs. The topology is deliberately small and deliberately familiar: one master node and two worker nodes, provisioned with kubeadm rather than with a managed distribution or a lightweight container runtime. Because everything lives in VirtualBox virtual machines managed by Vagrant, the whole lab is a single vagrant up away and a single vagrant destroy -f away from being gone. That is the property that makes it useful for exam preparation, where the point is to rebuild, break and rebuild again. It is tested on Windows, Ubuntu Desktop and Intel based Mac systems, and Apple Silicon users are pointed at a separate repository.

The network is a NAT bridge onto an internal switch

The network graph in the README explains the addressing, and it is worth reading before you debug anything. The host machine connects to the external network and the internet. From there a NAT network named K8s-NATNetwork sits on 192.168.99.0/24, bridging the outside world to the inside. Below that sits an internal switch, k8s-Switch, on 192.168.99.1/24, and the three nodes hang off it: the master node at 192.168.99, node 1 at 192.168.99.81 and node 2 at 192.168.99.82. In the README's own description, the NAT network provides the bridge between the internal network and the external network, while the internal switch connects all the Kubernetes nodes. The practical consequence is that the nodes talk to each other on a private subnet that never leaves the host, and reach the internet through NAT, so a cluster that appears to lose external connectivity is usually a host network configuration problem rather than a Kubernetes one.

Provisioning is one vagrant up

The bring up procedure is three commands. The clone URL printed in the README points at scriptcamp/vagrant-kubeadm-kubernetes rather than the techiescamp organisation, so check it against the repository you are actually in before you run it:

git clone https://github.com/scriptcamp/vagrant-kubeadm-kubernetes.git
cd vagrant-kubeadm-kubernetes
vagrant up

From there the Vagrantfile and the scripts/ directory do the rest, installing the cluster components on the master and joining the workers. The machine sizes are given in the prerequisites: the virtual machines use 3 vCPUs and 4 or more Gigabytes of RAM, which is why the workstation itself is asked for 8 Gigabytes or more of RAM. The scripts/ directory also holds the helper for installing the dashboard later, which matters if you skipped it during the initial provision. Note that the whole thing is scripted shell work over Vagrant, so the first run downloads base images and Kubernetes packages, and the README describes it as a fully automated setup rather than an interactive one.

Pointing kubectl at the cluster and reaching the dashboard

After the cluster is up, the kubeconfig has to be found. The README gives two ways to do it. Either export the path from the configs directory:

cd vagrant-kubeadm-kubernetes
cd configs
export KUBECONFIG=$(pwd)/config

or copy the file into your .kube directory:

cp config ~/.kube/

The dashboard is installed automatically by default, and the login token is copied from the config/token file. You reach the dashboard through a port forward, which is the part people get stuck on:

kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443

and then open https://localhost:8443 in a browser. The service name in that command, kubernetes-dashboard-kong-proxy, shows that the dashboard is fronted by a Kong proxy service, which is why the port forward targets that rather than the dashboard pod itself.

settings.yaml decides what gets installed

The behaviour of the provision is controlled by a single settings file at the root of the repository, alongside the Vagrantfile and the scripts directory. The README explains one setting in detail: the dashboard is installed automatically by default, but it can be skipped by commenting out the dashboard version in settings.yaml before running vagrant up. If you skip it that way, you can deploy it later by enabling it in settings.yaml and running the dashboard script on the control plane node:

vagrant ssh -c "/vagrant/scripts/dashboard.sh" controlplane

That command shape is worth understanding, because it shows how the project separates configuration from execution. Settings are edited in one place on the host, and the scripts are executed inside the guest through vagrant ssh, against the controlplane machine. Any other toggle you would want, a different component or a different version, follows the same pattern in that file rather than in the scripts themselves. The repository root is small and legible for this reason: .gitignore, CHANGELOG, LICENSE.md, README.md, Vagrantfile, scripts/ and settings.yaml.

Host prerequisites that fail in specific ways

Two host level issues are documented with fixes, and both are the kind of thing that eats an afternoon if you hit them cold. The first is a working Vagrant setup using Vagrant with VirtualBox. The second is the VirtualBox networks configuration on Mac and Linux, where the latest version can cause issues. The fix is to create or edit /etc/vbox/networks.conf and add a line allowing any host only network range:

sudo mkdir -p /etc/vbox/
echo "* 0.0.0.0/0 ::/0" | sudo tee -a /etc/vbox/networks.conf

The stated effect is that host only networks can then be in any range, rather than only 192.168.56.0/21, and the README links a HashiCorp forum thread describing the private network creation failure on macOS 11.6 with Vagrant 2.2.18. Apple Silicon Mac users are sent to a separate repository for the same project, so the hardware assumption in this one is an Intel based machine.

Stopping, restarting and destroying the lab

The lifecycle commands are the standard Vagrant set, and the README documents all three explicitly. To shut the cluster down:

vagrant halt

To bring it back:

vagrant up

To remove it entirely:

vagrant destroy -f

The destroy command is the important one for exam practice, since it guarantees a clean slate without hunting for leftover state between attempts. The distinction between halt and destroy is worth keeping straight: halt stops the virtual machines and keeps their disks, so a broken cluster stays broken, while destroy with the force flag discards them. One thing to plan for in advance is version drift. The documentation states that the current Kubernetes version for the CKA, CKAD and CKS exams is 1.30, while the setup itself has been updated with a 1.31 cluster version, so the practice environment and the exam environment are not pinned to the same release.

A GPL project with one tag and a separate Mac repository

Maintenance and licensing both deserve a note. The project is GPL-3.0, with the licence text in LICENSE.md at the root and a CHANGELOG alongside it, so reuse and redistribution terms are clear and standard for a scripts and configuration project of this kind. The licence is a separate question from whether you may use the environment for commercial work, which is an operational matter rather than a legal one. The release history is thin: the only tagged release is 1.0, dated 2022-03-23, while the last push to the repository was on 2026-10-15 and the repository is not archived. In other words the scripts keep changing while the version tag does not, so pinning to a release tells you very little about what you are running. The full documentation lives outside the repository at devopscube.com/kubernetes-cluster-vagrant/, and the practical documentation for the setup itself is in that site rather than in the README, which is a reasonable arrangement for a project that also sells a certification course.

Editorial conclusion

vagrant-kubeadm-kubernetes suits someone preparing for the CKA, CKAD or CKS who wants a reproducible cluster that can be thrown away and rebuilt between practice sessions. It is the wrong tool for a workload that needs to survive a host reboot, and the README is explicit that the target is exam preparation. Verify first that your host can run the requirement of an 8 Gigabyte or larger workstation with three vCPUs and 4 or more Gigabytes of RAM per virtual machine, that you are not on an Apple Silicon Mac, since that case is served by a separate repository, and that the cluster version matches your exam, because the documentation still names 1.30 for the exams while the setup has moved to 1.31.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. techiescamp/vagrant-kubeadm-kubernetes on GitHub