Kubernetes on Proxmox: k3s, Talos and Production HA

Building a sovereign Kubernetes platform on Proxmox? WZ-IT combines Proxmox clusters, Kubernetes, networking, storage, GitOps and managed operations into a dependable platform on private or European infrastructure. Kubernetes on Proxmox services

Proxmox and Kubernetes complement each other because they own different layers. Proxmox virtualizes compute, networking and storage. Kubernetes orchestrates applications and containers on top. Together they can form a sovereign platform that does not depend on a hyperscaler or proprietary virtualization.

Before the first VM is created, two decisions shape the cluster: the Kubernetes distribution (k3s, Talos Linux, RKE2 or kubeadm) and the failure-domain design across physical hosts. This guide covers both. The combination is not automatically highly available. If three Kubernetes nodes are virtual machines on the same Proxmox host, the application still has one physical point of failure. A dependable design considers both control layers, their failure domains and their recovery mechanisms together.

Does Kubernetes on Proxmox make sense? When it fits and when it does not

The combination is particularly strong when:

• data control and European or private infrastructure matter,
• a dependable Proxmox cluster already exists,
• several applications need a shared delivery and operations platform,
• VMware is being replaced while the application layer is modernized,
• bare-metal resources, GPUs or specialized networks must be controlled,
• one partner owns infrastructure and Kubernetes end to end.

For a few simple applications, Proxmox with separate VMs, LXC, Compose or Coolify may be more economical. Our decision guide distinguishes those cases.

For an assessment of your environment: plan Kubernetes on Proxmox.

Contents

• Proxmox and Kubernetes: who handles which responsibility?
• Kubernetes on Proxmox: VM or LXC?
• Which Kubernetes distribution on Proxmox: k3s, Talos Linux, RKE2, kubeadm
• The Proxmox side: templates, Talos images, CSI and CCM
• A resilient reference architecture
• High availability at two layers
• Networking: from physical uplink to service
• Storage without duplicate complexity
• Backup and disaster recovery
• Automated provisioning
• Upgrades and ongoing operations
• Does Kubernetes on Proxmox make sense? When it fits and when it does not

Proxmox and Kubernetes: who handles which responsibility?

Clear boundaries prevent the same function from being implemented twice without coordination.

Proxmox sees a worker VM but not the business meaning of its Pods. Kubernetes sees nodes and storage classes but does not automatically know that two VMs share one physical server. The target architecture must connect both views.

Kubernetes on Proxmox: VM or LXC?

Proxmox can run full KVM virtual machines and Linux system containers through LXC. Kubernetes nodes can technically be built with either model. Our architecture recommendation for production is nevertheless clear: run Kubernetes nodes as KVM virtual machines.

Why VMs are the robust default

• Each node has its own kernel and clear system boundary.
• Kernel modules, cgroups, iptables or nftables, eBPF and CNI behavior can be configured independently of the hypervisor.
• Operating-system and Kubernetes upgrades are better isolated from the Proxmox host.
• Snapshots, templates, Cloud-Init and VM migration are established Proxmox functions.
• Security and failure boundaries are easier to reason about.

Why LXC is more demanding

Further reading: LXC vs KVM.

A Kubernetes node in LXC shares the Proxmox host kernel. Nested containers, required kernel modules, cgroups, AppArmor and networking features often need elevated container permissions or specialized host configuration. This can be useful in lab or tightly resource-optimized environments, but increases coupling and troubleshooting complexity.

This is a WZ-IT architecture recommendation, not a claim that Kubernetes in LXC is technically impossible.

Which Kubernetes distribution on Proxmox: k3s, Talos Linux, RKE2, kubeadm

Proxmox does not prescribe a Kubernetes distribution. Every common option runs in KVM VMs. The differences lie in the operating-system model, the path to a highly available control plane and the upgrade process. As of October 2026, the current upstream minor release is Kubernetes 1.37 (1.37.1); k3s and RKE2 ship it as v1.37.1+k3s1 and v1.37.1+rke2r1, and Talos Linux v1.14.4 includes Kubernetes 1.37.1.

