Kubernetes on Proxmox

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.

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.

Contents

• Division of responsibilities
• KVM virtual machine or LXC
• 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
• When Proxmox and Kubernetes fit

Division of responsibilities

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.

KVM virtual machine 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

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.

A resilient reference architecture

A common highly available starting point may look like this:

Proxmox node A        Proxmox node B        Proxmox node C
├─ Control Plane 1    ├─ Control Plane 2    ├─ Control Plane 3
├─ Worker 1           ├─ Worker 2           ├─ Worker 3
└─ Infrastructure VMs └─ Infrastructure VMs └─ Backup/tools
          │                    │                    │
          └──── VLANs / storage / cluster networks ┘

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

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

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.

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

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.

When Proxmox and Kubernetes fit

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.

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.

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