Clarify platform responsibilities: WZ-IT designs and operates Kubernetes on Proxmox. Consulting covers the boundaries between hypervisor, cluster and applications.
Proxmox VE manages virtual machines and Linux system containers. Kubernetes controls container workloads through its own API. The comparison therefore concerns different layers: a business can use Proxmox without Kubernetes, Kubernetes without Proxmox or both together. Foundations: Proxmox VM management and Kubernetes components.
As of October 2026. This article supports the platform decision. The architecture overview covers the combined platform; the installation guide walks through a k3s deployment. No original measurements are claimed here.
Contents
- Responsibilities compared
- When each platform fits
- High availability has two layers
- Plan storage and backup separately
- Operations and decision
- Sources
Responsibilities compared
| Question | Proxmox VE | Kubernetes |
|---|---|---|
| What is managed? | Hosts, KVM VMs and LXC system containers | Pods and declared application resources |
| Where does the operating system run? | Each VM has its own guest kernel | Application containers use their node's kernel |
| Which interface is central? | Proxmox web interface and API | Kubernetes API and declarative resources |
| What is replaced after failure? | HA can restart configured virtual guests | Controllers can replace workloads on suitable nodes |
| Who provides infrastructure? | Proxmox on existing servers and storage | Physical or virtual nodes must be provisioned |
The table combines documented VM properties, LXC system containers as well as Kubernetes components and container isolation. Kubernetes is not another name for a Proxmox cluster. LXC and a pod are also different operational objects; Proxmox, Docker and LXC compared explains that boundary.
When each platform fits
| Starting point | Path to assess | Deciding question |
|---|---|---|
| Windows and Linux servers with separate guest operating systems | Proxmox as a VM platform | Which applications and operating systems must continue unchanged? |
| Container applications with declarative deployment across nodes | Kubernetes on suitable infrastructure | Can the team operate the cluster, add-ons and applications? |
| Existing Proxmox cluster plus a need for container orchestration | Kubernetes nodes as Proxmox VMs | Are physical failure domains and responsibilities clear? |
| A few applications without cluster requirements | Assess a VM with Docker Compose or an application platform | Does the need justify another orchestration layer? |
These are decision criteria, not a universal performance ranking. Kubernetes can run on physical or virtual nodes. The combination fits when both VM management and an application platform are required. Existing virtualisation alone does not create a need for Kubernetes. See Do we need Kubernetes?.
High availability has two layers
Proxmox HA concerns configured VMs and containers. Kubernetes controls desired application state. VM restart and pod replacement have different prerequisites; neither mechanism alone guarantees database or application availability.
For k3s with embedded etcd, at least three server nodes form the HA control plane. The k3s documentation describes its quorum. For planning, distribute control-plane VMs across independent hosts, check placement after maintenance and make the API endpoint redundant. Three VMs on the same host lose their foundation together if that host fails. Spare capacity, networking and storage belong in the same failure plan.
Plan storage and backup separately
Proxmox supplies storage for virtual guests. Kubernetes attaches application volumes through Persistent Volumes and Claims. An existing Proxmox datastore does not automatically become a Kubernetes StorageClass. Drivers, access and recovery must fit the chosen storage model.
For backup, distinguish VM data, Kubernetes state and application data. For k3s, datastore backup also includes server tokens needed for recovery. Databases and persistent volumes need additional suitable backups. Kubernetes backup and restore covers combined recovery planning.
Operations and decision
Document four things before choosing: existing VM workloads, deployment requirements, owners for each layer and verifiable recovery procedures. Hypervisor, guest operating system, distribution and add-on updates remain separate tasks. Combining the platforms adds a management layer; it does not remove these tasks.
Agree the target architecture: Kubernetes on Proxmox covers consulting, implementation and agreed operations. For deployment, the k3s guide covers VMs, bootstrap and acceptance.
