Allow skipping resources which are not accessible with current permission about kubectl-tree HOT 10 OPEN

Any news for this issue?
Without this feature it is sometimes impossible to use this tool.
The MR #15 seems like a good beginning...

from kubectl-tree.

Sure thing. You can probably redact PII like namespaces, object names, and maybe even API names etc.

The -v 5 logs have enough information to understand how much time is spent while querying an api group. That should be a good place to start.

I also suspect two other things: Something wrong with pagination logic (we can increase page size if it has a lot of objects) and client-side rate limit/burst (both set to 1000 qps right now).

from kubectl-tree.

In additional, there’s another kind of failure: When some API groups don’t respond with success (for reasons other than authorization).

We may lump these behaviors all into this one flag so that we don’t distinguish between failure modes.

Also we currently query all objects in all namespaces for child objects. In a secure env, a developer won’t have access to all namespaces.

So when we print warnings for inaccessible resources, would we print them per namespace (which can be hundreds of lines per mamespace), or would we just say “Some objects could not be queried and may be excluded from this result”. I am not certain.

from kubectl-tree.

Damn I did not read your comment and started working on a PR. Anyway it is a WIP @ahmetb

from kubectl-tree.

@princerachit I'm not as interested in code as I'm interested in designing the experience for now. :) Right now this is a design problem to me. It seems like many users will hit this, so I'm looking at solving it the cleanest way.

from kubectl-tree.

Sounds right @ahmetb . Another issue I can see is that it takes huge amount of time when running against an enterprise grade cluster

I0106 13:19:41.260134   50748 query.go:45] all goroutines have returned in 7m53.641176705s

from kubectl-tree.

@princerachit let's open a new issue, I'd love to see full logs and which API groups and how many namespaces etc are involved.

from kubectl-tree.

Maybe another design challenge is to include/exclude only a set of resources. As a user it does not make sense to iterate over non - useful resources like snapshots/monitoring/...

from kubectl-tree.

@ahmetb Let me talk to my employer. I am not sure if I am allowed to share the logs. But will open an issue.

from kubectl-tree.

Some objects could not be queried and may be excluded from this result”

What about the default behavior will just print this, and if you want more verbosity, you increase the loglevel, and then get a list of all objects that couldn't be fetched? I would love to use this tool within our company, and propagate it's use, but due to these restrictions it's currently not feasible.

(We, for example, don't have permission to list k8s secrets, because the list verb not only shows the metadata, but gives you actually permissions to view the content of it as well)

from kubectl-tree.