Skip to main content

Customize Trident protect installation

Contributors netapp-mwallis netapp-shwetav
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 NetApp AutoSupport connections for Trident protect

You can change the way Trident protect connects to NetApp Support to upload support bundles by configuring a proxy for the connection. You can configure the proxy to use either a secure or an insecure connection based on your needs.

Configure a secure proxy connection
Steps

  1. Configure a secure proxy connection for Trident protect support bundle uploads:

    helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect --set autoSupport.proxy=http://my.proxy.url --reuse-values
Configure an insecure proxy connection
Steps

  1. Configure an insecure proxy connection for Trident protect support bundle uploads that skips TLS verification:

    helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect --set autoSupport.proxy=http://my.proxy.url --set autoSupport.insecure=true --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.

Disable daily Trident protect AutoSupport bundle uploads

Optionally, you can disable the scheduled daily Trident protect AutoSupport support bundle uploads.

Note By default, Trident protect collects support information that helps with any NetApp support cases that you might open, including logs, metrics, and topology information about clusters and managed applications. Trident protect sends these support bundles to NetApp on a daily schedule. You can manually generate a support bundle at any time.
Steps

  1. Create a file named autosupportconfig.yaml.

  2. Add the AutoSupport 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 AutoSupport option:

    autoSupport:
  enabled: true

    When autoSupport.enabled is set to false, daily uploads of AutoSupport support bundles are disabled.

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

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