Do we need Kubernetes?

Which target platform fits your applications? WZ-IT assesses the application, team and operating objectives and designs an appropriate architecture, from Compose or Coolify to Kubernetes on private or European infrastructure. Kubernetes application modernization

Not every company and not every application requires Kubernetes. Kubernetes fits when the platform standardizes existing complexity in delivery, scaling and operations. It does not fit when the additional cluster lifecycle creates more work than the applications require or the organization can own over time.

The question should therefore not be “Are we large enough for Kubernetes?” A better question is: Which operational problems must we solve, how do we expect the system to evolve, and which platform can our team operate reliably? User and server counts alone do not answer it.

Contents

• The short decision
• Strong signals for Kubernetes
• Warning signs against Kubernetes
• Decision matrix
• Five common starting points
• The often overlooked team question
• Operating cost, not just infrastructure cost
• A meaningful Kubernetes pilot
• Kubernetes as a modernization target

The short decision

As a practical guideline:

• A few stable applications, a small team and infrequent change: usually a VM, Docker Compose or Coolify.
• Many services, several teams, frequent deployments and shared platform standards: Kubernetes becomes relevant.
• Dynamic load, extensive automation and substantial resilience requirements: Kubernetes can clearly justify its cost.
• No named operational owner: do not start with Kubernetes, regardless of the technology.

Kubernetes is not automatically more professional than a smaller platform. A documented Compose environment with monitoring, backups, tested restores and clean delivery is more professional than a neglected Kubernetes cluster without an owner.

Strong signals for Kubernetes

Kubernetes typically adds value when several of the following conditions apply at once.

Many workloads with recurring operating requirements

When numerous APIs, web applications, workers and scheduled jobs must follow similar rules, a shared abstraction becomes valuable. Delivery, health checks, resources, secrets, networking and observability can be standardized.

Multiple teams or products

Kubernetes can form an internal platform on which teams deliver applications according to defined rules. Namespaces, RBAC, quotas, policies and GitOps create a shared operating model without granting every team unrestricted infrastructure access.

Frequent, automated deployments

Rolling updates, declarative state and GitOps are most useful when changes are delivered frequently and reproducibly. Their value is much lower for two manual releases each year.

Horizontal scaling and changing demand

Workloads that can run multiple instances in parallel can be scaled from metrics. This still requires a suitable application architecture, correct resource requests and available cluster capacity.

Maintenance and failures without extended interruption

Multiple replicas, Pod Disruption Budgets, distributed nodes and controlled rollouts can absorb maintenance and partial failures. Kubernetes orchestrates those mechanisms, but it does not remove common failure domains in the hypervisor, storage or network.

A sovereign platform instead of isolated provider services

A portable Kubernetes platform can run on Proxmox, bare metal, European providers or EKS, AKS and GKE. This does not remove every form of lock-in automatically, but it creates a more consistent application layer across infrastructure models.

Warning signs against Kubernetes

The following starting points favor a simpler solution or at least argue against an immediate production launch:

• There are only one or two stable applications and very few deployments.
• The team has neither time nor a partner for cluster upgrades, security and incidents.
• The main reason is “Kubernetes is the industry standard” rather than a concrete problem.
• The application is not cleanly containerized and has unknown dependencies.
• Backups, recovery objectives and monitoring are already unclear today.
• A single physical server remains the entire infrastructure. A cluster on top does not create physical high availability.
• The budget considers server cost but not platform maintenance and learning effort.

Kubernetes cannot modernize a legacy application merely by moving its containers. Data storage, configuration, sessions, filesystem access, jobs and external dependencies must be understood first.

Decision matrix

This is not a numerical scorecard. A strict regulatory access requirement or extreme scaling requirement can outweigh several minor counterarguments. The target architecture as a whole is what matters.

Five common starting points

1. A conventional business application

One web application, one API and one PostgreSQL database on a server normally do not need Kubernetes. Docker Compose or Coolify provide a much smaller operational surface. Monitoring, backup and restore remain mandatory either way.

2. Existing software must be taken over and containerized

