[Feature Request] Can we include "kubectl get all" and "kubectl get all -o wide" in ECK diagnostics?

[kunisen]

For troubleshooting purpose, having the output of the following 2 commands are more intuitive than current viewing pods.json/deployments.json/etc and do some formatting.

• kubectl get all
• kubectl get all -o wide

(It's very similar to have _cat/nodes and nodes.json at the same time which is what we have for Elasticsearch diagnostics)

Would also like to have -o wide is because it can show which object is on which k8s node, which could be helpful for particular troubleshooting case.

[sebgl]

@kunisen to make sure I get the feature request right: the goal here is not to get information about more k8s resources (get all returns things we may not care about), but rather to provide a "summary" of the resources we care about in a format that is easier to digest than the full JSON arrays in multiple files?

[kunisen]

Thanks! @sebgl
Indeed, it's rather to provide a "summary" + "list" for quick reference.
A good example is recently we hit an issue that readiness probe made some pods become 0/1 ready.
It's really hard to view from json file but if we can have kubectl get pods then we can view the 0/1 or 1/1 very quickly.

This similarly expands to all resources so I raised the request for get all.

Hope that's clear!

[thbkrkr]

We are quite reluctant to make this enhancement because:

• Users have already complained about the size of the diagnosis and it adds files when the data is already present in the diagnosis even if it's small files.
• Apply the filters to the get commands seems a bit hacky.

Wouldn't it be better to put our efforts into a diagnostic visualization tool?

[kunisen]

@VimCommando Per comment above, maybe it's a good topic for how to make our internal visualization tool easier to use. :)

[VimCommando]

I am all for getting visualizations going on our data. We just need ECK diags to be supported first:

https://github.com/elastic/<internal support ops related repository>/issues/476