Generate a Support Bundle

Follow these instructions to generate a support bundle with data collected for the last 48 hours of the life of the cluster.

Prerequisites

Before generating a support bundle, verify that you have:

An AMD64-based Linux or macOS machine with a supported version of the operating system.
A running Kubernetes cluster.
Access to the DKP CLI.

Diagnostic Bundle

dkp diagnose was developed by D2iQ and builds on the open source troubleshoot.sh project.

The command dkp diagnose is based on version 0.13.16 of troubleshoot.sh with custom modifications. The D2iQ fork is open source and available from this public GitHub repository.

dkp diagnose supports multiple support bundle collectors and can be configured as a SupportBundle Kubernetes resource in a YAML file.

The following list is the minimum set of resources that is required to debug a cluster, but can be further customized.

The bundle uses the following collectors:

clusterInfo collects basic information about the cluster
clusterResources collects a subset of available resources in the cluster
configMap collects the values of Kubernetes ConfigMaps
secrets collects the names and metadata of secrets, but NOT the secret values or keys
execCopyFromHost runs a container on each node on the cluster and copies the created data
allLogs is capable of collecting logs from all containers on the cluster
cpuMemoryUtilisation collects the average CPU and memory utilization of the last 30 days.

Generate a Support Bundle

The command dkp diagnose uses the same Kubernetes configuration as kubectl. dkp diagnose can also be pointed at a specific configuration by using the --kubeconfig parameter.

To generate the support bundle, perform the following steps:

Run the dkp diagnose command by running the default collectors configuration.
CODE
```
dkp diagnose
```
The output looks similar to this:
CODE
```
Collecting support bundle ...

support-bundle-2021-08-13T14_44_23.tar.gz
```
To view the bundle contents, extract the bundle (replacing support-bundle-2021-08-13T14_44_23.tar.gz with the location from the previous step):
CODE
```
tar -xzvf support-bundle-2021-08-13T14_44_23.tar.gz
```
A new directory named support-bundle-<date-created>is created. This directory contains the files specified:
CODE
```
ls support-bundle-2021-08-13T14_44_23
```
The output looks similar to this:
CODE
```
cluster-info  cluster-resources  configmaps  node-diagnostics  pod-logs  secrets  version.yaml
```

Collect Information from a Bootstrap Cluster

In the case where your bootstrap cluster has not yet pivoted towards your Konvoy cluster, you can collect log information from that bootstrap cluster as well, and there are a preconfigured set of relevant collectors. Specify an additional bootstrap cluster kubeconfig using the --bootstrap-kubeconfig parameter to activate bootstrap cluster diagnostics. You will receive an additional support bundle named bootstrap-support-bundle-<date created>.

Note that the bootstrap cluster diagnostics are independent of the configuration of the “main” or Konvoy cluster diagnostics. We run a static collector set that collects the following bootstrap cluster information:

ClusterInfo
ClusterResources
AllLogs
ConfigMaps
Secrets

Run the dkp diagnose command with bootstrap bundle configuration.

CODE

    dkp diagnose bundle.yaml

Customizations

To print the default collectors configuration, run the following command:

CODE

dkp diagnose default-config > bundle.yaml

Edit the file to make appropriate modifications.

By default, dkp diagnose does not require that you supply a configuration. You can print the default bundle by running dkp diagnose default-config.

SSH Fallback

In some cases the Kubernetes API is not available for the cluster. In those cases you can collect node level information using SSH access to the diagnosed nodes. Be aware that not all clusters have SSH access configured. If they do not then access using SSH fallback is not possible.

To get node level information from your cluster using SSH access, perform the following steps:

Enter the following command:

CODE

dkp diagnose ssh <path/to/ansible-inventory.yaml>

The ansible-inventory.yaml file specifies the nodes to access for data collection.

This collector does not use the full Ansible inventory.yaml format only a limited subset to describe the infrastructure.

Only the following attributes of the ansible-inventory.yaml are supported. All other group definitions are ignored.

Support for all shared variables.
Support for hosts key in all groups.
Supported behavioral inventory is limited to:
- ansible_host
- ansible_port
- ansible_user
- ansible_ssh_private_key_file
The following is an example inventory.yaml file:

CODE

all:
  vars:
    ansible_user: centos
  hosts:
    host-1:
      ansible_host: 192.168.10.1
    host-2:
      ansible_host: 192.168.10.22
      ansible_port: 2222

More information on these Ansible parameters can be found in the Ansible user guide.

All other group definitions in the inventory.yaml file are ignored.

Refer to the following example file:

CODE

all:
  vars:
    ansible_user: centos
  hosts:
    host-1:
      ansible_host: 192.168.10.1
    host-2:
      ansible_host: 192.168.10.22
      ansible_port: 2222

The fallback collector runs a bash script over SSH and copies the collected data. The format of the created bundle matches that of dkp diagnose collector generated bundles.

CODE

    node-diagnostics/<HOSTNAME_PORT>/data/
        - dmesg
        - ....

Redactors are supported and are in the same format as the main dkp diagnose command. Per node collection timeouts are supported using the --timeout parameter.

See also: dkp-cli