Storage class requirements

A persistent volume (PV) is a piece of storage in the Kubernetes cluster, while a persistent volume claim (PVC) is a request for storage. The Turbonomic platform uses persistent volumes to store logs, certificates, tokens, and some data for some of the services. It also dynamically provisions storage by using persistent volume claims to create PVs from the cluster's default storage class.

The following list outlines the recommended properties for a storage class. Follow the instructions for the storage provisioner that you are using.

  • Use a dynamic storage provisioner; Turbonomic creates the PVC.

  • Set Volume Expansion to be True.

  • Set Reclaim Policy to Retain.

  • Set Volume Binding Mode to WaitForFirstConsumer.

  • Encryption is supported.

  • Consider whether you want to use storage that is multi-zoned, but the cost will likely be more.

Volume binding mode and reclaim policies

To support pods with multiple PVs, especially where your nodes are spread across multiple Availability Zones (AZs) or regions, use a volume binding mode of WaitForFirstConsumer for your storage class. This sample storage class shows the minimum requirements that must be part of the default storage class in the cluster. You can also create a new storage class and specify it in the Turbonomic Custom Resource (CR). Use a storage class that reflects your cluster’s storage provisioner.

Best Practices

  • The Turbonomic platform relies on data that is stored in PVs that are important to retain target, licensing, and historical data association. Minimally you can use the reclaimPolicy option of Retain in the storage class. Back up the PVs associated with the following PVCs to aid in recovery if there is a loss of the server: api, api-certs, auth, and consul-data.

  • Volume backup strategy is important. If you are running a containerized DB for Turbonomic, the embedded reporting feature, or both, include these PVs to preserve: db-data and data-timescaledb-0.

  • Use a storage class that allows for volume expansion (allowVolumeExpansion) for the DB PVs.

Non-default storage class

The Turbonomic deployment uses the cluster's default storage class if one is defined. If you want to use a different storage class, specify the name of the storage class in the Turbonomic CR and apply the change.

  1. Open the CR file for editing.

    The location of the file depends on the type of Turbonomic installation that you are configuring.

    • VM Image installation of Turbonomic

      Log in to an SSH terminal session of your Turbonomic instance as the System Administrator that you set up when you installed Turbonomic.

      /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
    • Turbonomic on a Kubernetes node or node cluster

      deploy/crds/charts_v1alpha1_xl_cr.yaml
  2. Modify the CR file to include the storage class.

    global:
      repository: icr.io/cpopen/turbonomic 
      tag: 8.14.3
      storageClassName: <yourStorageClass>
      externalIP: 10.97.96.3
      pullPolicy: Always
  3. Apply the changes that you made to the CR file.

    For example, run the following command for VM image installations:

    kubectl apply -f /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
Note:

If you want to reconfigure an existing Turbonomic deployment to use a different storage class, re-create the PVCs to delete the PVs created with the original storage class. Contact IBM Support for assistance if you need to retain data on the original PVs.

Static storage providers

Turbonomic supports Kubernetes clusters that do not have a dynamic storage provisioner. To use a static storage provider, you must create the PVs and then create a storage class with the No Provisioner provisioner parameter. Specify the name of the storage class in the Turbonomic CR and apply the change. Refer to the previous section for the steps to modify the CR.

Contact IBM Support for more information and sample yamls for the storage class and PVs.

Persistent volumes

The following table describes the PVC resources and default configurations.

Component Persistent volume claim Size in Gi (default) Notes
api api 1  
api api-certs 1  
auth auth 1  
consul consul-data 1  
db db-data 500 This component is not required when you use an external DB server or service
kafka kafka-log 50  
prometheus prometheus-server 8  
redis(suspend) redis-data-redis-master-0 4 This component is required for the Parking feature.
rsyslog rsyslog-auditlogdata 30  
rsyslog rsyslog-syslogdata 30  
topology-processor topology-processor 3  
zookeeper zookeeper-data 3  
timescaledb data-timescaledb-0 125 This component is required if embedded reporting is enabled.

Specify a new value for spec: postgresql: persistence: size: <value> Gi

If you want to deploy with a different volume size, specify the volume in the Custom Resource. Combine these settings with any other properties specified. See the following example for db where the PVC size and Mem Limits are modified.

  db:
    resources:
      limits:
        memory: 16Gi
    persistence:
      size: 500Gi
Note:

You can change the storage size for the following components:

  • db
  • consul
  • kafka
  • rsyslog
  • timescaledb/postgresql for embedded reporting