k3s on bare metal: a three-server cluster on public IPs, built and locked down

Node minimums and control-plane sizing

The k3s requirements page gives a floor for k3s and its packaged components only; your pods come on top. It supports x86_64, armhf and arm64, expects most modern Linux distributions to work, and refuses two nodes with the same hostname.

A cluster of three to ten machines sits at the bottom of that guide's first bracket. What the docs tie k3s speed to is the datastore's disk, and they warn that embedded etcd can struggle on slow disks, so put server nodes on SSD or NVMe. Workers are sized by what you schedule on them. If your images are built for arm64, the Ampere Altra servers are native arm64 hardware that k3s supports.

The network constraint: one public port, no private VLAN

Every one of our dedicated servers has one connected port with a public IPv4, and no private VLAN, second port or cross-connect is sold. Node-to-node traffic in a self-built cluster therefore crosses the public network. The k3s docs list what each node must accept, and from whom:

The docs are blunt about VXLAN: an exposed 8472 opens the cluster network to anyone, so nodes belong behind a firewall that blocks it. The default vxlan backend does not encrypt, while --flannel-backend=wireguard-native encapsulates and encrypts pod traffic between nodes. On a network with no private segment, choose wireguard-native, and check that the WireGuard kernel module loads on every node first, as the docs require.

The k3s requirements page recommends turning ufw off, and lists the rules to keep if you leave it on. On a machine whose only interface is public, keep it on. The docs' ufw rules are 6443 plus the pod and service CIDRs; the rules below add the ports from the docs' inbound-rules table, each narrowed to your own node IPs.

Firewall first, on every node

Apply this before installing anything. Replace the example addresses with your nodes' public IPs and your workstation's address. The pod and service CIDRs are the k3s defaults; if you change them, change these rules too.

SERVERS="203.0.113.10 203.0.113.11 203.0.113.12"
NODES="$SERVERS 203.0.113.20"
ADMIN=198.51.100.7
ufw default deny incoming
ufw limit 22/tcp
for ip in $NODES; do
  ufw allow from $ip to any port 6443 proto tcp
  ufw allow from $ip to any port 10250 proto tcp
  ufw allow from $ip to any port 51820 proto udp
done
for ip in $SERVERS; do
  ufw allow from $ip to any port 2379:2380 proto tcp
done
ufw allow from $ADMIN to any port 6443 proto tcp
ufw allow from 10.42.0.0/16 to any   # pods
ufw allow from 10.43.0.0/16 to any   # services
ufw enable

ufw does not gate ServiceLB host ports or NodePorts: k3s's own iptables rules forward that traffic before ufw sees it. If Traefik should not answer the internet, install with --disable=traefik (or --disable=servicelb), or label only the nodes that should serve it with svccontroller.k3s.cattle.io/enablelb=true.

Then confirm from a machine outside the cluster that 6443, 10250, 2379-2380 and 51820 do not answer it, and that 80, 443 and the NodePort range (30000-32767 by default) answer only on the nodes you intend. Our rack servers and blades also have an out-of-band console, which is the way back in if a rule shuts out SSH.

Installing three servers and the agents

1. Give every machine a unique hostname, and order them on a current Ubuntu or another modern distribution from the Linux server range.
2. On server 1, write a random token to a root-only file, then run the installer with --cluster-init. Passing the token in a file keeps it out of shell history, and unlike a --token flag, out of the process list. --tls-san is optional: add a DNS name you will point at the servers.
3. Copy server 1's /var/lib/rancher/k3s/server/token to the other nodes as /root/k3s-token, mode 600. That file holds the secure-format token, which lets a joining node check the cluster's CA before it sends credentials.
4. Join servers 2 and 3 with --server pointing at server 1 and the same flannel backend: flannel options must match on every server.
5. Join each agent with K3S_URL. The flannel backend is set on servers only, so agents need no --flannel-backend flag.
6. Run kubectl get nodes on a server: three entries with the control-plane and etcd roles, plus your agents.

# server 1
(umask 077; openssl rand -hex 32 > /root/k3s-token)
curl -sfL https://get.k3s.io | K3S_TOKEN_FILE=/root/k3s-token sh -s - server \
  --cluster-init --flannel-backend=wireguard-native --tls-san=k3s.example.com

# servers 2 and 3 (token copied from server 1, mode 600)
curl -sfL https://get.k3s.io | K3S_TOKEN_FILE=/root/k3s-token sh -s - server \
  --server https://203.0.113.10:6443 \
  --flannel-backend=wireguard-native --tls-san=k3s.example.com

# each agent
curl -sfL https://get.k3s.io | K3S_URL=https://203.0.113.10:6443 \
  K3S_TOKEN_FILE=/root/k3s-token sh -

The admin kubeconfig lands at /etc/rancher/k3s/k3s.yaml, owned by root at mode 600. It carries system:masters credentials, so a copy on your workstation, with the server field changed to a server's address, is as sensitive as the token. k3s renews the certificates in that file when it starts; copies have to be refreshed by hand.

The token, quorum and snapshots

• Token. The k3s docs say anyone holding the server token effectively has full administrator access. It also encrypts the bootstrap data in the datastore, so a snapshot cannot be restored without it. Store it with your backups. k3s token rotate replaces it; every node that joined with the old one must then be restarted with the new one.
• Quorum. Embedded etcd wants an odd server count; quorum is (n/2)+1. By that formula three servers keep working with one down, and a fourth adds no tolerance.
• Snapshots. The documented default schedule is 0 */12 * * * (every 12 hours), five kept, in a directory under the k3s data dir on each server. That is the same disk you are protecting, so copy them off the machine or configure the S3 target k3s supports.

Load balancers, hardening and upgrades

The k3s bare metal load balancer question has a built-in answer: ServiceLB, which serves a LoadBalancer Service from host ports. By default it puts the bundled Traefik on ports 80 and 443 of each node, so all node IPs answer web traffic. You can limit ServiceLB to chosen nodes, or disable it and deploy another LoadBalancer controller; extra IPv4 addresses for one come out of the server's own /24.

For hardening, the k3s CIS guide sets protect-kernel-defaults, secrets-encryption, Pod Security admission and audit logging in /etc/rancher/k3s/config.yaml, and k3s leaves host-level changes to you. The requirements page adds one more for flannel clusters: pods with NET_RAW can abuse the bridge network, so untrusted pods need a restricted profile that drops it.

To upgrade, re-run the installer with the same environment and flags, servers first and one at a time, then agents, without skipping a Kubernetes minor version. Drain a node first if a brief API outage would hurt.

Self-built k3s against managed Kubernetes

If the part you want is the workloads rather than the control plane, managed Kubernetes in New York splits the job: we operate an RKE2 control plane, and your dedicated servers are the workers.

Build it yourself when you need another city, encrypted node traffic, k3s itself or full control of the control plane; the dedicated server range lists every line a node can be. Take the managed cluster when New York suits and you would rather not own etcd. Racked machines are live about 30 minutes after an order is approved; builds to order take 4 to 24 hours.