My usual recommendation is to have highly granular namespaces. One pattern I've seen is that every unique instance of an app has a separate namespace. This allows you to isolate concerns.
For example, an API, Database, worker queue, and monitoring for a single app all live in an isolated namespace. This means that if you need to shutdown the app, you know exactly what systems are affected. On Feb 7, 2018 12:31 AM, "Kamil Korzekwa" <kam...@gmail.com> wrote: > Hey everyone, > > I am wondering what are the best practices for organising/managing > namespaces within SaaS product across multiple teams. Each team has full > ownership of their services and works according to "you build it you run > it" principle. > > Example approaches: > a) All teams share product namespace. > b) Namespace per team. > c) Each team would have separate namespace for each functional domain that > they work on (e.g. Streaming, Configuration, FancyPersistence, Analytics > etc.). > d) Each product functional domain would have a separate namespace (some > domains are cross-team, so sometimes namespace could be shared by multiple > teams). > > In a), team Foo does not have to specify namespace when calling team Bar > service. Makes it easier to manage configuration and to move service from > one team to another. > In b) namespaces are used to prevent name collisions between teams > internal services and to have quota management and access control per team. > The downside is that team Foo must specify namespace when calling team Bar > service (unless externalName or dns alias is used). > c) and d) sound interesting, they allow more fine-grained access control > and in theory it is easier to move functional domain to another team > (change role binding and roll secrets). However, it feels like an abuse of > namespaces and logical grouping like this may/will have to change over > time. It is also harder for team to manage many namespaces than single > namespace. > > Useful resources: > http://blog.kubernetes.io/2016/08/kubernetes-namespaces- > use-cases-insights.html > https://www.youtube.com/watch?v=18P7cFc6nTU > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
