The short answer
Kubernetes is an orchestration API. You describe the end state with objects such as Deployment, Service and Ingress, and controllers keep the cluster close to that state. A managed container service starts higher up. You give it an image and a few settings, and it runs compute, load balancing, certificates and scaling behind an endpoint.
The question is who owns the moving parts. With Kubernetes you own nodes, add-ons, ingress, policy and upgrades. With a managed container service the provider owns the cluster and host layer. You own the image, health checks, secrets, identity and release process.
Managed Kubernetes sits in the middle. EKS, GKE and AKS run the control plane, but you still get the Kubernetes API and usually still own worker nodes and add-ons. Compare the operating contract, not the product name. Ask what breaks at 2 a.m. and who patches it.
| Aspect | Kubernetes | Managed container services |
|---|---|---|
| Unit you manage | Clusters, nodes, Pods, namespaces and add-ons | Services, revisions and container images |
| Runtime control | High. Privileged pods, DaemonSets, custom CNI and device plugins | Limited. No node access, fewer host features, provider networking |
| Scaling | HorizontalPodAutoscaler plus Cluster Autoscaler or Karpenter | Provider scales instances on concurrency, CPU or queue depth |
| Upgrades and patching | You own node versions, add-on upgrades and certificate rotation | Provider patches host and platform; you own image and dependencies |
| Networking and ingress | CNI, ingress controller, Gateway API, NetworkPolicy, service mesh | Provider ingress, custom domains and limited L4 and L7 controls |
| Portability | API is portable; storage, ingress and IAM need work | Image moves; IAM, secrets and triggers are provider specific |
| Team fit | Platform team, many services, custom workloads | Small app team, few services, fast start |
How Kubernetes works
A cluster has a control plane and worker nodes. The API server takes requests, etcd stores state, the scheduler places Pods, and controllers reconcile. Each node runs a kubelet and a container runtime. Set resource requests and limits so scheduling works, and add readiness and liveness probes so traffic and restarts follow real health.
Core objects cover common cases. Deployments run stateless Pods. StatefulSets give stable names and storage. Services provide virtual IPs. Ingress or Gateway API exposes HTTP. ConfigMaps and Secrets inject settings. Jobs and CronJobs handle batch work. HorizontalPodAutoscaler scales Pods, and Cluster Autoscaler or Karpenter adds nodes.
The gaps are add-ons. You pick a CNI plugin, an ingress controller, cert-manager, external-dns and a CSI driver. You set RBAC, NetworkPolicy, Pod Security Admission and admission controllers. A managed control plane removes API server and etcd work, not add-on work or node upgrades.
How managed container services works
A managed container service takes an image and a service definition. You choose CPU and memory, concurrency or request limits, minimum and maximum instances, environment variables, secret references and ingress rules. The provider creates compute, load balancing, TLS and scaling. Cloud Run, Azure Container Apps, AWS App Runner and Fargate with ECS are examples. Names differ, the contract is similar.
Control is narrower by design. You usually get no nodes, no DaemonSets, no custom schedulers and no privileged containers. Networking follows the provider model for private ranges, egress and custom domains. Storage is limited, and stateful workloads often need a separate database service. Debugging moves from node access to logs, metrics and revision history.
Scaling may follow request concurrency, CPU or queue depth. Some services scale to zero, which cuts idle cost but adds cold starts. You manage image size, startup time, health endpoints and graceful shutdown. Revisions and traffic splitting help releases, but you still need a rollback plan.
When to choose Kubernetes
Choose Kubernetes when the hard part is the platform, not the container. That means many services, several teams, shared ingress, common policy, namespace isolation and RBAC that matches your org. The API pays off when you can build a paved road other teams use without learning every add-on.
Choose it for workloads that managed container services fit poorly. DaemonSets for node agents, custom controllers, CRDs, GPU scheduling with taints and tolerations, batch Jobs at scale, or StatefulSets with careful storage. Hybrid or on-premises requirements also push toward Kubernetes because the API is the same in each place.
Portability is real but partial. The same Deployment can run on several clouds. Ingress classes, storage classes, IAM and network policy still differ. Treat portability as a design goal that needs testing. Do not choose Kubernetes without an owner for upgrades, certificates, add-ons and CNI issues.
When to choose managed container services
Choose a managed container service when the application is the hard part and the platform should stay boring. A small team with a few HTTP APIs, background workers or event handlers can ship without hiring a platform engineer. The provider handles host patching, load balancers and most scaling.
It fits spiky traffic and internal tools. Scale to zero helps idle services. Per request or per second billing can match usage better than a cluster of idle nodes, but watch cold starts, minimum instances and egress. Set concurrency and max instances so one bad release cannot overload a database.
It also fits teams that want a smaller patch surface. The provider patches the host and runtime, while you focus on image provenance, dependency updates, secret handling and IAM. Check private networking, audit logs, region choices and encryption key options. Avoid it when you need privileged access, custom kernel settings, special protocols or custom scheduling.
Costs and effort to consider
Compare the full bill, not the compute line. Kubernetes brings node compute, control plane fees on managed offerings, load balancers, NAT gateways, storage, logging and cross zone traffic. Managed container services bring request or compute time, minimum instances, egress and logging. Idle capacity and log volume often decide the real cost.
People cost matters more. Kubernetes needs upgrades every few months, add-on releases, certificate rotation and debugging across several layers. A managed service still needs image hygiene, health checks, secret rotation and release discipline. The difference is where the work sits, not whether work exists.
Watch cluster sprawl and service sprawl. Many small clusters or services duplicate ingress, monitoring and policy. Set a default: one shared cluster with namespaces, or one service per bounded context. Write down who approves exceptions. If the gap is the release process, fix that first. Cloudverg's Delivery platform setup at $14,500 fixed price is one option among others: four weeks to set up pipelines, environments, secrets, monitoring and rollback for the services in scope.
Frequently asked questions
Is managed Kubernetes the same as a managed container service?
No. Managed Kubernetes such as EKS, GKE or AKS runs the control plane for you but still exposes the Kubernetes API and usually leaves worker nodes and add-ons to you. A managed container service hides the cluster and nodes and gives you a narrower deploy contract. Choose based on how much control you need versus how much platform work you can staff.
Can I move from a managed container service to Kubernetes later?
Usually yes, if you keep a plain container image and move configuration into environment variables and secret references. Plan for differences in ingress, storage, IAM and scaling. Test one small service first and document the provider features you rely on.
Do I need Kubernetes to run containers in production?
No. Many production workloads run on ECS, Cloud Run, Container Apps or App Runner. Kubernetes earns its keep with shared platforms, custom scheduling, policy and portability across environments. For a few services, it can add work without a matching payoff.