by Daniel Thiry
Kubernetes has left the state when it was mostly an ops technology behind and now is also very relevant for many developers. As I wrote in my blog post about the Kubernetes workflow, the first step for every developer who starts to directly work with Kubernetes is to set up/get access to a Kubernetes development environment.
A Kubernetes work environment is not only the first step but also a basic requirement to be able to work with Kubernetes at all. Still, access to such an environment is often a problem: A VMware study even found out that “access to infrastructure is the biggest impediment to developer productivity”. For this, Kubernetes development environments should have a high priority for every team that plans to use the technology.
In this article, I will describe and compare four different Kubernetes development environments and explain when to use which dev environment.
- Local Kubernetes Clusters
- Individual Cloud-Based Clusters
- Self-Service Namespaces
- Self-Service Virtual Clusters
6 Evaluation Criteria For Dev Environments
To make the different Kubernetes dev environments comparable, it makes sense to…