In many organisations the Kubernetes discussion is framed as replacement: “we are migrating from virtual machines to containers”. That is a false choice. A Kubernetes cluster itself runs on virtual machines, and a good share of workloads in a typical company should never go into containers at all. The right question is which workload goes where, and by what criterion.
What stays on Hyper-V
Domain controllers. Active Directory needs a stable machine identity, a predictable address and a full Windows system. There is no reason to containerise it and no supported way to do it well.
Application servers nobody will ever rebuild. An application from 2012, running as a Windows service with its configuration in the registry, will live on a virtual machine until the end of its lifecycle. The cost of containerising it exceeds the benefit, because there is no benefit: it does not scale, it is not released often, and there is no team that would gain from it.
Systems with machine-bound licences. Some commercial software counts licences per host or per physical core, or ties the key to a hardware identifier. In a container that complicates everything.
Infrastructure services for the cluster itself. The image registry, the Git server, the CI system, central logging. They can run inside the cluster, but then a cluster outage takes away the tools needed to repair it. At least one copy of these services should run outside the platform it serves.
What goes to Kubernetes
Frequently released applications. If a team deploys changes several times a week, containers and declarative deployments save time on every release. With one release a quarter that saving does not exist.
Stateless, horizontally scalable applications. Web front ends, APIs, queue workers. This is the case Kubernetes was designed for.
New internal services. A tool written this year by the in-house team should be built as an image and deployed from a repository from day one. There is no migration cost, only a choice of starting platform.
Databases, with care. Database operators have matured and failover works. It does, however, require understanding how storage works in the cluster, failure testing and replication monitoring. A database nobody on the team can recover by hand inside a container is safer on a virtual machine.
A criterion that works
Instead of asking “can this be containerised”, ask three questions:
- How often does it change? Rarely: virtual machine. Often: container.
- Who maintains it? If the team knows Windows Server and does not know Kubernetes, moving the workload to the cluster will not improve its availability; it will lower it.
- What happens when the platform fails? If the workload is needed to repair the platform, it cannot run on it.
Coexistence in practice
Both platforms have to see each other and must not get in each other’s way. A few rules:
- Cluster nodes are ordinary virtual machines on Hyper-V, with reserved resources, no dynamic memory, and checkpoints disabled because they corrupt etcd.
- The cluster network is a separate segment. Traffic between the classic server network and cluster services passes through clearly defined entry points, not pod addresses.
- Authentication in the cluster uses the same identity directory as the rest of the environment. Separate accounts in Kubernetes are a separate audit problem.
- Backups cover both worlds: virtual machines through virtualisation tooling, cluster state through the repository and volume snapshots.
Summary
Hyper-V and Kubernetes solve different problems. The first gives isolation and stability to systems that must run for years without change. The second gives speed and repeatability to systems that change every week. An environment with both kinds of workloads needs both platforms, and the placement of each workload should follow from its characteristics, not from the direction the industry happens to be heading.