SupportDump resource

TechPreview

This section describes the SupportDump custom resource (CR) used in the management API to request collection of logs and Kubernetes objects from a management or MOSK cluster into a single .tar.gz archive. The archive is stored on the management cluster nodes, on the local volume created for supportdump-controller.

Caution

A cluster can have only one support dump collection running at a time. While a collection is in progress, creation of another SupportDump object for the same cluster is rejected. Wait for the running collection to complete or delete the existing object.

The SupportDump CR contains the following fields:

apiVersion
API version of the object that is kaas.mirantis.com/v1alpha1.
kind
Object type that is SupportDump.
metadata
Object metadata that contains the following fields:
- name
  Name of the SupportDump object.
- namespace
  Namespace used to create the SupportDump object. Must be equal to the namespace of the target cluster.
spec
Resource specification that contains the following fields:
- collectors
  List of collectors to run. Each list item enables one built-in collector: kubernetesObjects, underlayKubernetesLogs, or systemLogs. The same collector can be included several times with a different configuration. To run a collector with its default settings, use an empty dictionary, for example, underlayKubernetesLogs: {}.
  
  kubernetesObjects
  Collects Kubernetes objects and pod logs. Contains the following field:
  
  singleObjectCollectionTimeout
  Timeout for a single request that collects a Kubernetes object or pod logs. Accepts a duration string with a unit suffix, such as s, m, or h. For example, 45m or 1h30m.
  
  underlayKubernetesLogs
  Collects logs of the underlying Kubernetes cluster. Applies to MKE-based clusters only. The collected data includes logs of the MKE components running in Docker along with the MKE configuration. Contains the following fields:
  
  verbose
  Enables collection of additional data, such as non-system tasks and services. Boolean.
  
  serviceDriller
  Enables the swarm service driller. Boolean.
  
  logLines
  Sets the maximum number of lines to collect from journalctl. Integer.
  
  audit
  Enables collection of audit logs. Boolean.
  
  systemLogs
  Collects system logs from the cluster machines. If several filters are set, a machine must satisfy all of them for its logs to be collected. Contains the following fields:
  
  nodeLabels
  Map of node labels. Logs are collected only from machines that have all the listed labels set in the machine spec.
  
  machineNames
  Names of the machines to collect logs from.
- maxSizeMb
  Maximum size of the resulting archive, in MB.
  
  Caution
  
  The logs that do not fit into the size limit are discarded.
- overallTimeout
  Maximum duration of the entire collection. When the timeout is reached, the collection stops and everything collected by that moment is archived. Accepts a duration string with a unit suffix, such as s, m, or h. For example, 45m or 1h30m. Defaults to 10m.
- plugins
  Optional. List of plugins to run as part of the collection. All plugins run as containers of a single job on the management cluster. Each list item contains the following fields:
  
  image
  Image of the container that runs the plugin.
  
  name
  Name of the plugin. Must be unique within the list and be a valid RFC 1123 DNS label. The plugin output is placed into a subfolder of the resulting archive with the same name.
  
  env
  Key-value pairs of the plugin-specific environment variables passed into the container.
  
  secretName
  Optional. Name of the secret in the same namespace to pass sensitive content to the plugin without exposing it in plain text. The secret is mounted into the container at /secret.
  
  nodeAccess
  Enables mounting of the SSH key for the cluster machines into the container at /ssh. Boolean. Set to true only if the plugin requires access to the cluster machines.
  
  The kubeconfig file of the target cluster is provided to all plugins as a secret mounted at /kubeconfig/admin.conf. Each plugin writes the data it has collected into the /output folder mounted into its container.
- targetCluster
  Name of the cluster to collect the data from. The cluster must exist in the same namespace as the SupportDump object.
If the spec.collectors list contains the systemLogs collector, or if at least one plugin has nodeAccess set to true, a new SSH key is created for the collection. Its public part is placed into a PublicKey object that is added to spec.publicKeys of the targetCluster cluster object. Its private part is available to the systemLogs collector and is mounted into the plugin containers that require it. Both parts of the key are removed when the collection finishes.
status
Status of the SupportDump CR that contains the following fields:
- collectors
  List of collector statuses in the same order the collectors are listed in spec.collectors. Each list item contains the following fields:
  
  completedAt
  Time when the collector finished.
  
  message
  Message describing status details of the collector. Omitted if empty.
  
  startedAt
  Time when the collector started.
  
  status
  Collector status. Possible values:
  
  Pending
  Not processed yet.
  
  InProgress
  Currently running.
  
  Completed
  Completed successfully.
  
  Failed
  Failed. For details, see the message field.
  
  type
  Collector type that corresponds to the collector set in spec.collectors.
- completedAt
  Time when the SupportDump processing finished.
- fileName
  Path inside the podName pod to copy the resulting archive from.
- message
  Message describing status details of the SupportDump processing. Omitted if empty.
- plugins
  List of plugin statuses. Has the same structure as the collector statuses, with the plugin name replacing the collector type.
- podName
  Name of the supportdump-controller pod that processed the object.
- startedAt
  Time when the SupportDump processing started.
- status
  Overall SupportDump status. Possible values:
  
  Pending
  Not processed yet.
  
  InProgress
  Currently running.
  
  Completed
  Completed successfully.
  
  Failed
  Failed. For details, see the message field.

Caution

The overall status of the dump can be Completed even if some collectors have the Failed status, as long as at least some data is collected. The overall Failed status means that nothing has been collected, that the resulting archive could not be created, or that the job specification for plugins could not be constructed.