Open ncdc opened 4 years ago
With my hacky changes from above (and limiting to just the default namespace to cut down on noise):
DEBU[0000] creating working directory /tmp/crashd
DEBU[0000] kube_capture(what=objects)
DEBU[0000] Search filters groups:[]; kinds:[clusters]; namespaces:[default]; versions:[]; names:[]; labels:[] containers:[]
DEBU[0000] Searching for clusters in namespace default [GroupRes: cluster.x-k8s.io/v1alpha3, Resource=clusters]
DEBU[0000] Found 1 clusters in namespace [default]
DEBU[0000] kube_capture(): saving clusters search results to: /tmp/crashd/kubecapture/default/clusters.json
@ncdc thanks for the superb detailed issue.
Just chiming in to note taht @gwang550 and I just ran into this problem when exploring how to provide guidance on how to troubleshoot issues bootstrapping a management cluster due to connectivity issues to the infrastructure APIs.
In some scenarios, we were looking at the vspherecluster
objects on the cluster and seeing these conditions:
"status": {
"conditions": [
{
"lastTransitionTime": "2021-07-06T20:12:44Z",
"status": "True",
"type": "Ready"
},
{
"lastTransitionTime": "2021-07-06T20:12:44Z",
"status": "True",
"type": "LoadBalancerAvailable"
},
{
"lastTransitionTime": "2021-07-06T20:12:44Z",
"message": "Secret \"tkg-mgmt-vc\" not found",
"reason": "VCenterUnreachable",
"severity": "Error",
"status": "False",
"type": "VCenterAvailable"
}
],
"ready": true
}
But when we grabbed the resource with crashd
, we saw this instead:
"status": {
"apiEndpoints": [
{
"host": "2620:124:6020:c00a:0:a:cccc:eebb",
"port": 6443
}
],
"ready": true
}
We were confused about why the crashd output was missing the conditions, but in looking at the output more closely, we saw that the apiVersion of the resource was older (v1alpha2 instead of v1alpha3).
@mcwumbly will move this higher in priority. Thanks for pointing this out.
I @mcwumbly #207 implemented some changes that should fix your issue.
For the following script
With the following cluster:
Run this:
Look at clusters.json:
Note that it's the v1alpha2 API version. It appears that crashd is finding both the v1alpha2 and v1alpha3 API versions of my Cluster, processing them both, and writing the results to the same file, with the last one in winning:
If you use a RESTMapper and assume that when capturing objects, you always concatenate groups and kinds (which should really be resources) together, you can do something like this to get the server preferred version without having to loop through discovery data: