Available in:  CE, SE, SE+, EE

The module lifecycle stage: General Availability
The module has requirements for installation

The module is guaranteed to work only with stock kernels that are shipped with the supported distributions.

The module may work with other kernels or distributions, but its stable operation and availability of all features is not guaranteed.

How to explicitly enable the module…

You may explicitly enable or disable the module in one of the following ways:

  • Via Deckhouse web UI. In the “System” → “System Management” → “Deckhouse” → “Modules” section, open the sds-node-configurator module and enable (or disable) the “Module enabled” toggle. Save changes.

    Example:

    Module enable/disable interface

  • Via Deckhouse CLI (d8).

    Use the d8 system module enable command for enabling, or d8 system module disable command for disabling the module (you need Deckhouse CLI (d8), configured to work with the cluster).

    Example of enabling the module:

    d8 system module enable sds-node-configurator

  • Using ModuleConfig sds-node-configurator.

    Set spec.enabled to true or false in ModuleConfig sds-node-configurator (create it if necessary);

    Example of a manifest to enable module sds-node-configurator:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: sds-node-configurator
spec:
  enabled: true

How to configure the module…

You can configure the module in one of the following ways:

  • Via Deckhouse web UI.

    In the “System” → “System Management” → “Deckhouse” → “Modules” section, open the sds-node-configurator module and enable the “Advanced Settings” switch. Fill in the required fields in the “Configuration” tab or specify the module settings in YAML format on the “YAML” tab, excluding the settings section. Save the changes.

    Example:

    Module Setup Interface

    You can also edit the ModuleConfig object sds-node-configurator on the “YAML” tab in the module settings window (“System” → “System Management” → “Deckhouse” → “Modules”, open the module sds-node-configurator) by specifying the schema version in the spec.version parameter and the necessary module parameters in the spec.settings section.

  • Via Deckhouse CLI (d8) (requires Deckhouse CLI (d8) configured to work with the cluster).

    Edit the existing ModuleConfig sds-node-configurator (for more details on configuring Deckhouse, see the documentation) by executing the following command:

    d8 k edit mc sds-node-configurator

    Make the necessary changes in the spec.settings section. If necessary, specify the schema version in the spec.version parameter. Save the changes.

    You can also create a file with manifest for ModuleConfig sds-node-configurator using the example below. Fill in the spec.settings section with the required module parameters. If necessary, specify the schema version in the spec.version parameter.

    Apply the manifest using the following command (indicate the manifest file name):

    d8 k apply -f <FILENAME>

    Example of a manifest for ModuleConfig sds-node-configurator:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: sds-node-configurator
spec:
  version: 1
  enabled: true
  settings: # Module parameters from the "Parameters" section below.

How to change the module release channel…

To change the module release channel, follow the instruction.

Requirements

To the Deckhouse version: 1.72 and above.

Parameters

Schema version: 1

  • settings
    object
    • settings.disableDs
      boolean
      Disable sds-node-configurator DaemonSet.

      Default: false

    • settings.enableNetlinkBlockDeviceDiscovery
      boolean
      Use netlink/sysfs instead of lsblk as the data source for block device discovery on the agent. When disabled, the agent discovers block devices via lsblk.

      Default: false

    • settings.enableThinProvisioning
      boolean
      Enable support of thin LVM volumes.

      Default: true

    • settings.fileDevicesDirectory
      string

      Base directory on each node under which the agent is allowed to create backing files for file-backed LVM devices (spec.fileDevices).

      Every spec.fileDevices[].directory must be this directory or a subdirectory of it; the agent rejects backing files outside this subtree to prevent an arbitrary host path (for example /etc or /var/lib/kubelet) from being filled up. Override it to point at a dedicated data disk mounted on the node when the default location does not have enough space.

      The filesystem root (/) is not accepted: it would make every absolute path a valid subdirectory and disable the restriction entirely.

      Default: /opt/deckhouse/sds/file-devices

      Pattern: ^/[^/]+(/[^/]+)*$

    • settings.fileDevicesMinFreeSpacePercent
      integer

      Share of the backing-file filesystem, in percent, that the agent keeps free when creating or growing a file-backed LVM device (spec.fileDevices).

      Backing files are preallocated, and by default they live on the node’s root filesystem. Allocating down to the last free byte is what causes a node-level outage rather than a mere provisioning error: kubelet starts evicting pods at nodefs.available<10%, long before the filesystem is actually full. The default of 15% matches kubelet’s stricter imagefs.available threshold and leaves a margin above the nodefs one.

      An entry that does not fit within this limit is not provisioned and is reported on the LVMVolumeGroup’s VGConfigurationApplied condition; the Volume Group itself keeps working.

      Lower it only when fileDevicesDirectory points at a dedicated disk that nothing else on the node depends on. 0 disables the reserve entirely.

      Default: 15

      Allowed values: 0 <= X <= 90

    • settings.logLevel
      string
      Module application log level.

      Default: INFO

      Allowed values: ERROR, WARN, INFO, DEBUG, TRACE