Environment Size and Scope

[tskinn]

I find myself putting not only more than one application in an environment but an entire (small) k8s clusters worth of resources in a tanka environment. I just read that it is not recommended to put resources from multiple namespaces in one environment. So is the rule of thumb that environments map roughly to namespaces? Am I heading towards disaster? Do we know how many resources tanka can handle in one environment before it becomes tediously slow? I just like the idea of, similar to terraform, running one command and having an entire dev environment in sync but also being able to target specific resources when necessary.

[malcolmholmes]

FWIW: We achieve the same effect with Flux: we commit a change to git, then CI converts those to YAML (with code wrapped around tk export), and then commits that code to a second repo. Then we have Flux listening on that repo and mirror changes into k8s.

In this way, it is allowing us to reason at a higher level than a single Tanka environment without having to have many calls to tk apply.

[tskinn]

@Duologic did you have any advice on this topic? it sounded like you might from your comment in #569

[Duologic]

@malcolmholmes summarized it nicely already.

[dsabsay]

I know this is an old thread, but I've had similar questions myself.

I can't speak to how it works on really large clusters. But I started a project that now has 3 separate small environments and in general I regret it. Like you mentioned, one of the main selling points to me is that my entire cluster state is calculated and diff'd with one command. Having even a just a few environments means I have to check each one when I'm e.g. trying to validate that all the changes I want have been merged into a particular branch. Admittedly, the actual problem could be that I'm running these commands manually at all, but that's just my perspective. I'm considering collapsing the environments into one at some point.