The real question isn't whether it can run in a container
Kubernetes can provide a consistent platform for deploying, scaling and operating containerized applications. It does not automatically make every business application highly available, secure, stateless, portable, easy to upgrade, simple to monitor, cheap to operate, or recoverable. A business workload may run successfully in Kubernetes while remaining a poor operational fit.
The real decision is not "can this application run in a container?" — it's "can the organization operate, secure, upgrade and recover this application reliably on Kubernetes?"
A sound assessment examines application architecture, state and storage, availability requirements, scaling behaviour, network dependencies, identity and security, operational ownership, backup and disaster recovery, licensing, migration risk, cost and business criticality.
What Kubernetes provides — and what it doesn't
Kubernetes provides a control system for declaring and reconciling application state: workload placement, replica management, rolling updates, service discovery, configuration and secret distribution, resource allocation, failure replacement, horizontal scaling and storage attachment.
Which business workloads fit Kubernetes well
Workloads that need careful evaluation
Traditional monoliths
A monolith can run in Kubernetes, but containerizing it does not automatically create cloud-native behaviour. Long startup time, local file dependencies, in-memory sessions, fixed hostnames and tight database coupling can all remain unresolved. The migration should not pretend the application has become horizontally scalable or failure tolerant when its architecture hasn't changed.
Databases
Databases can run on Kubernetes, but the decision should compare a Kubernetes-hosted database against a managed database service, a dedicated VM, or an external database cluster — evaluating latency, IOPS, replication, backup, point-in-time recovery, operator maturity and team expertise. A PersistentVolume supplies storage abstraction, but database durability and consistency remain the application's responsibility.
Applications with local state or unsupported requirements
Dependencies on local filesystem paths, static IP addresses, local license files, or unsupported operating systems and kernel modules may fit better in virtual machines — KubeVirt or Harvester can run VMs through Kubernetes, but VM operation remains different from ordinary container workloads.
Choosing the right workload controller
StatefulSets provide stable identity and persistent-storage association, but they do not automatically solve application-level high availability, backup or replication.
Availability architecture
Kubernetes replaces failed Pods, but application availability depends on architecture — multiple replicas, multiple nodes, multiple failure domains, load balancing, topology spread, redundant storage and databases, and tested recovery.
Replicas are not automatically highly available. Three replicas can still fail together when they share one node, one zone, one storage array, one database, or one configuration error. High availability requires independent failure domains.
A PodDisruptionBudget can limit how many replicas are voluntarily disrupted during node drains, but it does not prevent every failure — use it together with sufficient replicas, spare node capacity, topology spreading, and correctly configured readiness, liveness and startup probes. Poor probes can create outages by restarting healthy but slow applications, or routing traffic to unready replicas.
Resource planning, health checks and storage
Every production workload should define or deliberately omit CPU/memory requests and limits. Understated requests cause node overcommitment and unpredictable latency; overstated requests reduce utilization and can prevent scheduling. Requests should follow measured behaviour, not one universal template — and the kubelet can still evict Pods under node pressure regardless of PodDisruptionBudgets, so capacity monitoring matters too.
Storage design
Security and backup essentials
Kubernetes security depends on identity, RBAC, ServiceAccounts, namespace design, network policy, Pod security, Secrets, image trust and audit logging. Namespaces can support separation and quota, but multi-tenant isolation also depends on networking, policy and node controls — namespaces alone are not complete security boundaries.
Every business workload should define protection for Kubernetes resources, persistent volumes, databases, object storage, external services, Secrets, container images and infrastructure definitions — with a documented RPO, RTO, recovery location, recovery order and last-tested date. See the Kubernetes backup encryption guide and the backup testing guide for the recovery side of this.
Migration assessment
Inventory the application
Record components, processes, ports, databases, files, scheduled tasks, external services, credentials, certificates, users, dependencies and owners.
Classify state
Identify state stored in local filesystem, shared filesystem, database, object storage, memory, message queue, external systems and user sessions.
Define availability
Record required uptime, maximum data loss, maximum downtime and peak demand.
Test container behaviour
Confirm the application starts without manual intervention, configuration and logs are externalized, shutdown is graceful, and multiple replicas can run where required.
Test failure
Simulate Pod deletion, node loss, storage interruption, dependency failure, deployment rollback, credential rotation and backup restore.
Choose an approach
Rehost with minimal change, replatform with targeted improvements, refactor for stronger scalability, or retain the workload outside Kubernetes when vendor support, licensing or hardware dependency makes that the correct decision.
Common mistakes
Platform consistency is not enough reason to move an unsuitable application. Measure the operational benefit.
A legacy architecture inside a container remains a legacy architecture. Document its real limitations.
Replicas may share the same node, storage and database. Design independent failure domains.
A StatefulSet does not replace database backup, point-in-time recovery or integrity testing.
Incorrect limits can create throttling and memory failures. Measure actual behaviour.
Healthy nodes and Pods do not prove successful business transactions. Monitor user outcomes.
Recovery architecture should be designed before production cutover, and tested before approval.
Business workload readiness checklist
0 / 24Frequently asked questions
Yes, when the application architecture, operational requirements, security model, recovery plan and team capabilities fit the platform.
Stateless services, horizontally scalable APIs, event-driven workers, batch workloads and applications designed for automated deployment often fit well.
Yes, but containerization does not automatically make the application scalable, resilient or cloud native.
They can, but the decision should compare Kubernetes operation with managed databases, virtual machines and dedicated database platforms.
A Deployment generally manages interchangeable stateless Pods. A StatefulSet provides stable identity and persistent-storage relationships for stateful workloads.
No. High availability also requires replicas, failure-domain distribution, spare capacity, resilient data services and external dependency planning.
It limits voluntary disruption to a selected set of Pods. It does not prevent every involuntary failure.
No. Replication and reconciliation do not protect against deletion, corruption, ransomware or site loss.
Not by themselves. Isolation also depends on RBAC, networking, admission controls, node security and tenant trust.
No. Virtual machines, managed services, SaaS platforms or dedicated infrastructure may remain better choices.
Inventory the application, classify its state, map dependencies, define RPO and RTO, test container behaviour, and compare operating models.
Consider separate clusters when workloads require different trust boundaries, administrators, upgrade schedules, compliance controls or blast-radius limits.
Put the right workloads on Kubernetes
Kubernetes is strongest when workloads support automated deployment, replaceable instances, explicit configuration, measurable health, externalized state, controlled scaling and tested recovery. It's weaker when an application depends on one machine, one manual administrator, one local filesystem, or one unsupported vendor configuration.
Start with the business service. Map its state, dependencies, failure modes and recovery requirements, then compare Kubernetes with virtual machines, managed services and existing infrastructure. Move the workload when Kubernetes creates a measurable operational advantage — keep it elsewhere when the platform would add complexity without improving delivery, availability, security or recovery.