Kubernetes Support Bundle Examples

This repository contains public, vendor-neutral examples for collecting troubleshooting data from Kubernetes clusters with Troubleshoot.

Open Source Attribution

This project directly reuses the open source Troubleshoot tool from Replicated. Support bundle specs in this repository are authored for and executed by Troubleshoot's support-bundle collector.

What This Repo Contains

• Reusable support bundle specs under examples/
• Generic run instructions using kubectl support-bundle
• No provider-specific access tooling or internal cluster access workflows

Requirements

• kubectl configured for the target cluster context
• The Troubleshoot plugin:

kubectl krew install support-bundle

If Krew is not available, install the support-bundle binary directly from the Troubleshoot release artifacts.

Quick Start

Run a support bundle against your current kubeconfig context:

kubectl support-bundle ./examples/support-bundle-basic.yaml

Run with an explicit kubeconfig/context if needed:

KUBECONFIG=~/.kube/config kubectl --context my-cluster support-bundle ./examples/support-bundle-basic.yaml

Use the generated .tar.gz archive for support triage or load it with sbctl.

Public LKE Cluster Tips

The examples in this repo also work well for public LKE clusters. Tips LKE customers often find useful:

• Use a dedicated kubeconfig context per cluster so bundle commands are unambiguous.
• Prefer explicit context selection when collecting data:

kubectl --context lke-prod-us-east support-bundle ./examples/support-bundle-basic.yaml

• Run collection as close to incident time as possible so events and logs are still available.
• Start with support-bundle-basic.yaml, then re-run with support-bundle-full.yaml if deeper triage is needed.
• If networking is the symptom, collect support-bundle-cloud-native-networking.yaml in addition to the basic bundle.
• Capture the output filename and timestamp in your ticket so support can correlate it with alert timelines.
• Redact or review application logs before sharing if they may contain customer data.

For recurring issues, keep a known-good baseline bundle from a healthy period and compare it with incident bundles.

Example Specs

File	Description
examples/support-bundle-basic.yaml	Minimal cluster metadata and pod logs
examples/support-bundle-cloud-native-products.yaml	Compute/workload incident triage
examples/support-bundle-cloud-native-networking.yaml	Networking incident triage
examples/support-bundle-host.yaml	Host-level collection when API server is unreachable
examples/support-bundle-full.yaml	Broad collection for mixed compute/network incidents

When the API Server Is Down

Run host collectors directly on affected nodes:

sudo ./support-bundle --interactive=false \
  https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/host/default.yaml

For multi-node environments, run host collection on each relevant node.

Security Notes

• Review collected data before sharing it externally.
• Redact tokens, secrets, customer identifiers, and internal endpoints.
• Align bundle handling with your organization's data retention policy.

Contributing

• Keep specs provider-neutral unless explicitly scoped.
• Avoid embedding internal URLs, account names, or environment identifiers.
• Include a short description when adding a new example under examples/.