Skip to main content

Collecting a Support Bundle

Collect a support bundle​

Now that we have the kubectl plugin installed, let's collect a support bundle.

A support bundle needs to know what to collect and optionally, what to analyze. This is defined in a YAML file. Open your favorite editor and paste the following content in:

apiVersion: troubleshoot.sh/v1beta2
kind: SupportBundle
metadata:
  name: supportbundle-tutorial
spec:
  collectors: []
  analyzers: []

Save the file as support-bundle.yaml and then execute it with:

kubectl support-bundle ./support-bundle.yaml

The support bundle plugin will work for a few seconds and then show you the filename that it created.

Note: This does not deploy anything to the cluster, it's all client-side code.

In my case, the file created was named support-bundle.tar.gz.

You can tar xzvf the file and open it in your editor to look at the contents.

Collect a support bundle using multiple specs​

Introduced in Troubleshoot v0.42.0

You may need to collect a support bundle using the collectors and analyzers specified in multiple different specs. As of Troubleshoot v0.42.0, you can now pass multiple specs as arguments to the support-bundle CLI.

Create a support bundle using multiple specs from the filesystem

kubectl support-bundle ./support-bundle-spec-1.yaml ./support-bundle-spec-2.yaml

Create a support bundle using a spec from a URL, a file, and from a Kubernetes secret

kubectl support-bundle https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/in-cluster/default.yaml \
./support-bundle-spec-1.yaml \
secret/path/to/my/spec

Collect a support bundle using specs discovered from the cluster​

Introduced in Troubleshoot v0.47.0

You can also use the --load-cluster-specs flag with the support-bundle CLI to collect a Support Bundle by automatically discovering Support Bundle and Redactor specs in Secrets and ConfigMaps in the cluster. For more information, see Discover Cluster Specs.

Notes on using multiple specs with runHostCollectorsInPod flag​

  • If one spec has runHostCollectorsInPod: true and another does not, the merged spec sets runHostCollectorsInPod: true and includes all host collectors from both specs.
  • When using a spec with a URI pointing to a spec hosted elsewhere, if the target URI spec does not have the runHostCollectorsInPod setting, the merged output reflects the default setting of false regardless of the original spec's setting.