k3s describes itself as lightweight Kubernetes in a binary of less than 100 MB and bundles Flannel, CoreDNS, Traefik, ServiceLB and the local-path provisioner. The default datastore is SQLite. A highly available cluster needs three or more server nodes with embedded etcd, in an odd number so that etcd keeps its quorum. Automated upgrades run through the system-upgrade-controller, which upgrades server nodes before agents.

Talos Linux replaces the general-purpose guest OS. It is managed through a declarative gRPC API and, according to its design principles, ships no shell and no SSH. For the API endpoint, Talos offers a shared virtual IP that the control-plane nodes claim through an etcd election; it requires a common Layer 2 network. OS upgrades use an A/B image scheme and roll back automatically if the new version fails to boot. Kubernetes itself is upgraded in a separate step.

RKE2 targets security and compliance, enables FIPS 140-2 compliance and passes the CIS Kubernetes Benchmark with minimal operator intervention. The control plane runs as static Pods with containerd as the embedded runtime. An HA cluster consists of an odd number of server nodes, three recommended, behind a fixed registration address such as a Layer 4 load balancer, round-robin DNS or a virtual IP. Upgrades can be automated with the system-upgrade-controller.

kubeadm is the upstream reference path. An HA cluster needs three or more control-plane machines, either with stacked etcd or with a separate etcd cluster, plus a load balancer for the kube-apiserver. Upgrades run control plane first, then workers; skipping minor versions is not supported.

Independent of the distribution, three control-plane VMs only provide high availability if they sit on three different physical Proxmox hosts. For the API endpoint without Talos, an external load balancer or a virtual IP such as kube-vip is common; our comparison MetalLB vs. kube-vip separates the two roles. A deeper comparison of the three main options is in k3s vs. RKE2 vs. Talos.

Kubernetes in LXC

Lab setups sometimes run k3s in Proxmox LXC containers because of its small footprint. The restrictions described above still apply: shared host kernel, privileged or specially configured containers and closer coupling to the Proxmox host. For production clusters we use KVM VMs.

The Proxmox side: templates, Talos images, CSI and CCM

VM templates with Cloud-Init are the usual base for k3s, RKE2 and kubeadm. Proxmox can convert a prepared Cloud-Init VM into a template; linked clones from a template are a fast way to roll out new VM instances. Hostname, IP address, SSH key and user are then set per clone.

Talos does not use a classic Cloud-Init template. The official Talos Proxmox guide boots the VMs from an ISO built by the Image Factory, applies machine configurations with talosctl and then bootstraps etcd. As VM settings, it recommends among others UEFI (OVMF), machine type q35, CPU type host, VirtIO SCSI rather than VirtIO SCSI Single, and disabled ballooning, because Talos does not support memory hotplug. The QEMU guest agent requires an image that includes the siderolabs/qemu-guest-agent extension. Alternatively, network settings can be supplied via the nocloud mechanism. The complete procedure with all commands, from the Image Factory to upgrades, is covered in Install Talos Linux on Proxmox.

Proxmox CSI and CCM connect both layers. The open-source Proxmox CSI plugin provisions persistent volumes dynamically as VM disks on Proxmox storage, including LVM, LVM-thin, ZFS, Ceph and NFS, and attaches them to the node as block devices. The Proxmox cloud controller manager sets the label topology.kubernetes.io/region to the Proxmox cluster and topology.kubernetes.io/zone to the hypervisor host, and removes Node objects when their VM is deleted. Kubernetes then knows which VMs share a physical host, and topology spread or anti-affinity rules can distribute Pods across hosts. Both projects are maintained by the community, not by Proxmox Server Solutions; their release state and compatibility belong in the platform's upgrade plan.

A resilient reference architecture

A common highly available starting point may look like this:

