🇧🇷 Leia a versão em português aqui
This is the first part of a series where I'll share, step by step, how I built my own on-premise Kubernetes cluster, without relying on any cloud provider. The goal is to document the whole process — from environment preparation to a working cluster — as a reference for anyone studying the topic or looking to replicate the same setup at home or at work.
I used VPS (Virtual Private Server) and VM (Virtual Machine) for this cluster. However, it can also be set up on physical machines (Bare Metal).
Bye the end of this series, it will be easier to understand cloud clusters on AWS (EKS), Google (GKE) and Azure (AKS).
In this first part, we'll cover everything needed before installing any Kubernetes component: hardware requirements, basic network configuration, firewall rules, and a few mandatory operating system adjustments.
Requirements
The following topology was used for this cluster:
- 3 servers in total
- 1 master server (control-plane): 2 CPUs (cores) and 2 GB of RAM
- 2 worker servers (slaves): 1 CPU and 1 GB of RAM each
- Root access on all machines
This is a minimal setup, ideal for study, lab, or testing environments. For production, resources should be scaled according to expected load.
Configuring the hosts file
Before installing anything, it's important for the machines to resolve each other by name, not just by IP. Edit the /etc/hosts file on all servers and add the corresponding entries:
10.0.10.100 master.company.local master
10.0.10.101 slave01.company.local slave01
10.0.10.102 slave02.company.local slave02
This ensures that, later on, the Kubernetes components can correctly resolve node names.
Configuring the Firewall
Kubernetes depends on specific ports being open between nodes so the control-plane can communicate with the workers (and vice versa). The ports vary depending on the server's role in the cluster.
On the master server:
| Port | Protocol |
|---|---|
| 6443 | TCP |
| 2379-2380 | TCP |
| 10250 | TCP |
| 10251 | TCP |
| 10252 | TCP |
| 10253 | TCP |
On the worker servers (slaves):
| Port | Protocol |
|---|---|
| 10251 | TCP |
| 10255 | TCP |
Make sure to open these ports in the firewall tool you're using (ufw, firewalld, iptables, etc.), according to your chosen Linux distribution.
Disabling SWAP
Kubernetes requires SWAP to be disabled on all cluster nodes. This is because the kubelet doesn't correctly manage memory when SWAP is active, which can cause unexpected behavior in pod scheduling.
First, check if SWAP is active:
# swapon -s
If it is, disable it:
# swapoff -a
However, this deactivation is temporary — it won't survive a reboot. To make the change permanent, edit the /etc/fstab file and comment out the line referring to SWAP:
#/dev/mapper/master--vg-swap_1 none swap sw 0 0
Testing communication between nodes
With /etc/hosts configured, it's worth confirming the servers can communicate with each other before moving on:
# ping slave01
# ping slave02
If the pings succeed (round trip), the network environment is ready.
Restarting the servers
Finally, to make sure all changes (especially disabling SWAP) are properly applied, restart each server:
# shutdown -r now
or
# reboot
Next steps
With the environment prepared — hardware defined, network configured, firewall adjusted, and SWAP disabled — we now have the foundation needed to start installing the actual Kubernetes components.
In Part 2 of this series, we'll install the container runtime and the Kubernetes packages (kubeadm, kubelet, and kubectl) on all nodes.
Continued in Part 2.
Top comments (0)