Kubernetes is not automatically the first step. The application, data flows, persistence, delivery and dependencies are stabilized first. Only then should the choice between VM, Compose, Coolify and Kubernetes be made. That distinction is central to a refit: establish a dependable operating model first, then choose the appropriate orchestration layer.

3. A growing SaaS platform with several services

Multiple APIs, workers, events, separate environments and frequent releases are a common Kubernetes starting point. The platform can standardize delivery, resources and policies. Databases may run in the cluster, on separate infrastructure or as managed services depending on the operating model and risk profile.

4. Distributed edge or site systems

Kubernetes may fit central platform services while small sites use K3s, individual containers or specialized edge components. Not every location needs a full cluster. Networking, offline behavior and centralized lifecycle management matter more than using one technology everywhere.

5. Regulated or sovereign infrastructure

Kubernetes on Proxmox or European bare-metal providers can create a controllable platform. Relevant considerations include tenant isolation, identity, private access, audit, encryption, backup locations and traceable updates. An open-source foundation alone does not satisfy compliance requirements.

The often overlooked team question

Kubernetes shifts work. Developers gain a standardized platform, while a new platform layer appears. Someone must own:

• cluster and node upgrades,
• CNI, ingress or Gateway, DNS and certificates,
• storage classes and data recovery,
• RBAC, policies, secrets and vulnerabilities,
• GitOps controllers and delivery processes,
• monitoring, logging, alerting and incident response,
• capacity, cost and add-on lifecycle.

The official production environment documentation deliberately distinguishes learning environments from highly available production clusters. An installer reduces setup effort, not long-term responsibility.

Ownership may sit with an internal platform team, a DevOps team working with a specialist partner or a managed-operations service. It must not remain implicit between development and administration.

Operating cost, not just infrastructure cost

Kubernetes itself has no license fee. The cluster still incurs cost through:

• additional nodes and reserves for failures and maintenance,
• load balancers, storage, backup and observability,
• building and maintaining platform automation,
• regular version and add-on upgrades,
• security work and incident response,
• training and technical documentation.

Managed Kubernetes removes some of this work, not all of it. EKS, AKS or GKE operate substantial control-plane components; applications, workload security, permissions, networking, data and cost control remain shared or customer responsibilities.

The economic question is therefore: does the standardized platform save more recurring work and risk across applications and teams than it creates itself?

A meaningful Kubernetes pilot

A useful pilot is not a “Hello World” deployment. It is a small test of the future operating model:

1. Select a representative but non-critical application.
2. Document the target architecture and responsibility boundaries.
3. Build delivery through Git and CI/CD or GitOps.
4. Define resources, health checks, secrets and network access.
5. Connect metrics, logs and alerts.
6. Test a node failure and a controlled upgrade.
7. Create a backup and perform an actual restore.
8. Compare effort, delivery speed and failure modes with the existing platform.

Only this test shows whether Kubernetes creates an operational advantage for the organization. A successfully running demo Pod does not.

Kubernetes as a modernization target

Kubernetes does not need to be the starting point of a migration. WZ-IT separates the path into four decisions:

1. Understand the current system: capture processes, dependencies, data, networking, deployments and operating issues.
2. Modernize the application: containerize it, externalize configuration, add health checks and organize data paths.
3. Choose the target platform: select VM, LXC, Docker Compose, Coolify or Kubernetes based on real requirements.
4. Build operations: combine delivery, access, observability, backup, security and ownership.

When Kubernetes fits, it can run on Proxmox and sovereign infrastructure. Internal services and the cluster API can remain private and identity-aware through NetBird.

Conclusion

You do not need Kubernetes simply because you use containers. You need it when a distributed, declarative platform solves concrete delivery, scaling, resilience and governance problems more effectively than a smaller alternative.

The right architecture is the simplest one that meets your requirements reliably and can be operated over time. That may be Kubernetes. It may just as deliberately be Docker Compose, Coolify or a solid VM architecture.

Sources

• Kubernetes documentation: Production environments
• Kubernetes documentation: Cluster administration
• Kubernetes documentation: Workloads
• Docker documentation: Compose
• Coolify documentation