I've used Minikube for testing changes, but I'm trying to understand how it compares with tools such as kind and k3s. What are the practical differences between these local Kubernetes options, and when would you choose one over another?
I'm also curious about current industry practice. My company mainly uses managed services such as AKS and EKS, along with higher-level platforms built around Kubernetes. Do companies still create and operate clusters entirely from scratch, or has managed Kubernetes become the normal choice? If you have built and maintained a cluster yourself, I'd appreciate an overview of the architecture, operational challenges, and useful learning resources.
4 Answers
Local clusters are especially useful while scaffolding an application or figuring out how several components fit together. The biggest difference from a managed cloud cluster is usually the surrounding cloud integration. In production you may need cloud load balancers, DNS automation, identity integration, storage classes, and provider-specific permissions. A local k3s or kind setup can validate Kubernetes manifests and application behavior, but it will not faithfully reproduce those integrations.
For performance benchmarking, use an environment that resembles production as closely as possible. Local testing is useful for functional and integration checks, but it should not be treated as a reliable substitute for production-scale performance testing.
For production, managed Kubernetes is usually the sensible default unless you have a strong reason to operate the control plane yourself. Self-hosting means taking responsibility for etcd, backups, high availability, upgrades, security, and recovering from control-plane failures. That can be valuable experience, but it is a substantial operational burden.
Building a cluster yourself once is still worthwhile because it makes it much clearer what services such as AKS, EKS, and GKE are managing for you.
I’m currently moving from EKS to self-managed RKE2 on bare-metal systems because of a major infrastructure cost decision. The hardware is much cheaper, but the operational workload is dramatically higher, especially when there are few people left who understand the automation and infrastructure tooling.
Self-managed clusters still exist in on-premises environments, government systems, bare-metal deployments, and organizations with unusual networking, compliance, or cost requirements. Some teams also use distributions such as RKE2 with their own virtual machines. However, many companies choose managed Kubernetes because it removes a large amount of undifferentiated operational work.
The control plane fee is often not the main cost concern. Non-production node pools and other resources left running continuously can cost more than the managed control plane itself. Tools such as kind are free and useful for testing the Kubernetes API, but they cannot reproduce provider features such as cloud load balancers, managed identity, or external DNS.
We use managed Kubernetes in the cloud and RKE2 on premises. RKE2 gives the engineering team more control, but it also means accepting responsibility for more of the platform. I would choose self-management only when that flexibility or the deployment environment genuinely requires it.
The local tools have different goals. kind runs Kubernetes nodes inside containers, so clusters start and disappear quickly. It is excellent for CI, integration tests, and disposable multi-node environments. Minikube is more focused on a convenient local development cluster and commonly uses a virtual machine or container runtime, so it is generally heavier but can feel more like a small standalone installation. k3s is a lightweight Kubernetes distribution rather than just a temporary test wrapper; it can be used for long-running labs, edge systems, or smaller production deployments.
That helps clarify the distinction. I’m going to experiment with kind for lower-environment testing and compare what it can reproduce locally.
That makes sense. The application can behave correctly locally while the cloud load balancer, DNS, identity, or storage layer behaves very differently after deployment.