Access<\/td> Root or sudo SSH<\/td> SSH key login<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nYou can run a single-node cluster for practice. Still, I always suggest two nodes so the whole setup feels like the real thing.<\/p>\n\n\n\nNote<\/strong>: Every command here was tested by my team on Ubuntu 24.04 with Kubernetes v1.36 in July 2026. They run the same on Debian with tiny tweaks.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nHere is the full road map before we dig in. Keep this table open in another tab and treat it as your checklist.<\/p>\n\n\n\n
The Setup Plan at a Glance<\/h2>\n\n\n\n My team broke the whole job into ten clean steps. Each one builds on the last, so follow them in order for a smooth, calm run.<\/p>\n\n\n\nStep<\/strong><\/th>What It Does<\/strong><\/th><\/tr><\/thead>1. Prepare servers<\/td> Set names and update packages<\/td><\/tr> 2. Turn off swap<\/td> Kubernetes needs swap disabled<\/td><\/tr> 3. Kernel modules<\/td> Let servers pass pod traffic<\/td><\/tr> 4. Install containerd<\/td> The engine that runs containers<\/td><\/tr> 5. Install the tools<\/td> Add kubeadm, kubelet, kubectl<\/td><\/tr> 6. Start control plane<\/td> Build the cluster boss<\/td><\/tr> 7. Set up kubectl<\/td> Let you send commands<\/td><\/tr> 8. Pod network<\/td> Let pods talk to each other<\/td><\/tr> 9. Join workers<\/td> Add your app servers<\/td><\/tr> 10. Test it<\/td> Deploy a real, live app<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTen steps sound like a lot. Trust me, most take under a minute once you find the rhythm. Let’s dive in.<\/p>\n\n\n\n
How to Setup Kubernetes on VPS?<\/h2>\n\n\n\n Below, I\u2019ve done the exact steps that you need to do to set up kubernetes on VPS. First, you have to buy VPS from a reliable VPS provider and they will give you your VPS login credentials via SSH. After logging in to the VPS, you need to carry on with these steps exactly how I\u2019ve done it.<\/p>\n\n\n\n
Step 1: Prepare Every Server<\/h3>\n\n\n\n Run this first part on every server, both the control plane and the workers. It sets the stage so nothing breaks on you later.<\/p>\n\n\n\n
Give each server a clear name. This helps you know which machine you sit on, since every terminal window looks the same.<\/p>\n\n\n\n
sudo hostnamectl set-hostname control-plane \u00a0 # on the bosssudo hostnamectl set-hostname worker-1\u00a0 \u00a0 \u00a0 \u00a0 # on a worker<\/code><\/pre>\n\n\n\nNow add each server’s name and private IP to the hosts file. This lets your servers find each other by name, not just by numbers.<\/p>\n\n\n\nsudo nano \/etc\/hosts# add lines like these, with your own real IPs10.0.0.10 control-plane10.0.0.11 worker-1<\/code><\/pre>\n\n\n\nThen update the packages on every box. Fresh packages mean fewer bugs and fewer surprises during the install.<\/p>\n\n\n\n
sudo apt update && sudo apt upgrade -y<\/code><\/pre>\n\n\n\nWith names set and packages fresh, we hit the one setting that trips up almost every single beginner.<\/p>\n\n\n\n
Step 2: Turn Off Swap<\/h3>\n\n\n\n Swap is spare disk space that acts like extra memory. Kubernetes wants it off so it can read real memory the right way.<\/p>\n\n\n\n
Switch it off with two short commands. The first stops swap now, and the second keeps it off after a reboot.<\/p>\n\n\n\n
sudo swapoff -asudo sed -i '\/ swap \/ s\/^\\(.*\\)$\/#\\1\/g' \/etc\/fstab<\/code><\/pre>\n\n\n\nRun these on every server. Skip this, and your cluster may refuse to start with a confusing, hard-to-read error.<\/p>\n\n\n\nPro Tip<\/strong>: Run every step on all servers unless I clearly say control plane only. My team keeps three terminals open side by side for this.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nNext we tell the Linux kernel to allow the network traffic that your pods will lean on.<\/p>\n\n\n\n
Step 3: Load Kernel Modules and Network Settings<\/h3>\n\n\n\n Pods need to send traffic across your servers. Two small kernel modules make that possible, so let me switch them on for you.<\/p>\n\n\n\n
The overlay and br_netfilter modules handle how containers share the network. Load them with the short block below.<\/p>\n\n\n\n
cat <<EOF | sudo tee \/etc\/modules-load.d\/k8s.confoverlaybr_netfilterEOF\u00a0sudo modprobe overlaysudo modprobe br_netfilter<\/code><\/pre>\n\n\n\nNow set a few network rules so traffic flows the right way between pods. Kubernetes checks for these during the setup.<\/p>\n\n\n\ncat <<EOF | sudo tee \/etc\/sysctl.d\/k8s.confnet.bridge.bridge-nf-call-iptables\u00a0 = 1net.bridge.bridge-nf-call-ip6tables = 1net.ipv4.ip_forward \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = 1EOF\u00a0sudo sysctl --system<\/code><\/pre>\n\n\n\nThese lines look scary. They simply let one server pass pod traffic to another and never drop it. Run them on every node.<\/p>\n\n\n\n
Now we install the real engine that runs your containers under the hood.<\/p>\n\n\n\n
Step 4: Install containerd, the Container Runtime<\/h3>\n\n\n\n A container runtime is the program that actually starts and stops your containers. Kubernetes needs one, and containerd is the runtime my team trusts.<\/p>\n\n\n\n
Docker used to fill this role. Kubernetes dropped that path a while back, so we now use containerd on its own.<\/p>\n\n\n\n
sudo apt install -y containerd<\/code><\/pre>\n\n\n\nNext, create its default settings file. This gives containerd a clean base to work from.<\/p>\n\n\n\n
sudo mkdir -p \/etc\/containerdcontainerd config default | sudo tee \/etc\/containerd\/config.toml > \/dev\/null<\/code><\/pre>\n\n\n\nOne setting matters a lot. Flip SystemdCgroup to true so containerd and Kubernetes agree on how to track resources.<\/p>\n\n\n\nsudo sed -i 's\/SystemdCgroup = false\/SystemdCgroup = true\/' \\\u00a0\u00a0\/etc\/containerd\/config.tomlsudo systemctl restart containerdsudo systemctl enable containerd<\/code><\/pre>\n\n\n\nMiss that one flag, and your pods crash in a loop later. My team has debugged that exact issue more times than we admit.<\/p>\n\n\n\n
With the engine ready, we bring in the three tools that run the whole show.<\/p>\n\n\n\n
Step 5: Install kubeadm, kubelet, and kubectl<\/h3>\n\n\n\n These three tools do the heavy lifting. Let me tell you what each one does before you install them.<\/p>\n\n\n\n
kubeadm builds the cluster. kubelet runs on every node and keeps pods alive. kubectl is the command you type to control it all.<\/p>\n\n\n\n
First, add the official Kubernetes package source. This block grabs the signing key for the current v1.36 release.<\/p>\n\n\n\n
sudo apt install -y apt-transport-https ca-certificates curl gpgsudo mkdir -p -m 755 \/etc\/apt\/keyringscurl -fsSL https:\/\/pkgs.k8s.io\/core:\/stable:\/v1.36\/deb\/Release.key \\\u00a0\u00a0| sudo gpg --dearmor -o \/etc\/apt\/keyrings\/kubernetes-apt-keyring.gpg<\/code><\/pre>\n\n\n\nNow point apt at that source and install the three tools in one go.<\/p>\n\n\n\necho 'deb [signed-by=\/etc\/apt\/keyrings\/kubernetes-apt-keyring.gpg] \\\u00a0\u00a0https:\/\/pkgs.k8s.io\/core:\/stable:\/v1.36\/deb\/ \/' \\\u00a0\u00a0| sudo tee \/etc\/apt\/sources.list.d\/kubernetes.listsudo apt updatesudo apt install -y kubelet kubeadm kubectl<\/code><\/pre>\n\n\n\nThen lock the versions. This stops a random update from breaking your cluster during normal patching.<\/p>\n\n\n\n
sudo apt-mark hold kubelet kubeadm kubectl<\/code><\/pre>\n\n\n\nNote:<\/strong> The old apt.kubernetes.io source is dead and gone. My research team only uses the pkgs.k8s.io source shown above, and so should you.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nRun every step so far on all your servers. Before we start the cluster brain, let me pause on the thing that decides how smooth all of this feels.<\/p>\n\n\n\n
Step 6: Start the Control Plane<\/h3>\n\n\n\n This step runs on the control plane only. It turns your boss server into the brain of the whole cluster.<\/p>\n\n\n\n
The command below starts the cluster and sets the pod network range. My team pairs this range with Calico, the network tool we add next.<\/p>\n\n\n\n
# run on the control plane onlysudo kubeadm init --pod-network-cidr=192.168.0.0\/16<\/code><\/pre>\n\n\n\nThis takes a few minutes. When it finishes, it prints a kubeadm join command. Copy that whole line and save it somewhere safe.<\/p>\n\n\n\n
That join line is your ticket to add workers later. It holds a token that expires in 24 hours, so please do not lose it.<\/p>\n\n\n\nDisclaimer<\/strong>: Your exact output, IPs, and tokens will differ from mine. Never share your join token in public, since anyone who holds it can add nodes to your cluster.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe cluster brain is alive. Now let me hand you the keys to talk to it.<\/p>\n\n\n\n
Step 7: Set Up kubectl Access<\/h3>\n\n\n\n Right now only root can reach the cluster. These three lines let your normal user run kubectl and skip typing sudo every time.<\/p>\n\n\n\n
Run them on the control plane as your regular user, not as root.<\/p>\n\n\n\n
mkdir -p $HOME\/.kubesudo cp -i \/etc\/kubernetes\/admin.conf $HOME\/.kube\/configsudo chown $(id -u):$(id -g) $HOME\/.kube\/config<\/code><\/pre>\n\n\n\nTest it right away. This command asks the cluster to list its nodes for you.<\/p>\n\n\n\n
kubectl get nodes<\/code><\/pre>\n\n\n\nYou see your control plane listed as NotReady. That is fine for now. It stays that way until we add the pod network next.<\/p>\n\n\n\n
That NotReady status is our cue. The cluster needs a way for pods to talk, so let me install one.<\/p>\n\n\n\n
Step 8: Install a Pod Network<\/h3>\n\n\n\n Pods cannot reach each other until you add a network layer, called a CNI. My team uses Calico because it is stable and simple.<\/p>\n\n\n\n
Install it with one command on the control plane. It reads a ready-made file straight from the Calico project.<\/p>\n\n\n\n
# run on the control plane onlykubectl apply -f https:\/\/raw.githubusercontent.com\/projectcalico\/\\calico\/v3.28.0\/manifests\/calico.yaml<\/code><\/pre>\n\n\n\nGive it a minute or two to settle. Then check your nodes one more time.<\/p>\n\n\n\nkubectl get nodes<\/code><\/pre>\n\n\n\nYour control plane should now read Ready. That single word means the network is live and the cluster is healthy.<\/p>\n\n\n\nNote<\/strong>: Calico ships new versions often. My team checks the Calico site for the current file link before each fresh install, and I suggest you do the same.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nYour cluster runs, but it has no workers yet. Let me bring your app servers into the family.<\/p>\n\n\n\n
Step 9: Join Your Worker Nodes<\/h3>\n\n\n\n Now grab that kubeadm join command you saved back in Step 6. You run it on each worker, not on the control plane.<\/p>\n\n\n\n
The line looks like the one below, with your own IP and token filled in. Add sudo at the front.<\/p>\n\n\n\n
# run on each worker nodesudo kubeadm join 10.0.0.10:6443 --token abcdef.0123456789abcdef \\\u00a0\u00a0--discovery-token-ca-cert-hash sha256:1234...yourhash<\/code><\/pre>\n\n\n\nLost the token? That is fine. Run this on the control plane to print a fresh join command for you.<\/p>\n\n\n\n
kubeadm token create --print-join-command<\/code><\/pre>\n\n\n\nAfter each worker joins, hop back to the control plane and list your nodes. Watch them turn Ready one by one.<\/p>\n\n\n\n
kubectl get nodes<\/code><\/pre>\n\n\n\nIt feels great to see every node marked Ready. My team still smiles at that screen after all these years.<\/p>\n\n\n\n
A cluster with nothing running is just a shell. Let me prove it works by deploying a real app.<\/p>\n\n\n\n
Step 10: Test the Cluster With a Real App<\/h3>\n\n\n\n Let me put a small web app on the cluster. This shows that pods start, spread out, and answer traffic like they should.<\/p>\n\n\n\n
Run this on the control plane. It creates a tiny Nginx web server with two copies for safety.<\/p>\n\n\n\n
kubectl create deployment web --image=nginx --replicas=2kubectl expose deployment web --port=80 --type=NodePort<\/code><\/pre>\n\n\n\nCheck that both copies are running. This command lists your pods and the node each one landed on.<\/p>\n\n\n\nkubectl get pods -o wide<\/code><\/pre>\n\n\n\nYou should see two web pods spread across your workers. That spread is Kubernetes at work, keeping your app alive when a node dies.<\/p>\n\n\n\n
Open the NodePort in your browser to see the Nginx welcome page. That live page is proof your cluster now serves real traffic.<\/p>\n\n\n\nNote<\/strong>: This test app is safe to remove. Run kubectl delete deployment web and kubectl delete service web once you finish poking around.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nYou now hold a working cluster. Before you celebrate, let me save you from the traps my team hit early on.<\/p>\n\n\n\n
Common Mistakes I See Beginners Make<\/h2>\n\n\n\n I have cleaned up a lot of broken clusters over the years. These few slips cause most of the pain, so watch for them.<\/p>\n\n\n\n
\nSwap left on is the top offender. Double-check you turned it off on every node, not just the control plane.<\/li>\n\n\n\n A skipped SystemdCgroup flag is next. Pods crash in a loop when containerd and Kubernetes disagree on resource tracking.<\/li>\n\n\n\n An expired token blocks many joins. Tokens die after 24 hours, so create a fresh one when a worker refuses to connect.<\/li>\n\n\n\n A closed firewall port causes silent failures. Open the ports your nodes need so the boss and workers can chat freely.<\/li>\n<\/ul>\n\n\n\nSpeaking of ports, here are the exact ones my team opens between nodes. Set these first when a fresh cluster acts odd.<\/p>\n\n\n\nPort<\/strong><\/th>Node<\/strong><\/th>Purpose<\/strong><\/th><\/tr><\/thead>6443<\/td> Control plane<\/td> API server, all nodes talk here<\/td><\/tr> 10250<\/td> All nodes<\/td> kubelet health and stats<\/td><\/tr> 30000-32767<\/td> Workers<\/td> NodePort apps reach the outside<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nOpen these ports between your nodes and you dodge the most common network headache. My team checks this list first every time.<\/p>\n\n\n\n
You have the full build and the common fixes. Let me answer the questions my team hears most about Kubernetes on VPS.<\/p>\n\n\n\n
![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-71.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-67.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-70.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-68.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-69.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-73.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-74.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-72.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-75.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-76.png\")
<\/figure>\n\n\n\n![\"Kubernetes](\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2026\/08\/image-77.png\")
<\/figure>\n\n\n\n