Kubernetes and Cloud Native: How the Pieces Fit

Updated 6 November 2026 · Standard formula, shown below

Kubernetes and cloud native technologies work together as a layered platform: Kubernetes orchestrates containerized applications, while surrounding tools handle networking, storage, observability, and delivery. You still operate the application itself, its data, and the parts of the infrastructure that sit above the cloud provider’s managed services.

Background: From VMs to Containers to Orchestration

Before cloud native, applications ran on virtual machines (VMs) with a fixed operating system, fixed IP address, and manual scaling. Containers changed that by packaging an application with its own dependencies into a single image that runs anywhere. But running hundreds of containers by hand is unmanageable. Kubernetes, originally developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF), emerged as the standard orchestration layer. It automates deployment, scaling, and failover of containers across a cluster of machines.

Cloud native is broader than Kubernetes. It includes microservices, declarative APIs, immutable infrastructure, and continuous delivery. The CNCF hosts projects like Prometheus for monitoring, Envoy for networking, and Helm for package management, all designed to work with Kubernetes but not all required for every setup.

How the Pieces Fit Together

A typical cloud native stack has several layers, each with a specific job. Understanding the boundaries helps you know what you operate and what you don’t.

Container runtime – The software that actually runs containers (e.g., containerd, CRI-O). Kubernetes talks to it through the Container Runtime Interface.
Kubernetes control plane – The API server, scheduler, and controller managers that decide where workloads run and keep the desired state. In managed services (EKS, AKS, GKE), the cloud provider operates this.
Worker nodes – The machines (virtual or physical) that run your containers. You manage the OS, the kubelet, and the container runtime, unless you use a serverless offering like AWS Fargate.
Networking – Services, Ingress controllers, and service meshes (like Istio) route traffic between containers and to the outside. You define the rules; the plugin implements them.
Storage – Persistent volumes (PVs) and persistent volume claims (PVCs) abstract storage. You choose the storage class (cloud disk, NFS, etc.) and manage backups.
Observability – Metrics (Prometheus), logs (Loki or ELK), and traces (Jaeger) tell you what’s happening. You deploy and configure these tools.
Delivery – CI/CD pipelines build images, scan them, and deploy via GitOps tools like Argo CD or Flux.

In a managed Kubernetes service, the cloud provider handles the control plane, upgrades, and often the node health. You still operate the workloads, the networking rules, the storage, and the observability stack.

What You Still Operate

Even with managed Kubernetes, you are not off the hook. The division of labor is often misunderstood. Here’s what remains your responsibility:

Application code and configuration – You write the Dockerfile, set resource requests/limits, and manage ConfigMaps and Secrets.
Deployments and releases – You define YAML manifests, Helm charts, and rollout strategies (blue-green, canary).
Data and databases – Whether you run PostgreSQL in a pod or use a cloud database, you manage schema, backups, and access.
Security – You set RBAC roles, network policies, pod security standards, and image scanning.
Cost optimization – You choose instance types, autoscaling settings, and resource requests to avoid overprovisioning.
Disaster recovery – You back up etcd (if you run your own control plane) and your application data, and test restores.

If you run Kubernetes yourself (on bare metal or VMs), you also operate the control plane, etcd, and node lifecycle. That’s a significant operational burden that managed services remove.

Choosing Between Managed and Self-Managed

The choice depends on your team, workload, and compliance needs. Here are the main factors:

Team expertise – If you have no dedicated Kubernetes admin, a managed service is safer. Self-managed requires deep knowledge of etcd, networking, and upgrades.
Compliance and data residency – Some regulations require you to control the control plane or keep data on-premises. Self-managed gives that control.
Workload predictability – If you have steady, predictable traffic, managed nodes with autoscaling work well. If you have spiky, short-lived batch jobs, consider serverless (e.g., Virtual Kubelet).
Cost – Managed control plane is free on most clouds (you pay for nodes), but you pay a premium for features like Fargate. Self-managed on your own hardware can be cheaper at scale but requires more people.

A common middle ground is using managed Kubernetes (EKS, AKS, GKE) with managed node groups and a managed database. This reduces operational load while keeping flexibility.

Common Problems and Misconceptions

One misconception is that Kubernetes makes applications “cloud native� automatically. It doesn’t. If your app is a monolithic stateful process that doesn’t handle graceful shutdown or horizontal scaling, Kubernetes will still run it, but you won’t get the benefits. You must design for 12-factor principles.

Another issue is networking complexity. Kubernetes has several network models (e.g., CNI plugins like Calico, Cilium). Misconfiguring NetworkPolicies can cause silent connectivity issues. Similarly, service meshes add a lot of moving parts; many teams adopt them too early and struggle with debugging.

Storage is another pain point. Persistent volumes in Kubernetes are not like local disks. They have access modes (ReadWriteOnce, ReadWriteMany) that limit how many pods can mount them. If you run a database in Kubernetes, you need to handle backups and failover yourself, which is non-trivial.

Alternatives to Full Kubernetes

Not every workload needs Kubernetes. For simple web apps, a platform like Heroku or a cloud’s PaaS (e.g., AWS Elastic Beanstalk) might be enough. For event-driven functions, serverless platforms (AWS Lambda, Google Cloud Functions) are simpler. For containers without orchestration, Docker Compose works for single-host setups.

Kubernetes makes sense when you need portability across clouds, complex scaling rules, or a standard platform for many teams. If you have one small app, the operational overhead may outweigh the benefits.

Costs and Skills

Kubernetes can reduce infrastructure costs through efficient bin-packing, but it adds hidden costs: training, tooling, and the time spent on YAML and debugging. Managed services reduce control plane costs but you pay for nodes, storage, and egress. Monitoring tools (Prometheus, Grafana) also consume resources. The biggest cost is often the team’s time. A skilled Kubernetes engineer is expensive and hard to hire. Start small and automate aggressively.

Frequently Asked Questions

Do I need Kubernetes if I only have a few services?

Probably not. If you have fewer than five services and no scaling needs, a simple VM or a PaaS is easier and cheaper. Kubernetes adds value when you need multiple teams, complex networking, or autoscaling.

What does “cloud native� actually mean?

It means designing applications to run in the cloud, using microservices, containers, declarative APIs, and continuous delivery. It’s about how you build and operate, not just where you run.

Is Kubernetes the same as Docker?

No. Docker is a container runtime and image format. Kubernetes orchestrates containers across multiple machines. Docker Swarm is an alternative orchestrator, but Kubernetes is the de facto standard.

Who is responsible for security in a managed Kubernetes cluster?

It’s shared. The cloud provider secures the control plane and the physical infrastructure. You are responsible for your workloads, RBAC, network policies, secrets, and image security.

Can I run stateful databases in Kubernetes?

Yes, using StatefulSets and persistent volumes, but it requires careful planning for backups, failover, and performance. Many teams prefer managed databases to avoid this complexity.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.