Skip to content

Support Bundles

A support bundle is a snapshot of your Pixee Enterprise Server cluster (logs, configuration, manifests, and diagnostics) that Pixee Support uses to investigate issues.

Bundles uploaded through any of the paths below are delivered to Pixee Support automatically — you do not need to send the file yourself.

Which path to use

Three entry points coexist. Each produces a bundle that lands in the same place; the differences are who can reach them and how much log content the bundle carries.

Path Carries VictoriaLogs? Reachable by Best for
Pixee Platform UI (preferred) Yes Any authenticated Pixee Platform user Most cases. The extended bundle is what Pixee Support usually needs to investigate non-trivial issues.
kotsadm Admin Console No kotsadm administrators only Cases where Pixee Support has explicitly asked for the standard (non-extended) bundle, or where the in-product flow has been disabled.
Cluster shell fallback Yes Anyone with VM sudo or a kubeconfig Fallback when neither of the other two paths is available — for example, when the Pixee Platform itself is down (so the in-product flow can't run) and the kotsadm Admin Console is unreachable or unusable.

If you are uncertain which to pick, ask Pixee Support which bundle they want.

Generate from the Pixee Platform UI

  1. Sign in to the Pixee Platform.
  2. Click your avatar in the top-right of the navigation bar.
  3. Choose Generate Support Bundle.

A toast confirms the bundle has started. The bundle is generated in the cluster and uploaded to Pixee automatically. You can close the page; the upload continues in the background. Subsequent toasts report progress as the bundle moves through running and into a terminal state (succeeded or failed).

While your bundle is in flight, the menu item label switches to Generating support bundle… and is disabled in your browser. It re-enables when the bundle reaches a terminal state. Only one bundle can be in flight at a time across the cluster — if another user has a bundle running, you'll see a warning toast identifying them and your request will not run until theirs finishes.

This is the recommended path because it requires no shell access and produces the extended bundle (with Victoria logs) that Pixee Support typically needs.

Generate from the kotsadm Admin Console

The kotsadm Admin Console retains its Generate a Support Bundle and Send bundle to vendor controls. These produce the standard bundle, which does not include the Victoria logs export, and upload it through kotsadm's own pipeline.

  1. Open the kotsadm Admin Console (https://<host>:30000).
  2. Click Troubleshoot in the navigation bar.
  3. Click Generate a Support Bundle.
  4. Once generation completes, click Send bundle to vendor.

Use this path when Pixee Support has explicitly asked for the standard bundle, or when the in-product flow has been disabled on this installation. For routine investigation, prefer the Pixee Platform UI path — the extended bundle it produces carries the log content Pixee Support relies on.

Generate from the cluster shell

Use this path when the Pixee Platform UI is unavailable — for example, when a deployment fails and leaves the platform itself unreachable. Two commands produce the bundle and upload it to the in-cluster Replicated SDK Service, which forwards it to Pixee.

The kubectl support-bundle CLI also auto-uploads the bundle on its own, but that goes to a Replicated analysis endpoint, not to Pixee — the explicit POST in step 2 is what makes it reach Pixee Support.

Prerequisites

On the Pixee Enterprise Server VM, drop into the cluster shell — kubectl and the support-bundle plugin are already on the PATH:

sudo ./pixee shell

From any machine with a kubeconfig pointing at the cluster, install the support-bundle kubectl plugin:

curl https://krew.sh/support-bundle | bash

Generate and upload

The upload runs inside a one-shot pod using the pixee-utility-alpine image.

Reference both spec secrets explicitly rather than using --load-cluster-specs. Auto-discovery only finds the standard spec (labeled troubleshoot.sh/kind=support-bundle); the extended spec is deliberately labeled troubleshoot.pixee.ai/kind=support-bundle-extended so it is not auto-discovered, so --load-cluster-specs alone would produce a thin bundle with no VictoriaLogs export. This matches what the in-cluster Job runs.

kubectl support-bundle -o bundle.tar.gz \
  secret/kotsadm/pixee-enterprise-server-support-bundle \
  secret/kotsadm/pixee-enterprise-server-support-bundle-extended

kubectl run -n kotsadm sb-upload --rm -i --restart=Never \
  --image=images.pixee.ai/proxy/pixee/218200003247.dkr.ecr.us-east-1.amazonaws.com/pixee/pixee-utility-alpine:1.0.20274709409 \
  --command -- sh -c 'cat > /tmp/b.tgz && curl -fsS -X POST \
    -T /tmp/b.tgz \
    -H "Content-Type: application/gzip" \
    http://replicated.kotsadm.svc:3000/api/v1/supportbundle' < bundle.tar.gz

Disabling the in-product flow

The in-product flow runs as a small in-cluster Service backed by a Kubernetes ServiceAccount with cluster-wide read access plus pods/exec and pods/log. The runner ServiceAccount needs that scope so the bundle's collectors can discover and inspect cluster state across namespaces — without it, the bundle would not be useful for diagnosing distributed issues.

To disable the in-product flow entirely:

  1. Open the kotsadm Admin Console (https://<host>:30000).
  2. Click Config.
  3. Find In-product support bundle generation and clear the checkbox.
  4. Click Save config and deploy the new version.

When disabled:

  • The chart renders no Deployment, Service, ConfigMaps, ServiceAccounts, or cluster-scoped RBAC for the support-bundle service.
  • The Generate Support Bundle menu item in the Pixee Platform UI is hidden.
  • The kotsadm Admin Console's Generate a Support Bundle and Send bundle to vendor controls remain available.

Trade-off

Disabling the in-product flow means Pixee Support cannot receive the extended (Victoria-logs-bearing) bundle through the platform UI. The two remaining paths are:

  • The kotsadm Admin Console — produces the standard bundle (no Victoria logs).
  • The cluster shell fallback — produces the extended bundle but requires VM sudo or a kubeconfig.

For most non-trivial investigations Pixee Support needs the extended bundle, so disabling the in-product flow typically means support engineers will ask you to run the cluster-shell path. Bundles delivered that way reach Pixee Support the same way; the difference is operator effort, not destination.

Edge cases

Thin bundle when VictoriaLogs is disabled

If VictoriaLogs is not enabled on this installation, the Generate Support Bundle menu item stays visible and bundles still generate — but the bundle's log collector finds no VictoriaLogs endpoint and the resulting bundle carries no log content. Pixee Support will see a "thin" bundle.

In that state, the kotsadm Send bundle to vendor button produces an equivalent (also-log-free) standard bundle through a different upload pipeline and is the appropriate path.

Bundle retention

Bundles uploaded through any path are retained by Pixee for Support to access. The cluster-side bundle Job (and its pod) are kept for 3 days after completion before Kubernetes auto-deletes them, which is enough time to inspect a failed run via kubectl logs <bundle-runner-pod>.

If none of the paths above produces a bundle, contact Pixee for further support.