Containers and Kubernetes Design: When K8s Is Right and When It's Overhead

A startup with a promising SaaS product deployed on Kubernetes because it seemed like the modern thing to do. The two-person DevOps team spent three months configuring the cluster — writing Helm charts, managing ingress controllers, tuning resource requests and limits, debugging node scheduling issues, and troubleshooting networking policies. In those same three months, the product team shipped two features. The Kubernetes cluster was running beautifully. The product was not moving.

The workload was a straightforward web application with a single API service, a background worker, and a managed database. It had predictable traffic. It did not need service mesh, custom autoscaling policies, or multi-region failover at the orchestration layer. Everything Kubernetes provided — and everything the team was spending their time managing — was capability the product would not need for years, if ever.

When the team migrated to ECS Fargate, the operational overhead dropped dramatically. Deployments that required Helm chart updates and rolling strategy configuration became task definition changes pushed through a CI pipeline. Infrastructure management shifted from cluster operations to service configuration. The two-person DevOps team went from managing Kubernetes to building deployment automation, monitoring, and the CI/CD improvements that actually accelerated delivery. No capability was sacrificed.

This is not an argument against Kubernetes. It is an argument against defaulting to Kubernetes without asking whether the workload warrants the complexity. At EB Pearls, container orchestration design is an architecture decision driven by workload requirements, not industry momentum. Across 900+ projects delivered for over 1,400 businesses, with a 97% client retention rate and ISO 9001/27001 certification, we see the same pattern: teams adopt Kubernetes because it is the industry standard, then spend more time operating the platform than building the product it hosts. Built to Last™ delivery starts with the workload and works backward to the orchestration layer — because the right question is never "should we use K8s?" but "does this workload justify the operational investment?"

Why Kubernetes Dominates the Conversation — and Why That Is a Problem

Kubernetes won the container orchestration war. Docker Swarm faded. Mesos moved to the Apache Attic. Every major cloud provider offers a managed Kubernetes service. The ecosystem of tools, certifications, conferences, and vendor products built around Kubernetes is enormous. When teams evaluate container orchestration, Kubernetes is the default starting point and frequently the default ending point.

This dominance creates a gravitational pull. Engineers want Kubernetes experience on their CVs. Solution architects recommend Kubernetes because it handles the most complex scenarios. Vendor tooling assumes Kubernetes. The result is that teams adopt Kubernetes not because they evaluated alternatives and determined K8s was the best fit, but because not choosing Kubernetes feels like choosing something inferior.

The problem is that Kubernetes is designed for a specific class of operational complexity. It excels when you need fine-grained control over scheduling, networking, scaling, and service discovery across dozens or hundreds of services. It provides primitives — pods, deployments, services, ingress, custom resource definitions — that allow you to model virtually any distributed systems architecture. That flexibility is powerful. It is also expensive to operate, expensive to learn, and expensive to maintain.

For workloads that do not need that flexibility, every Kubernetes primitive is configuration that must be written, reviewed, tested, and maintained. Every cluster upgrade is an operational event. Every networking policy is a debugging surface. The CNCF 2023 Annual Survey reflects broad adoption, but adoption does not mean every adopter is using the right tool for their workload. The question teams should be asking is not whether Kubernetes can run their workload — it can run almost anything — but whether Kubernetes is the most efficient way to run it.

The Decision Framework: When Kubernetes Is the Right Answer

Kubernetes earns its complexity when certain workload characteristics are present. Understanding these characteristics turns the Kubernetes decision from a default into a deliberate architectural choice.

High Service Count with Complex Interdependencies

When an application consists of dozens of microservices with complex communication patterns, service discovery requirements, and independent scaling needs, Kubernetes provides the orchestration primitives that make this manageable. Service objects, ingress rules, network policies, and config maps create a declarative model for how services find each other, communicate, and scale. Without this orchestration layer, managing the same architecture requires custom tooling that inevitably reimplements what Kubernetes already provides.

Multi-Team, Multi-Service Ownership

Kubernetes namespaces, role-based access control, and resource quotas provide isolation boundaries that allow multiple teams to deploy independently within a shared cluster. When your organisation has separate teams responsible for separate services — each with their own deployment cadence and resource requirements — Kubernetes provides the multi-tenancy model that prevents teams from interfering with each other while sharing infrastructure efficiently.

Custom Scheduling and Placement Requirements

Workloads that require GPU scheduling, node affinity, pod anti-affinity, topology-aware placement, or custom scheduling policies need the control that Kubernetes provides. Machine learning training jobs, real-time data processing pipelines, and stateful workloads with specific hardware requirements all benefit from the scheduling sophistication that Kubernetes offers and that simpler orchestration layers do not.

Hybrid and Multi-Cloud Deployment

When workloads must run across multiple cloud providers, across cloud and on-premises infrastructure, or across regions with a consistent operational model, Kubernetes provides the abstraction layer that makes this possible. The Kubernetes API is consistent regardless of where the cluster runs, and configurations are portable across environments. This portability has real value when the architecture genuinely requires it.

Mature Platform Engineering Team

This is the most important criterion and the one most frequently ignored. Kubernetes requires a team with the skills, capacity, and mandate to operate it. Cluster upgrades, security patching, monitoring, capacity planning, cost optimisation, and incident response are ongoing responsibilities. If the team responsible for Kubernetes is also responsible for application development, CI/CD, monitoring, and everything else — as is common in organisations with small DevOps teams — Kubernetes becomes a tax on every other priority.

When Kubernetes Is Overhead: The Alternatives That Work

For workloads that do not meet the criteria above, alternatives deliver the container orchestration benefits without the operational weight.

ECS and Fargate: Container Orchestration Without Cluster Management

