Lesson 2: Installing Rocky Linux 10 on Node 4

Node 4 needs a fresh operating system before it can serve as the first RKE2 control plane. Rocky Linux is a community-driven, enterprise-grade Linux distribution that is fully compatible with Red Hat Enterprise Linux. We chose it for its open source nature, stability, and first-class support by Hetzner.

This is the 2nd lesson of the guide Migrating from k3s to RKE2. Make sure you have completed the previous lesson before continuing here. The full list of lessons in the guide can be found in the overview.

Installing Rocky Linux via Hetzner Robot#

Before we can install the operating system, we need to configure the server identity in Hetzner’s management interface. Log into the Hetzner Robot web interface and set the server name (e.g., node4) along with a reverse DNS entry. A proper reverse DNS entry helps with server identification in logs and monitoring tools.

After receiving the root credentials via email, access the server through SSH:

$ ssh root@<node4-public-ip>
# Enter password from email

Hetzner provides the installimage tool which makes OS installation straightforward on their dedicated servers. This tool handles disk partitioning, OS deployment, and basic configuration in one step:

$ installimage

In the configuration editor, select Rocky Linux 10 and set the hostname to match our naming convention. We use a simple partition layout without swap, because Kubernetes requires swap to be disabled, dedicating the entire disk to the root partition with a small separate /boot:

PART  /boot  ext3   1024M
PART  /      ext4   all

After installation completes, reboot the server to boot into the new operating system:

$ reboot

When reconnecting via SSH, we see a host key warning because the server’s SSH keys changed with the new OS installation. This is expected! Remove the old entries from ~/.ssh/known_hosts on the local machine and accept the new key when prompted.

Essential Security Configuration#

A freshly installed server needs immediate security hardening before we proceed with any other configuration. These steps protect the server from unauthorized access and establish good security practices from the start.

Change the Root Password#

The default root password was sent via email, which means it has already been transmitted over the network. Change it immediately:

$ whoami
root

$ passwd
Changing password for root.
New password: ********
Retype new password: ********
passwd: password updated successfully

Update the System#

Security vulnerabilities are patched regularly, and the installation image may be weeks or months old. Update all packages to ensure the system has the latest security patches before exposing it to any workloads:

$ dnf update -y

Create a Dedicated User Account#

Running commands as root is dangerous because it provides unrestricted access to the system. We create a dedicated admin account that requires explicit sudo for privileged operations, providing both safety and accountability.

Choose a username that indicates the account’s purpose and remains consistent across all cluster nodes. We use k8sadmin throughout this guide for Kubernetes administration:

$ useradd k8sadmin

$ passwd k8sadmin
New password:
Retype new password:
passwd: password updated successfully

$ usermod -aG wheel k8sadmin

Adding the user to the wheel group grants sudo privileges on RHEL-based systems.

Test that the new user account works by opening a new SSH session from the local machine:

$ ssh k8sadmin@<node4-public-ip>

Set Up SSH Key Authentication#

Password authentication is vulnerable to brute-force attacks and requires typing credentials on every connection. SSH key authentication eliminates both problems. Keys are far harder to crack and connect without password prompts.

Generate an ED25519 key pair on the local machine, which offers better security and performance than RSA:

$ ssh-keygen -t ed25519 -f ~/.ssh/node4_k8sadmin_ed25519
$ ssh-copy-id -i ~/.ssh/node4_k8sadmin_ed25519 k8sadmin@<node4-public-ip>

To avoid typing the full connection details every time, add an entry to the ~/.ssh/config file:

Host node4
  HostName <node4-public-ip>
  User k8sadmin
  IdentityFile ~/.ssh/node4_k8sadmin_ed25519
  IdentitiesOnly yes

Verify that key-based authentication works by connecting with just the host alias:

$ ssh node4

Disable Root Login#

With SSH key authentication working for our admin user, we can now disable root login entirely. Automated bots constantly scan the internet for servers accepting root SSH connections, making this a critical security measure:

$ sudo vi /etc/ssh/sshd_config

# Set: PermitRootLogin no

$ sudo systemctl restart sshd

From this point forward, only the k8sadmin account can access the server, and all administrative tasks require explicit sudo elevation. Using sudo also logs all privileged commands to the system journal, providing an audit trail of who did what and when.

Optional: Set Up Tailscale#

Managing bare-metal servers often means dealing with changing IP addresses, firewall rules, and VPN configurations. Tailscale simplifies this by creating a secure mesh network that works regardless of network topology. With Tailscale, we can access cluster nodes using consistent hostnames (like node4.tailnet-name.ts.net) from anywhere, even behind NAT or firewalls.

$ sudo dnf config-manager --add-repo https://pkgs.tailscale.com/stable/centos/10/tailscale.repo
$ sudo dnf install -y tailscale
$ sudo systemctl enable --now tailscaled
$ sudo tailscale up

Follow the authentication URL provided in the output to connect the machine to the Tailscale network. After authentication, verify the Tailscale IP address:

$ tailscale ip -4

For servers that should remain permanently accessible, consider disabling key expiry in the Tailscale admin console. This removes the need for periodic re-authentication, but it also means a compromised server could maintain access indefinitely, so use this option with caution.

Configure Timezone and Hostname#

Consistent timezone configuration across all cluster nodes is important for log correlation and debugging. When investigating issues, we need timestamps to match across nodes, so we set all nodes to their correct local timezone.

As our cluster nodes are located in Helsinki, we set the timezone to Europe/Helsinki:

$ sudo timedatectl set-timezone Europe/Helsinki

The hostname should already be set from the installation, but we verify it matches our naming convention:

$ hostname
node4

# If not correct, set it with:
$ sudo hostnamectl set-hostname node4

Install Essential Tools#

A Kubernetes node needs various tools for administration, troubleshooting, and automation. We install these now so they are available when needed during later lessons:

$ sudo dnf install -y \
    vim \
    git \
    bash-completion \
    tar \
    unzip \
    net-tools \
    bind-utils \
    jq

You can find additional information on the setup of each tool in their respective documentation.

Verify System Readiness#

Before proceeding to network configuration in Lesson 3, we verify that the system is properly configured and can communicate with the outside world. These checks catch common issues like DNS misconfiguration or firewall problems early:

# Check kernel version (should be 6.12+ for Rocky 10)
$ uname -r
6.12.0-124.27.1.el10_1.x86_64

# Check available memory
$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi       5.0Gi       119Gi       4.3Mi       1.2Gi       120Gi
Swap:             0B          0B          0B

# Check disk space
$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/md1        1.8T  1.5G  1.7T   1% /

# Verify DNS resolution works
$ nslookup philprime.dev
Server:		100.100.100.100
Address:	100.100.100.100#53

Non-authoritative answer:
Name:	philprime.dev
Address: 104.21.66.10
Name:	philprime.dev
Address: 172.67.197.206
Name:	philprime.dev
Address: 2606:4700:3032::6815:420a
Name:	philprime.dev
Address: 2606:4700:3036::ac43:c5ce

# Verify HTTPS connectivity (needed to download RKE2)
$ curl -s https://get.rke2.io > /dev/null && echo "Internet OK"
Internet OK

If any of these checks fail, resolve the issue before continuing. Network problems at this stage will cause harder-to-diagnose failures during RKE2 installation.

Lesson Conclusion

Congratulations! Node 4 is now running Rocky Linux 10 with security hardening complete, ready for network configuration. You have completed this lesson and you can now continue with the next one.