Skip to main content

Customize Trident protect installation

Contributors netapp-shwetav netapp-mwallis
PDFs

You can customize the default configuration of Trident protect to meet the specific requirements of your environment.

Specify Trident protect container resource limits

You can use a configuration file to specify resource limits for Trident protect containers after you install Trident protect. Setting resource limits enables you to control how much of the cluster's resources are consumed by Trident protect operations.

Steps

  1. Create a file named resourceLimits.yaml.

  2. Populate the file with resource limit options for Trident protect containers according to the needs of your environment.

    The following example configuration file shows the available settings and contains the default values for each resource limit:

    ---
jobResources:
  defaults:
    limits:
      cpu: 8000m
      memory: 10000Mi
      ephemeralStorage: ""
    requests:
      cpu: 100m
      memory: 100Mi
      ephemeralStorage: ""
  resticVolumeBackup:
    limits:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
    requests:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
  resticVolumeRestore:
    limits:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
    requests:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
  kopiaVolumeBackup:
    limits:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
    requests:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
  kopiaVolumeRestore:
    limits:
      cpu: ""
      memory: ""
      ephemeralStorage: ""
    requests:
      cpu: ""
      memory: ""
      ephemeralStorage: ""

  3. Apply the values from the resourceLimits.yaml file:

    helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect -f resourceLimits.yaml --reuse-values

Customize security context constraints

You can use a configuration file to modify OpenShift security context constraint (SCCs) for Trident protect containers after you install Trident protect. These constraints define security restrictions for pods in a Red Hat OpenShift cluster.

Steps

  1. Create a file named sccconfig.yaml.

  2. Add the SCC option to the file and modify the parameters according to the needs of your environment.

    The following example shows the default values of the parameters for the SCC option:

    scc:
  create: true
  name: trident-protect-job
  priority: 1

    This table describes the parameters for the SCC option:

    Parameter Description Default

    create

    Determines whether an SCC resource can be created. An SCC resource will be created only if scc.create is set to true and the Helm installation process identifies an OpenShift environment. If not operating on OpenShift, or if scc.create is set to false, no SCC resource will be created.

    true

    name

    Specifies the name of the SCC.

    trident-protect-job

    priority

    Defines the priority of the SCC. SCCs with higher priority values are assessed before those with lower values.

    1

  3. Apply the values from the sccconfig.yaml file:

    helm upgrade trident-protect netapp-trident-protect/trident-protect -f sccconfig.yaml --reuse-values

    This will replace the default values with those specified in the sccconfig.yaml file.

Configure additional Trident protect helm chart settings

You can customize AutoSupport settings and namespace filtering to meet your specific requirements. The following table describes the available configuration parameters:

Parameter Type Description

autoSupport.proxy

string

Configures a proxy URL for NetApp AutoSupport connections. Use this to route support bundle uploads through a proxy server. Example: http://my.proxy.url.

autoSupport.insecure

boolean

Skips TLS verification for AutoSupport proxy connections when set to true. Use only for insecure proxy connections. (default: false)

autoSupport.enabled

boolean

Enables or disables daily Trident protect AutoSupport bundle uploads. When set to false, scheduled daily uploads are disabled, but you can still manually generate support bundles. (default: true)

restoreSkipNamespaceAnnotations

string

Comma-separated list of namespace annotations to exclude from backup and restore operations. Allows you to filter namespaces based on annotations.

restoreSkipNamespaceLabels

string

Comma-separated list of namespace labels to exclude from backup and restore operations. Allows you to filter namespaces based on labels.

You can configure these options using either a YAML configuration file or command-line flags:

Use YAML file
Steps

  1. Create a configuration file and name it values.yaml.

  2. In the file you created, add the configuration options you want to customize.

    autoSupport:
  enabled: false
  proxy: http://my.proxy.url
  insecure: true
restoreSkipNamespaceAnnotations: "annotation1,annotation2"
restoreSkipNamespaceLabels: "label1,label2"

  3. After you populate the values.yaml file with the correct values, apply the configuration file:

    helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect -f values.yaml --reuse-values
Use CLI flag
Steps

  1. Use the following command with the --set flag to specify individual parameters:

    helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set autoSupport.enabled=false \
  --set autoSupport.proxy=http://my.proxy.url \
  --set restoreSkipNamespaceAnnotations="annotation1,annotation2" \
  --set restoreSkipNamespaceLabels="label1,label2" \
  --reuse-values

Restrict Trident protect pods to specific nodes

You can use the Kubernetes nodeSelector node selection constraint to control which of your nodes are eligible to run Trident protect pods, based on node labels. By default, Trident protect is restricted to nodes that are running Linux. You can further customize these constraints depending on your needs.

Steps

  1. Create a file named nodeSelectorConfig.yaml.

  2. Add the nodeSelector option to the file and modify the file to add or change node labels to restrict according to the needs of your environment. For example, the following file contains the default OS restriction, but also targets a specific region and app name:

    nodeSelector:
  kubernetes.io/os: linux
  region: us-west
  app.kubernetes.io/name: mysql

  3. Apply the values from the nodeSelectorConfig.yaml file:

    helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect -f nodeSelectorConfig.yaml --reuse-values

    This replaces the default restrictions with those you specified in the nodeSelectorConfig.yaml file.