Building an On-Premise Kubernetes Cluster — Part 1: Preparing the Environment

🇧🇷 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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

If it is, disable it:

# swapoff -a

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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.