Data last updated 35 minutes ago

Kubernetes Clusters from HostHatch

See what a 6-node Kubernetes cluster (3 control plane, 3 workers) costs from HostHatch. 1 provider matches. Prices are checked daily. These are self-managed clusters you set up yourself with k3s, k0s, RKE2, Talos Linux, MicroK8s or kubeadm. We will add Managed Kubernetes later.

We earn commissions when you shop through the links below. There are no additional costs for you. This helps us to keep the site running without ads.

serverlist.dev compares 2347 servers!

Share your cluster setup with your friends or colleagues

Control plane

3 nodes

CPU: 2 cores or more; 1 32
Memory: 4 GB or more; 1 128
Storage: 40 GB or more; 20 1 TB

Same size as the worker nodes etcd stays available with 1 node down.

Worker nodes

3 nodes

CPU: 4 cores or more; 1 32
Memory: 8 GB or more; 1 128
Storage: 80 GB or more; 20 1 TB

Matching clusters

Sort by

The stated total price includes the servers and private networking if we know that information. Additional costs for storage, networking or other services might apply. We will add Managed Kubernetes, Load Balancer and other services in the future. Let us know what you need to plan your cluster.

Setting up your own cluster

The following guide describes how to turn your servers into a small Kubernetes cluster. It is not specific to any provider or operating system, and it is easier than it might sound initially. If you are new to k8s, this guide will help you get started.

Pick a k8s system

System	Benefits	Cluster state	Comes with
k3s	Single binary. Quick start. Runs fine on 2 GB nodes.	SQLite on one server, embedded etcd for multiple, or an external PostgreSQL / MySQL	Traefik ingress, ServiceLB, local-path storage, Flannel
RKE2	The same installer idea as k3s with a stricter security default (CIS).	Embedded etcd	An ingress controller, Canal networking
k0s	Single binary with few opinions, easy to pair with your own addons.	etcd, or SQLite / external database via kine	Kube-router or Calico
Talos Linux	An immutable OS that only runs Kubernetes, managed through an API with no SSH.	etcd	Flannel. Needs a provider that lets you boot a custom image or ISO.
MicroK8s	Snap based installs on Ubuntu, addons switched on one by one.	dqlite	Addons for ingress, DNS, storage and more
kubeadm	Plain upstream Kubernetes.	etcd	Nothing: good luck

A k3s cluster in four steps

For your setup: 3 control-plane nodes and 3 workers. IP Addresses in the examples are placeholders.

1. First server

On one control-plane node, install k3s as a server:

curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init \
  --node-ip 10.0.0.2 \
  --tls-san 10.0.0.2

--cluster-init starts embedded etcd, so more servers can join later. --node-ip is the private address when there is one.

2. More servers

On the other 2 control-plane nodes, install k3s as a server that joins the first one. The token is in /var/lib/rancher/k3s/server/node-token on the first server.

curl -sfL https://get.k3s.io | K3S_TOKEN=<token> \
  sh -s - server \
  --server https://10.0.0.2:6443 \
  --node-ip 10.0.0.3

3. Workers

On each of the 3 workers, install k3s as an agent that points to the first server:

curl -sfL https://get.k3s.io | \
  K3S_URL=https://10.0.0.2:6443 \
  K3S_TOKEN=<token> sh -s - agent \
  --node-ip 10.0.0.10

4. kubectl from your machine

Copy the kubeconfig and point it at the server:

scp <user>@<server>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
# change "server:" in the file from 127.0.0.1
# to the server's address
kubectl get nodes

Things to decide and common problems

SQLite or etcd

A k3s server started without --cluster-init keeps its state in SQLite. That's fine for one control-plane node but cannot be shared with other servers. Start the first server with --cluster-init if you want high availability later. An existing single server can be switched to etcd mode by restarting it with the flag.

Run 1, 3 or 5 servers: etcd needs a majority, so 4 servers survive no more failures than 3. etcd also writes to disk constantly and is sensitive to slow storage. Prefer servers within the same location and servers with NVMe.

No private network

Without a private network the nodes talk over their public addresses. That works, but the traffic between them should be encrypted and the cluster ports must not be open to the internet. k3s can encrypt pod traffic itself:

# encrypt pod traffic between nodes
--flannel-backend=wireguard-native
# advertise the public address
--node-external-ip <public-ip>

Another option is a mesh VPN like WireGuard or Tailscale between the nodes, with --node-ip set to the VPN.

Firewall ports

Open these between your own nodes only. The ingress ports are the obvious exception.

6443/tcp	Kubernetes API (also from your own machine)
2379-2380/tcp	etcd, between servers
10250/tcp	kubelet, all nodes
8472/udp	Flannel VXLAN (default backend)
51820/udp	Flannel WireGuard backend
80, 443/tcp	Your ingress. Open to the world or your CDN like Cloudflare

Traefik and ingress

k3s installs Traefik as its ingress controller, listening on ports 80 and 443 of every node. Point your DNS at one or more node IPs and it works out of the box. Depending on your DNS and CDN this might be an easy way to implement a basic fallback switch. Of course it does not replace a highly sophisticated setup. To use ingress-nginx or a Gateway API controller instead, install with --disable traefik.

Change Traefik's settings with a HelmChartConfig in /var/lib/rancher/k3s/server/manifests/; direct edits to the manifest are overwritten on restart. For certificates, cert-manager with Let's Encrypt is the usual pairing.

Storage: local-path or Longhorn

k3s's local-path provisioner stores volumes on the node's own disk. It is simple and fast, but the pod and data is tied to that node.

Longhorn replicates volumes across nodes. It needs open-iscsi on every node (and an NFS client for shared volumes), and it multiplies disk usage by the replica count. Replication traffic runs between the nodes, which is where a private network or WireGuard pays off. Rook/Ceph and OpenEBS are the heavier alternatives, and some providers also have a CSI driver for their block storage.

Backups and upgrades

k3s with etcd takes snapshots every 12 hours. Add --etcd-s3 to copy them to your s3 bucket, or run k3s etcd-snapshot save by hand before changes.