Amazon ECS with Fargate removes the cluster management layer entirely. There are no nodes to provision, patch, or scale. There is no control plane to upgrade. You define a task (the equivalent of a pod), a service (the equivalent of a deployment), and the networking configuration. Fargate runs the containers on compute that AWS manages. Scaling, load balancing, and service discovery work through native AWS integrations.

For teams on AWS, ECS Fargate is the most operationally efficient way to run containerised workloads that do not need Kubernetes-level orchestration. The deployment model integrates directly with CodePipeline, CodeBuild, and CloudFormation. Monitoring integrates with CloudWatch. Networking integrates with VPC, ALB, and security groups. The entire operational surface is AWS-native, reducing tooling footprint and learning curve.

The trade-off is lock-in. ECS task definitions are not portable to other cloud providers, and multi-cloud deployment is not possible. For workloads committed to AWS without advanced orchestration needs, these trade-offs are acceptable.

Cloud Run and Azure Container Apps: Managed Container Platforms

Google Cloud Run and Azure Container Apps offer similar managed container experiences on their respective platforms. Cloud Run scales to zero — containers run only when handling requests, and you pay nothing when there is no traffic. This is compelling for workloads with variable traffic patterns where Kubernetes would require over-provisioned capacity or complex horizontal pod autoscaler configuration.

These platforms trade orchestration flexibility for operational simplicity. They handle scaling, load balancing, TLS termination, and container lifecycle management without the networking primitives or multi-tenancy features Kubernetes offers. For workloads behind an HTTP endpoint with automatic scaling, they are often the right choice.

Serverless: When Containers Are Also Overhead

For certain workload patterns — event-driven processing, API endpoints with variable traffic, scheduled tasks — serverless platforms eliminate the container layer entirely. AWS Lambda, Google Cloud Functions, and Azure Functions run code without any container management. The deployment unit is a function, not a container image. Scaling is automatic and granular. You pay per invocation, not per running container.

Serverless does not replace containers for all workloads. Long-running processes and applications needing persistent connections are poor fits. But for workloads where serverless does fit, it eliminates not just Kubernetes overhead but container overhead entirely. The application development trends shaping 2025 reflect this shift — teams increasingly choose the lightest-weight compute model that satisfies their requirements rather than defaulting to the most capable one.

Designing the Cluster When Kubernetes Is Right

When the decision framework points to Kubernetes, cluster design determines whether the investment pays off or becomes a persistent operational burden.

Right-Size the Cluster from the Start

Over-provisioned clusters waste money. Under-provisioned clusters create performance problems and scheduling failures. Start by profiling the actual resource consumption of your workloads — CPU, memory, network — and size the cluster accordingly. Use the Kubernetes resource management documentation to set requests and limits that reflect real usage, not guesses. Requests that are too low cause scheduling contention. Limits that are too high waste capacity. Both are common in clusters designed without workload profiling.

Implement Namespace Isolation Early

Namespaces are cheap to create and expensive to retrofit. Establish a namespace strategy before the first workload deploys. Separate namespaces by team, by environment, or by service domain — whichever maps most cleanly to your organisational boundaries. Apply resource quotas and limit ranges to prevent any single namespace from consuming disproportionate cluster resources. This isolation becomes critical as the cluster grows and more teams deploy to it.

Automate Everything That Can Be Automated

The operational cost of Kubernetes scales with the number of manual processes required to run it. Cluster upgrades, node patching, certificate rotation, backup verification, and security scanning should all be automated. GitOps tools like Argo CD or Flux provide declarative, version-controlled deployment pipelines that reduce manual kubectl operations to near zero. The concept-to-launch delivery process at EB Pearls treats automation as a prerequisite for Kubernetes adoption, not a later optimisation — because a cluster without automation is a cluster that consumes engineer time indefinitely.

Plan for Observability from Day One

A Kubernetes cluster without proper observability is a black box. Implement metrics collection (Prometheus or cloud-native equivalents), log aggregation, and distributed tracing before production workloads deploy. Monitor cluster health, node health, pod health, and application health as separate concerns with separate alerting thresholds.

The Migration That Proved the Point

The startup from the opening spent three months building a Kubernetes cluster for a workload that did not need it. The migration to ECS Fargate took two weeks.

The team replaced Helm charts with ECS task definitions, the ingress controller with an Application Load Balancer, Kubernetes service discovery with AWS Cloud Map, and the horizontal pod autoscaler with ECS service auto-scaling policies.

Every capability the application needed was available through ECS with less configuration and no cluster management. The two-person DevOps team, freed from cluster operations, built a deployment pipeline that reduced release cycles from weekly to daily. They built the project delivery infrastructure that actually accelerated product development.

The lesson was not that Kubernetes is bad. The lesson was that choosing an orchestration platform is an engineering decision, not a brand loyalty decision.

Where to Start

Audit your current workload. Count your services. Map their communication patterns. Identify which services need independent scaling, custom scheduling, or specific placement requirements. If the answer is "we have a handful of services with straightforward scaling needs," the Kubernetes decision framework is pointing you away from K8s.

Evaluate your team's operational capacity honestly. If your DevOps team is two or three people responsible for everything from CI/CD to monitoring to incident response, Kubernetes will consume a disproportionate share of their capacity. Consider the Kubernetes documentation on production best practices and measure your team against it. If the operational requirements exceed your team's capacity, a managed container service like ECS Fargate, Cloud Run, or Azure Container Apps will deliver better outcomes with less investment.

When you are ready to make the container orchestration decision that fits your workload, your team, and your operational reality, talk to our DevOps team. We design container architectures that match the workload — because the goal is not running Kubernetes. The goal is running your product reliably, efficiently, and at the pace your business demands.

Frequently Asked Questions