Teams & Namespaces
It is common for one team to be responsible for multiple applications. Especially when you get into a shared responsibility approach where each team is responsible for building and running their own applications (devops), but mature applications are also supported by a dedicated operations team (SRE) that supports multiple applications from multiple teams. By having one namespace per application environment you can clearly distinguish which resources belong together.
So to name your namespaces, use the application name as the first part and the environment as the second like this:
Tipp: Always use dash
-instaed of underscore
_for Kubernetes resource names.
Applications and environments
To be able to organize applications and environments into namespaces lets define what we mean by application and environment.
- An application, for the sake of this guide, is a group of Kubernetes resources, that serve a common purpose.
- An environment, is an instance of an application in a specific livecycle stage like development, staging or production.
As a reality check if something should be in the same namespace, ask yourself, would it make life easier debugging this app at 3 in the morning? If the answer to that from the perspective of the team that builds and runs the app is yes, put the resources into the same namespace.
So, to give an example, a team running and building one or more apps, has one namespace, per app, per environment. Assuming team1 is responsible for app1 and app2 and team2 is responsible for app3, app4 and app5 and you have three envrionments, development, staging and production you would end up with a structure like below: