How do you run Kubernetes on-premises?
Running Kubernetes on-premises means installing it on physical servers or virtual machines you own and supplying the parts a cloud provider normally adds: a highly available control plane, load balancers, persistent storage, certificates, a container registry, upgrades and backups. You can build the cluster yourself with kubeadm, install a distribution such as k3s, RKE2, Talos Linux or OpenShift, or connect your servers to a managed control plane. The software is the same Kubernetes as in the cloud; the extra work is in everything around it.
What the cloud provides and on-premises does not
| Component | What you need on-premises | Common tools |
|---|---|---|
| Control plane | At least three control plane nodes for high availability | kubeadm, a distribution, or a managed control plane |
| etcd | Fast disks, an odd number of members, regular snapshots stored off the cluster | etcdctl snapshot, distribution tooling |
| API endpoint | A virtual IP or load balancer in front of the API servers | keepalived and HAProxy, kube-vip |
| Service load balancers | Something that assigns and announces IPs for type: LoadBalancer |
MetalLB, Cilium, kube-vip, hardware load balancers |
| Persistent storage | A CSI driver backed by local disks, replicated storage or a SAN | Rook-Ceph, Longhorn, vendor CSI drivers |
| Ingress | A controller for HTTP routing and TLS | Gateway API or Ingress controllers, cert-manager |
| Registry | Image storage close to the nodes, mirrors for offline sites | Harbor, pull-through caches |
| Node operating system | Patching, kernel updates, hardening | Immutable operating systems, configuration management |
| Observability | Metrics, logs and alerts for nodes and the control plane | Prometheus, Grafana, log collectors |
| Backups | Cluster state and persistent volumes, restorable elsewhere | etcd snapshots, Velero |
Two of these cause most first-week surprises. A Service of type LoadBalancer stays in pending until you install a load balancer implementation, which load balancing for bare-metal Kubernetes explains. Stateful workloads need a storage layer, compared in storage options for on-premises Kubernetes.
Steps to an on-premises cluster
- Choose the hardware layer. Decide between bare-metal servers and virtual machines on a hypervisor such as Proxmox VE or vSphere. Bare metal vs virtual machines covers the trade-offs.
- Size the control plane. The kubeadm documentation calls for a minimum of three control plane nodes for a highly available cluster. Three etcd members tolerate one failure, five tolerate two. The etcd hardware guide names fast disks as the most critical factor and recommends SSDs.
- Pick an installation method. See the next section.
- Set up networking. Install a CNI plugin, reserve an IP range for load balancer Services, and configure DNS for the API endpoint and applications.
- Add storage. Install a CSI driver and define storage classes for the volume types your applications need.
- Plan upgrades. Kubernetes ships about three minor releases a year, and each gets about 12 months of patch releases. An on-premises cluster has to move through minor versions one at a time to stay supported.
- Back up and test restores. Snapshot etcd and back up persistent volumes to a location outside the cluster, then restore into a test cluster to prove it works.
Ways to install Kubernetes on-premises
| Approach | Examples | Who operates the control plane | Trade-off |
|---|---|---|---|
| Upstream with kubeadm | kubeadm plus your own add-ons | You | Full control, every component is your choice and your responsibility |
| Lightweight distribution | k3s, MicroK8s | You | Small footprint and a simple install; fits small clusters and edge sites |
| Enterprise distribution | RKE2, OpenShift, Talos Linux | You, with vendor tooling and optional support | Opinionated defaults and lifecycle tools, sometimes a subscription |
| Managed control plane with your own nodes | EKS Hybrid Nodes and other services that accept your own nodes | The provider | No control plane to run; nodes need a network path to the provider |
A Kubernetes distribution bundles Kubernetes with a tested set of add-ons and an upgrade path, which removes much of the integration work in the table above. A managed control plane removes the etcd, API server and upgrade work entirely, and leaves you with the nodes, storage and network on site. For a comparison of two AWS options, see EKS Anywhere vs EKS Hybrid Nodes.
Private cloud Kubernetes
“Private cloud Kubernetes” usually means the same setup with self-service on top: teams request clusters or namespaces through an API or portal instead of a ticket. That requires automation for node provisioning, either through a hypervisor’s API, a bare-metal provisioning tool such as Metal3, or infrastructure as code, so that adding capacity does not depend on manual installs.
How Cloudfleet fits
Cloudfleet Kubernetes Engine (CFKE) runs the control plane as a managed service, and you add your own Linux servers or virtual machines as nodes with the CLI, Terraform or cloud-init. Nodes connect outbound only, work behind NAT and need no inbound firewall rules. See self-managed nodes and the Proxmox tutorial.