Generating support bundle with Helm CLI installs

How do I?
,
1

We’re porting our existing Replicated app to Helm native, and in particular Helm CLI, and would like to provide the same support bundles as we do on Replicated KOTS.
How can support bundles be generated when installed with Helm CLI?

1 Like
2

Hi,

One of the things that KOTS does when it installs the app, is take the support bundle you’ve put together and installs it as a secret in the cluster.

This secret can be found by support-bundle from the CLI like this:

kubectl support-bundle --load-cluster-specs

Note also, that you can supply multiple specs.

To match current KOTS behavior, you’d include secrets in the Helm installation templates that have the content of the support-bundle you’d normally use, plus the defaults from KOTS (found here). The secret (or configMap) needs to have a label for Troubleshoot to find it: troubleshoot.io/kind=support-bundle.

The secrets would be in the format:

apiVersion: v1
data:
  support-bundle-spec: (base64 encoded support-bundle spec)
kind: Secret
metadata:
  labels:
    troubleshoot.sh/kind: support-bundle
  name: someapp-supportbundle
  namespace: default
type: Opaque

I should point out that you don’t need to put the spec into a secret - you can supply a local file, a url, or an oci reference to the Replicated registry. Take a look at kubectl support-bundle --help and you’ll see the CLI options.

1 Like
3

Thanks, it works great!
Out of curiosity, is there any reason why it needs to be put in a secret, instead of just putting it in the namespace as a SupportBundle object?

6

Hi, we don’t usually install the CRDs for the SupportBundle objects, which is why we can’t install them.

There’s an option to use ConfigMap too but I prefer them to be secrets because there’s potentially private info (e.g. database connection strings).

1 Like