Allow scoping by namespace at runtime

[programmerq]

Describe the rationale for the suggested feature.

Sometimes there can be multiple instances of the same application installed. It is common to split these instances by namespace. Since the end-user can install a helm chart into any namespace they want, troubleshoot should support looking in a given namespace as specified at runtime.

Describe the feature

Currently, the kubernetes namespace must be hardcoded into the support-bundle yaml definition. This should be optional.

If the support bundle definition does not include a namespace, the operation should be restricted to the current namespace as specified by the -n <namespace> argument or the current kubeconfig context's namespace.

Describe alternatives you've considered

The current path forward is to use a templating engine to render a support dump yaml definition that has the correct hardcoded namespace embedded in it. This adds additional workload on the end-user who wants a quick, easy, reliable process that will produce a support bundle to share with support.

Additional context

I'm building a support bundle definition for a project that is commonly deployed via a few different methods-- helm charts, sometimes manual kubernetes yaml, etc. Each instance of this project could live in a kubernetes namespace with any name at all.

[chris-sanders]

While I'm aware this is an old request, I think some discussions we've been having recently might help address this as well. If support bundles become a CRD and they are installed in a cluster the namespace field could be omitted to allow the bundle to operate on the namespace that it is installed. I think by making support bundles an object in the cluster we'll find we can address this use case.

My only concern with a namespace scope at runtime would be how it scales to multiple collectors. If you for example want to collect pods and logs from multiple namespaces you're left splitting up your bundle and making multiple runs to get it all done. Hopefully with something that can be installed in the cluster you could accomplish this with one go. I suspect you would still want a way to restrict which CRD's to process but you could process all of them in the cluster with a single command even across different namespaces which would be a nice benefit.

[xavpaice]

There's been some discussion around whether it's better to use the --namespace flag to restrict to a namespace, and default to all namespaces if not specified, or if Troubleshoot should use the same defaults as kubectl (i.e. require -A for all namespaces, or -n for any that's not the current context).

Knowing that a lot has changed since you raised this issue, can you confirm if the -n flag currently provided is what you're looking for, or how you'd prefer to see the tool behave?