Hey Kubernetes practitioners, one of the questions that keeps coming up is how large teams are using Kubernetes? Do you use namespace as a ownership boundary in your teams? Do you share Kubernetes cluster among your team by configuring hierarchical ownership policies? Can you share your experience?
Why this question?
The Litmus team is considering chaos at namespace level. You will be able to run the complete chaos infrastructure within the namespace.
Here is the description of a possible scenario:
Kubernetes cluster is setup on one of the cloud service providers like EKS, GKE, AKS or DOKS where the management of the cluster is not managed by the team. Then your team has a set of SREs or admins who have cluster wide access through service accounts to help manage the administration of applications and the cluster itself. When a developer wants the Kubernetes environment, a new namespace is created with service account settings with access to that developer. The developer has enough levers within the namespace and gets the Kubernetes environment that is required for development needs.
Are there any scenarios in which you felt there are limitations? Is this a common practice? Or developers are better off with their own small clusters?
Top comments (4)
To be honest, it depends. For small teams maybe you group by cluster, bigger teams in a microservice architecture maybe group by namespace.
In the last few projects I was part in, I noticed that it mostly goes the way of "namespace per team" until the restrictions and waiting times are so annoying that teams get their own clusters.
Locking down teams to their own namespace goes right until they want to deploy infrastructure things like s3 storages, databases and other things of the like themselves. Then it doesn't work as great anymore and ops teams as an external dependency slow things down too much.
Very valid reasons Raphael! Do you think we could add
freedom to inject infra-level chaos(disk, node, network - typical experiments with blast radius enough to "impact" other dev groups on different namespaces) to that list, considering chaos is increasingly appearing in a dev's checklist today as much it continues to be an SRE pursuit?I am inclined to agree. For small teams it probably has no instantly apparent value as compared to having/building more features.
I haven't seen much chaos engineering done as of yet, but I do think it can be a vital component in SRE and training.
Thank you Raphael. It appears that teams or individuals manage themselves within a namespace while they are small or during early dev stages.. mostly stateless applications.