The three control-plane VMs reside on different physical hosts. Workers are distributed as well. A load balancer or virtual endpoint exposes the Kubernetes API. Placement or anti-affinity rules at the Proxmox layer prevent critical VMs from accidentally sharing one host.

This is not a universal minimum architecture. An edge system, development cluster or GPU cluster may look different. The official Kubernetes production environment documentation does not mandate one vendor design, but emphasizes a replicated control plane, load-balanced API endpoint and sufficient worker capacity.

Physical failure domains first

Real failure boundaries come before VM sizes:

• separate physical Proxmox nodes,
• independent power and network paths where the availability objective requires them,
• redundant switches and bonds where appropriate,
• storage without one controller or server as a critical point,
• sufficient spare capacity to absorb one failed host.

A cluster can only protect against failures that its architecture actually separates.

High availability at two layers

Further reading: Plan Proxmox HA.

Proxmox HA and Kubernetes self-healing are not direct competitors.

Kubernetes reacts at workload and node level

If a Pod fails, its controller replaces it. If a worker remains unavailable, suitable workloads can be scheduled on other workers. This requires free resources, reachable storage and an application that tolerates multiple instances or restarts.

Proxmox HA reacts at VM level

The Proxmox HA manager can restart an affected VM on a remaining node after physical host failure, provided storage and quorum remain available. This can restore a Kubernetes node or other infrastructure component.

Design them together

For replaceable workers, Kubernetes can distribute workloads elsewhere first; restarting the VM later restores capacity. For control-plane VMs, their own replication keeps the API available in the meantime. Uncoordinated HA at both layers can, however, cause unnecessary movement. Timeouts, reserve capacity, placement and maintenance processes should therefore be documented together.

Networking: from physical uplink to service

The network contains several layers whose address ranges must not overlap:

1. Physical and Proxmox layer: uplinks, bonds, Linux bridges or Open vSwitch, VLANs and Proxmox firewall.
2. Node network: control-plane and worker IPs, API endpoint and potentially a storage network.
3. Pod network: addresses and routing supplied by the CNI plugin.
4. Service network: virtual ClusterIP ranges for Kubernetes Services.
5. North-south access: LoadBalancer, Ingress or Gateway API for application traffic.
6. Management access: private paths to the API, GitOps, monitoring and internal services.

In on-premises and Proxmox environments, a project such as MetalLB can provide LoadBalancer addresses through Layer 2 or BGP. External load balancers or provider networking are alternatives. The right option depends on network control, routing, redundancy and desired automation.

The Kubernetes API and internal administration services do not need public exposure. Private Kubernetes access through NetBird explains an identity-aware path over a WireGuard overlay.

Storage without duplicate complexity

Compare ZFS, Ceph and LVM or plan and build Ceph.

According to the Proxmox administration guide, Proxmox supports ZFS, Ceph RBD and CephFS, LVM, NFS, iSCSI and other backends. Kubernetes consumes persistent storage through CSI drivers, StorageClasses and PersistentVolumeClaims. This enables several architecture models.

Model A: shared Ceph cluster, directly through CSI

An existing Ceph cluster can provide block or file storage directly to Kubernetes. The CSI driver creates and attaches volumes while Ceph handles distribution and replication. Permissions and network boundaries between Proxmox and Kubernetes must be separated carefully.

Model B: virtual disks on Proxmox storage

Worker VMs receive virtual disks on ZFS, Ceph or a SAN. Applications use local volumes or a storage system built on top. This is easy to understand but can stack replication across layers. For example, a Kubernetes storage system may replicate data three times while each virtual disk is already triplicated by Ceph. This increases capacity and write-path cost without automatically tripling safety.

Model C: external storage

A separate NFS, Ceph, SAN or cloud storage system connects through a suitable CSI driver. This separates lifecycle and resources from Proxmox but introduces another infrastructure domain.

Model D: local storage with application-level replication

