Preflight and Support Bundle

Preflight checks use collectors and analyzers to provide cluster operators with clear feedback for any missing requirements or incompatibilities in the target environment before an application is deployed. Preflight checks are not automatically included in releases, so you must define them if you want to include them with a release.

Support bundles collect and analyze troubleshooting data from a cluster and help diagnose problems with application deployments. Default support bundles are automatically included with releases, and can be customized.

Collectors and analyzers are configured in the Preflight and Support Bundle custom resource manifest files.

note

Built-in redactors run by default for preflight checks and support bundles to protect customers' sensitive information. To add custom redactors to a support bundle, use the Redactor custom manifest file. For more information about the Redactor custom manifest file, see Redactor.

Basic Manifest Files

To define preflight checks or customize the default support bundle settings, add the corresponding custom resource manifest file to your release. Then add custom collector and analyzer specifications to the custom resource manifest file. For more information about these troubleshoot features and how to configure them, see Configuring Preflight Checks and Support Bundles.

The following sections show basic manifest files for the Preflight and Support Bundle custom resources that you can start with.

Preflight

The Preflight manifest file uses kind: Preflight:

apiVersion: troubleshoot.sh/v1beta2
kind: Preflight
metadata:
  name: sample
spec:
  collectors: []
  analyzers: []

Support Bundle

The Support Bundle manifest file uses kind: SupportBundle:

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

Global Fields

Global fields, also known as shared properties, are fields that are supported on all collectors or all analyzers. The following sections list the global fields for collectors and analyzers respectively.

Additionally, each collector and analyzer has its own fields. For more information about collector- and analyzer-specific fields, see the Troubleshoot documentation.

Collector Global Fields

The following fields are supported on all optional collectors for preflights and support bundles. For a list of collectors, see All Collectors in the Troubleshoot documentation.

Field Name	Description
collectorName	(Optional) A collector can specify the collectorName field. In some collectors, this field controls the path where result files are stored in the support bundle.
exclude	(Optional) Based on the runtime available configuration, a conditional can be specified in the exclude field. This is useful for deployment techniques that allow templating for Replicated app manager and the optional Helm component. When this value is true, the collector is not included.

Collector Example

This is an example of collector definition for a support bundle:

apiVersion: troubleshoot.sh/v1beta2
kind: SupportBundle
metadata:
  name: sample
spec:
  collectors:
    - collectd:
        collectorName: "collectd"
        image: busybox:1
        namespace: default
        hostPath: "/var/lib/collectd/rrd"
        imagePullPolicy: IfNotPresent
        imagePullSecret:
           name: my-temporary-secret
           data:
             .dockerconfigjson: ewoJICJhdXRocyI6IHsKzCQksHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvIjoge30KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy4xMiAoZGFyd2luKSIKCX0sCgkiY3JlZHNTdG9yZSI6ICJkZXNrdG9wIiwKCSJleHBlcmltZW50YWwiOiAiZGlzYWJsZWQiLAoJInN0YWNrT3JjaGVzdHJhdG9yIjogInN3YXJtIgp9
           type: kubernetes.io/dockerconfigjson

Analyzer Global Fields

The following fields are supported on all optional analyzers for preflights and support bundles. For a list of analyzers, see Analyzing Data in the Troubleshoot documentation.

Field Name	Description
collectorName	(Optional) An analyzer can specify the collectorName field.
exclude	(Optional) Based on the runtime available configuration, a conditional can be specified in the exclude field. This is useful for deployment techniques that allow templating for Replicated app manager and the optional Helm component. When this value is true, the analyzer is not included.
strict	(Optional) An analyzer can be set to strict: true so that fail outcomes for that analyzer prevent the release from deploying until the vendor-specified requirements are met. When exclude: true is also specified, exclude overrides strict and the analyzer is not executed.

Analyzer Example

This is an example of an analyzer definition with a strict preflight check and exclude set for installations that do not use the Kubernetes installer. In this case, the strict preflight is enforced on a Kubernetes installer cluster but not on an existing cluster or air gap cluster.

apiVersion: troubleshoot.sh/v1beta2
kind: Preflight
metadata:
  name: check-kubernetes-version
spec:
  analyzers:
    - clusterVersion:
        exclude: 'repl{{ (not IsKurl) }}'
        strict: true
        outcomes:
          - fail:
              when: "< 1.16.0"
              message: The application requires Kubernetes 1.16.0 or later
              uri: https://kubernetes.io
          - warn:
              when: "< 1.17.0"
              message: Your cluster meets the minimum version of Kubernetes, but we recommend you update to 1.17.0 or later.
              uri: https://kubernetes.io
          - pass:
              message: Your cluster meets the recommended and required versions of Kubernetes.