The module lifecycle stage: Experimental
The module has requirements for installation

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-object 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-object

  • Using ModuleConfig sds-object.

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

    Example of a manifest to enable module sds-object:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: sds-object
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-object 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-object on the “YAML” tab in the module settings window (“System” → “System Management” → “Deckhouse” → “Modules”, open the module sds-object) 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-object (for more details on configuring Deckhouse, see the documentation) by executing the following command:

    d8 k edit mc sds-object

    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-object 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-object:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: sds-object
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.controller
      object
      Settings of the sds-object-controller (reconciler for ObjectStore, Bucket, BucketAccess and BucketClaimPolicy CRs).

      Default: {}

      • settings.controller.resourcesManagement
        sds-object-controller resources management options.

        Default: {}

        Example: 

        mode: VPA
vpa:
  cpu:
    limitRatio: 1.5
    max: 200m
    min: 50m
  memory:
    limitRatio: 1.5
    max: 256Mi
    min: 64Mi
  mode: Auto
        • settings.controller.resourcesManagement.mode
          string
          The mode for managing resource requests. Classical Static requests/limits or VPA.

          Default: VPA

          Allowed values: VPA, Static

        • settings.controller.resourcesManagement.static
          object
          Static resource management settings.
          • settings.controller.resourcesManagement.static.limits
            object
            Resource limits for the controller pod.
            • settings.controller.resourcesManagement.static.limits.cpu
              CPU limit.
            • settings.controller.resourcesManagement.static.limits.memory
              Memory limit.
          • settings.controller.resourcesManagement.static.requests
            object
            Resource requests for the controller pod.
            • settings.controller.resourcesManagement.static.requests.cpu
              CPU request.
            • settings.controller.resourcesManagement.static.requests.memory
              Memory request.
        • settings.controller.resourcesManagement.vpa
          object
          Parameters of the VPA mode.

          Default: {}

          • settings.controller.resourcesManagement.vpa.cpu
            object
            CPU-related parameters.

            Default: {}

            • settings.controller.resourcesManagement.vpa.cpu.limitRatio
              number

              Coefficient used to calculate the initial CPU limit from the request.

              VPA preserves the resulting limits/requests ratio during further resource tuning.

            • settings.controller.resourcesManagement.vpa.cpu.max
              Maximum allowed CPU requests.

              Default: 200m

            • settings.controller.resourcesManagement.vpa.cpu.min
              Minimum allowed CPU requests.

              Default: 50m

          • settings.controller.resourcesManagement.vpa.memory
            object
            Memory-related parameters.

            Default: {}

            • settings.controller.resourcesManagement.vpa.memory.limitRatio
              number

              Coefficient used to calculate the initial memory limit from the request.

              VPA preserves the resulting limits/requests ratio during further resource tuning.

            • settings.controller.resourcesManagement.vpa.memory.max
              Maximum allowed memory requests.

              Default: 256Mi

            • settings.controller.resourcesManagement.vpa.memory.min
              Minimum allowed memory requests.

              Default: 64Mi

          • settings.controller.resourcesManagement.vpa.mode
            string
            The VPA usage mode.

            Default: Auto

            Allowed values: Initial, Auto

    • settings.logLevel
      string
      Module log verbosity level.

      Default: INFO

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

    • settings.nodeSelector
      object

      The same as in the Pods’ spec.nodeSelector parameter in Kubernetes. Applies to the module service Pods (controller, webhooks). If the parameter is omitted or false, nodeSelector will be determined automatically.

      Note: this does not control placement of object storage data planes — that is configured per cluster via ObjectStore.spec.placement.

    • settings.systemBucket
      object
      The built-in system object storage: a System ObjectStore (Garage on control-plane nodes) with a system Bucket for platform needs. It runs three replicas with a replication factor of 3, independent of the control-plane node count, unless singleReplica reduces it to one.

      Default: {}

      • settings.systemBucket.enabled
        boolean
        Whether to provision the system ObjectStore and its system bucket. Disable if the platform does not need a built-in object storage.

        Default: true

      • settings.systemBucket.singleReplica
        boolean

        Run the system ObjectStore as a single Garage replica (replication_factor: 1) instead of the default three.

        The replica is placed on one control-plane node and never migrates between masters: its data lives on that node’s local volume and there is no second copy to re-replicate from. If that node is removed or stays down, the system storage is unavailable until it returns (the data on its disk is not touched), and the controller will not move the replica for you.

        Use it to cut the footprint of the system storage on small or non-production installations. Do not use it where the platform data in the system bucket must survive the loss of a control-plane node.

        Toggling this setting recreates the system ObjectStore and DESTROYS everything stored in it. Garage cannot change its replication factor on a live cluster, so the controller tears the data plane down (StatefulSet, volumes, node identities) and rebuilds it empty on fresh directories, in both directions (on and off). Buckets are recreated and access keys are re-issued automatically, but the objects are gone — back up anything you need first. The previous data directories are left on the control-plane nodes under /var/lib/deckhouse/sds-object/garage/system and can be removed manually once you no longer need them.

        Default: false

    • settings.tolerations
      array of objects
      The same as in the Pods’ spec.tolerations parameter in Kubernetes. Applies to the module service Pods (controller, webhooks). If the parameter is omitted or false, tolerations will be determined automatically.
      • settings.tolerations.effect
        string
        Taint effect the toleration matches. An empty value matches any effect.

        Allowed values: ‘’, NoSchedule, PreferNoSchedule, NoExecute

      • settings.tolerations.key
        string
        Taint key the toleration applies to. An empty key with operator: Exists matches any taint.
      • settings.tolerations.operator
        string
        Operator that defines how key and value are matched.

        Allowed values: Exists, Equal

      • settings.tolerations.tolerationSeconds
        integer

        Duration in seconds the toleration tolerates the taint after it is added.

        Applies only when effect is NoExecute. Unset means tolerate forever.

      • settings.tolerations.value
        string
        Taint value the toleration matches. Required when operator is Equal.