Databases or distributed systems may use high-performance local volumes and replicate data themselves. Pod placement, node failure, rebuild and backup must then align exactly with the application.

A Kubernetes-native storage layer such as Longhorn instead replicates between nodes itself. The Longhorn vs Rook/Ceph comparison helps assess this additional layer.

There is no universally best option. Latency, IOPS, data volume, failure objectives, recovery time and available storage expertise determine the design.

Backup and disaster recovery

Kubernetes backup and restore and PBS offsite backup cover the separate recovery layers.

For Kubernetes on Proxmox, we separate three backup layers.

1. Infrastructure and VMs

Proxmox Backup Server can protect VM disks incrementally and with deduplication. This helps recover complete nodes and infrastructure VMs. A VM snapshot alone, however, does not guarantee application-consistent backups of distributed databases.

2. Cluster state

etcd requires scheduled snapshots, separate retention and a tested restore. Kubernetes and platform definitions also belong in version control, including a documented bootstrap order.

3. Application data

Databases, object storage and volumes need application-specific backups. RPO, RTO, retention, encryption and off-site copies are business decisions. A tool such as Velero can protect resources and supported volumes, but it does not automatically replace native database backups.

The recovery test must demonstrate that infrastructure, cluster state and data can produce a functioning system again.

Automated provisioning

A reproducible build can use the following chain:

1. Proxmox cluster and storage as a documented foundation.
2. VM templates with Cloud-Init.
3. Terraform or OpenTofu to create and place node VMs.
4. Ansible or a Kubernetes distribution to bootstrap operating systems and clusters.
5. GitOps, such as Argo CD or Flux, for CNI, ingress or Gateway, certificates, observability and workloads.
6. Secrets and identity integration outside plaintext repositories.

Automation is not merely convenient. It makes replacement, test clusters, upgrades and disaster recovery repeatable and reduces manual differences between nodes.

Upgrades and ongoing operations

The platform has multiple independent but coordinated lifecycles:

• Proxmox, kernel, Ceph and physical firmware,
• guest operating systems and Kubernetes nodes,
• Kubernetes control-plane and worker versions,
• CNI, CSI, ingress or Gateway and other add-ons,
• applications and their data migrations.

Maintenance should be rolling: verify capacity, drain workloads deliberately, update a node or hypervisor, validate health and storage, then continue. Kubernetes defines version skew policies, but they do not replace an upgrade plan.

Monitoring must correlate both layers. A Kubernetes “Node NotReady” alert is incomplete if its cause is the Proxmox host, Ceph or physical network. Conversely, a healthy VM status says nothing about Pods and applications.

Conclusion

Proxmox forms the sovereign infrastructure foundation and Kubernetes the standardized application layer. A dependable implementation connects both without confusing their responsibilities: physical failure domains, VM placement, Pod orchestration, networking, storage, backup and upgrades are designed as one system.

The result is more than “Kubernetes in three VMs.” It is a reproducible platform that can migrate, modernize and operate applications over the long term.

Have operations taken over: Kubernetes on Proxmox connects the agreed hypervisor and Kubernetes responsibilities.

For implementation, the k3s installation guide covers Cloud-Init VMs, the API endpoint and acceptance. Proxmox vs Kubernetes distinguishes the responsibilities of both platforms.

For the operating model, see What is Talos Linux?; for infrastructure as code, see automating Talos with OpenTofu.

Sources

• Proxmox VE Administration Guide
• Proxmox VE: High Availability Manager
• Proxmox VE: Storage
• Kubernetes documentation: Production environments
• Kubernetes documentation: Storage
• Kubernetes: Version skew policy
• MetalLB: Concepts
• Proxmox VE: Cloud-Init support
• k3s documentation and HA with embedded etcd
• RKE2 documentation and HA installation
• Talos Linux: Proxmox installation guide
• Talos Linux: Virtual (shared) IP
• Kubernetes: Creating highly available clusters with kubeadm
• Proxmox CSI plugin and Proxmox cloud controller manager