maybe use kubectl api-resources to collect all (needed) config can work for this?

kubectl api-resources --verbs=list -n tidb-cluster -o name | grep -Ei "tidbclusters.pingcap.com|pods" | xargs -n 1 kubectl get -n tidb-cluster -o yaml

maybe use kubectl api-resources to collect all (needed) config can work for this?

kubectl api-resources --verbs=list -n tidb-cluster -o name | grep -Ei "tidbclusters.pingcap.com|pods" | xargs -n 1 kubectl get -n tidb-cluster -o yaml

Hey @yiduoyunQ, thanks for your insights! I think the command you shared can cover most cases, and we can easily collect more resources by adding resource names in grep or by changing the namespace. I think my main concern is sometimes the customers we're dealing with don't have sufficient expertise for either k8s or tidb-operator, and they need our involvement in collecting the data we need in their own environments before we can start the investigation. This takes quite some time, especially for customers in a different time zone. Another concern is, the command could collect more information than we need. For instance, sometimes we want to collect the information for tidb clusters (together with its pods, asts) with certain labels in ns1, ns2 but not ns3, then we need to craft a new command and run it for ns1 and ns2 respectively (with label selectors). If people just replace -n tidb-cluster with -A (to collect resources in all namespaces), or they forgot the label selector, then it could easily lead to data exfiltration.

I think we need to document the steps for collecting related data in our public documentation so our support engineers can point it to our customers without back and forth. As for how to collect the information, I'm inclined to craft a user-friendly tool for info collection. But before that is available/mature, we can share the command you mentioned above with our customer on our website. How about that?