Kubernetes Clusters from HostGator
See what a 6-node Kubernetes cluster (3 control plane, 3 workers) costs from HostGator. 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.
Share your cluster setup with your friends or colleagues
Control plane
- CPU
- 2 cores or more
- 1 32
- Memory
- 4 GB or more
- 1 128
- Storage
- 40 GB or more
- 20 1 TB
Worker 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
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.