Skip to main content
OpenEBS logo
Star

Jiva User Guide

EditGitHub
2.12.x
note

The recommended approach to provision Jiva volumes is via CSI Driver. For detailed instructions on how to get started with new Jiva CSI Driver please refer to the Quickstart guide on Github.

OpenEBS configuration flow

For details of how Jiva works, see Jiva overview page

Jiva is a light weight storage engine that is recommended to use for low capacity workloads. The snapshot and storage management features of the other cStor engine are more advanced and is recommended when snapshots are a need.

User operations#

Simple provisioning of Jiva

Provisioning with Local or Cloud Disks

Provision Sample Application with Jiva Volume

Monitoring a Jiva Volume

Backup and Restore

Admin operations#

Create a Jiva Pool

Create a StorageClass

Setting up Jiva Storage Policies

User Operations#

Simple Provisioning of Jiva#

To quickly provision a Jiva volume using the default pool and StorageClass, use the following command

kubectl apply -f https://raw.githubusercontent.com/openebs/openebs/master/k8s/demo/pvc-standard-jiva-default.yaml

In this mode, OpenEBS provisions a Jiva volume with three replicas on three different nodes. Ensure that there are 3 Nodes in the cluster. The data in each replica is stored in the local container storage of that replica itself. The data is replicated and highly available and is suitable for quick testing of OpenEBS and simple application PoCs. If it is single node cluster, then download the above YAML spec and change the replica count accordingly and apply the modified YAML spec.

Provisioning with Local or Cloud Disks#

In this mode, local disks on each node has to be formatted and mounted at a directory path. The steps for mounting a disk into a node and creating a Jiva storage pool is provided here. Then, storage class has to be created by specifying this StoragePool name. You can use this StorageClass in PVC configuration.

Provision Sample Applications with Jiva Volume#

1.Percona#

Here we illustrate the usage of default Jiva storage class. In the following example manifest, the default storage class openebs-jiva-default is specified in PersistentVolumeClaim specification. So, the Jiva volume will be created with 3 replicas adhering to the default configuration. The manifest for deploying Percona can be downloaded from here or use the following spec.

  • Percona spec

    ---
    apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
    name: percona
    labels:
    name: percona
    spec:
    replicas: 1
    selector:
    matchLabels:
    name: percona
    template:
    metadata:
    labels:
    name: percona
    spec:
    securityContext:
    fsGroup: 999
    tolerations:
    - key: "ak"
    value: "av"
    operator: "Equal"
    effect: "NoSchedule"
    containers:
    - resources:
    limits:
    cpu: 0.5
    name: percona
    image: percona
    args:
    - "--ignore-db-dir"
    - "lost+found"
    env:
    - name: MYSQL_ROOT_PASSWORD
    value: k8sDem0
    ports:
    - containerPort: 3306
    name: percona
    volumeMounts:
    - mountPath: /var/lib/mysql
    name: demo-vol1
    volumes:
    - name: demo-vol1
    persistentVolumeClaim:
    claimName: demo-vol1-claim
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
    name: demo-vol1-claim
    spec:
    storageClassName: openebs-jiva-default
    accessModes:
    - ReadWriteOnce
    resources:
    requests:
    storage: 5G
    ---
    apiVersion: v1
    kind: Service
    metadata:
    name: percona-mysql
    labels:
    name: percona-mysql
    spec:
    ports:
    - port: 3306
    targetPort: 3306
    selector:
    name: percona

  • Run the application using following command.

    kubectl apply -f demo-percona-mysql-pvc.yaml

    Now, Percona application runs inside jiva default storage pool.

2.Busybox#

Before provisioning the application ensure that all the below mentioned steps are carried out:

  1. Ensure that the filesystem is mounted as per requirement. To know more about mount status click here.

  2. First, You need to Create a Jiva Pool specifying the filesystem path on each node. To know about the detailed steps click here.

  3. Using this storage pool, create a storage class by referring here.

  4. Once all the above actions have been successfully executed, You can deploy Busybox with Jiva volume as follows Copy the below spec into a file, say demo-busybox-jiva.yaml and update storageClassName to openebs-jiva-gpd-3repl.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: busybox
    labels:
    app: busybox
    spec:
    replicas: 1
    strategy:
    type: RollingUpdate
    selector:
    matchLabels:
    app: busybox
    template:
    metadata:
    labels:
    app: busybox
    spec:
    containers:
    - resources:
    limits:
    cpu: 0.5
    name: busybox
    image: busybox
    command: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 3306
    name: busybox
    volumeMounts:
    - mountPath: /var/lib/mysql
    name: demo-vol1
    volumes:
    - name: demo-vol1
    persistentVolumeClaim:
    claimName: demo-vol1-claim
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
    name: demo-vol1-claim
    spec:
    storageClassName: openebs-jiva-gpd-3repl
    accessModes:
    - ReadWriteOnce
    resources:
    requests:
    storage: 5G
    ---
    apiVersion: v1
    kind: Service
    metadata:
    name: busybox-mysql
    labels:
    name: busybox-mysql
    spec:
    ports:
    - port: 3306
    targetPort: 3306
    selector:
    name: busybox
    ```
    To deploy busybox, execut
    ```
    kubectl apply -f demo-busybox-jiva.yaml
    ```

  5. To verify whether the application is successfully deployed, execute the following command

    kubectl get pods

    The application pods should be running as displayed below

    NAME READY STATUS RESTARTS AGE
    busybox-66db7d9b88-pod01 1/1 Running 0 2m16s

Monitoring a Jiva Volume#

By default VolumeMonitor is set to ON in the JIva StorageClass. Volume metrics are exported when this parameter is set to ON. Following metrics are supported by Jiva as of the current release.

openebs_actual_used # Actual volume size used
openebs_connection_error_total # Total no of connection errors
openebs_connection_retry_total # Total no of connection retry requests
openebs_degraded_replica_count # Total no of degraded/ro replicas
openebs_healthy_replica_count # Total no of healthy replicas
openebs_logical_size # Logical size of volume
openebs_parse_error_total # Total no of parsing errors
openebs_read_block_count # Read Block count of volume
openebs_read_time # Read time on volume
openebs_reads # Read Input/Outputs on Volume
openebs_sector_size # sector size of volume
openebs_size_of_volume # Size of the volume requested
openebs_total_replica_count # Total no of replicas connected to cas
openebs_volume_status # Status of volume: (1, 2, 3, 4) = {Offline, Degraded, Healthy, Unknown}
openebs_volume_uptime # Time since volume has registered
openebs_write_block_count # Write Block count of volume
openebs_write_time # Write time on volume
openebs_writes # Write Input/Outputs on Volume

Grafana charts can be built for the above Prometheus metrics.

Backup and Restore#

OpenEBS volume can be backed up and restore along with application using velero plugin. It helps the user for taking backup of OpenEBS volumes to a third party storage location and then restoration of the data whenever it needed. The steps for taking backup and restore are following.

Prerequisites#

  • Mount propagation feature has to be enabled on Kubernetes, otherwise the data written from the pods will not visible in the restic daemonset pod on the same node. It is enabled by default on Kubernetes version 1.12. More details can be get from here.
  • Latest tested Velero version is 1.4.0.
  • Create required storage provider configuration to store the backup data.
  • Create required storage class on destination cluster.
  • Annotate required application pod that contains a volume to back up.

Overview#

Velero is a utility to back up and restore your Kubernetes resource and persistent volumes.

To take backup and restore of Jiva volume, configure Velero with restic and use velero backup command to take the backup of application with OpenEBS Jiva volume which invokes restic internally and copies the data from the given application including the entire data from the associated persistent volumes in that application and backs it up to the configured storage location such as S3 or Minio.

The following are the step by step procedure for taking backup and restore of application with Jiva.

  1. Install Velero
  2. Annotate Application Pod
  3. Creating and Managing Backups
  4. Steps for Restore

Install Velero (Formerly known as ARK)#

Follow the instructions at Velero documentation to install and configure Velero and follow restic integration documentation for setting up and usage of restic support.

While installing Velero plugin in your cluster, specify --use-restic to enable restic support.

Verify using the following command if restic pod and Velero pod are running after installing velero with restic support.

kubectl get pod -n velero

The following is an example output in a 3 Node cluster.

NAME READY STATUS RESTARTS AGE
restic-8hxx8 1/1 Running 0 9s
restic-nd9d9 1/1 Running 0 9s
restic-nd8d8 1/1 Running 0 9s
velero-db6459bb-n2rff 1/1 Running 0 9s

Annotate Application Pod#

Run the following to annotate each application pod that contains a volume to back up.

kubectl -n YOUR_POD_NAMESPACE annotate pod/YOUR_POD_NAME backup.velero.io/backup-volumes=YOUR_VOLUME_NAME_1,YOUR_VOLUME_NAME_2,...

In the above example command, where the volume names are the names of the volumes specified in the application pod spec.

Example Spec:

If application spec contains the volume name as mentioned below, then use volume name as demo-vol1 in the below command.

volumeMounts:
- mountPath: /var/lib/mysql
name: demo-vol1
volumes:
- name: demo-vol1
persistentVolumeClaim:
claimName: demo-vol1-claim

And if the application pod name is percona-7b64956695-dk95r , use the following command to annotate the application.

kubectl -n default annotate pod/percona-7b64956695-dk95r backup.velero.io/backup-volumes=demo-vol1

Creating and Managing Backups#

Take the backup using the below command. Here you should add the selector for avoiding Jiva controller and replica deployment from taking backup.

velero backup create <backup_name> --selector '!openebs.io/controller,!openebs.io/replica'

Example:

velero backup create hostpathbkp2 --selector '!openebs.io/controller,!openebs.io/replica'

After taking backup, verify if backup is taken successfully by using following command.

velero backup get

The following is a sample output.

NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
hostpathbkp2 Completed 2019-06-19 17:14:43 +0530 IST 29d default !openebs.io/controller,!openebs.io/replica

You will get more details about the backup using the following command.

velero backup describe hostpathbkp2 --details

Once the backup is completed you should see the Phase marked as Completed in the output of above command.

Steps for Restore#

Velero backup can be restored onto a new cluster or to the same cluster. An OpenEBS PVC with the same name as the original PVC will be created and application will run using the restored OpenEBS volume.

Prerequisites

  • Create the same namespace and StorageClass configuration of the source PVC in your destination cluster.
  • If the restoration is happens on same cluster where Source PVC was created, then ensure that application and its corresponding components such as Service, PVC and PV are deleted successfully.

On the target cluster, restore the application using the below command.

velero restore create --from-backup <backup-name>

Example:

velero restore create --from-backup hostpathbkp2

The following can be used to obtain the restore job status.

velero restore get

The following is an example output. Once the restore is completed you should see the status marked as Completed.

NAME BACKUP STATUS WARNINGS ERRORS CREATED SELECTOR
hostpathbkp2-20190619171932 hostpathbkp2 Completed 44 0 2019-06-19 17:19:33 +0530 IST <none>

Verify application status using the following command.

kubectl get pod -n <namespace>

Verify PVC status using the following command.

kubectl get pvc -n <namespace>

Verify PV status using the following command.

kubectl get pv

Admin Operations#

Create a Jiva Pool#

The process of creating a Jiva pool include the following steps.

  1. Prepare disks and mount them

  2. Create a Jiva pool using the above mounted disk.

Prepare disks and mount them#

If it is a cloud disk provision and mount on the node. If three replicas of Jiva volume are needed, provision three cloud disks and mount them on each node. The mount path needs to be same on all three nodes. The following is the steps for creating a GPD disk on Google cloud and mounting to the node.

  • Create a GPD

    gcloud compute disks create disk1 --size 100GB --type pd-standard --zone us-central1-a

  • Attach the GPD to a node

    gcloud compute instances attach-disk <Node Name> --disk disk1 --zone us-central1-a

  • If the disk attached is mapped to /dev/sdb, verify the size, mount the disk and format it

    sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
    sudo mkfs.ext4 /dev/<device-name>
    sudo mkdir /home/openebs-gpd
    sudo mount /dev/sdb /home/openebs-gpd

  • Repeat the above steps on other two nodes if this is a three replica case.

Create a Jiva Pool using the mounted disk#

Jiva pool requires mount path to be prepared and available on the Node. Note that if the mount path is not pointing a real disk, then a local directory is created with this mount path and the replica data goes to the container image disk (similar to the case of default pool).

  • YAML specification to create the Jiva pool is shown below

    apiVersion: openebs.io/v1alpha1
    kind: StoragePool
    metadata:
    name: gpdpool
    type: hostdir
    spec:
    path: "/home/openebs-gpd"

  • Copy the above content to the into a file called jiva-gpd-pool.yaml and create the pool using the following command.

    kubectl apply -f jiva-gpd-pool.yaml

  • Verify if the pool is created using the following command

    kubectl get storagepool

Create a StorageClass#

This StorageClass is mainly for using the Jiva Storagepool created with a mounted disk. Jiva volume can be provision using default Jiva StorageClass named openebs-jiva-default in the corresponding PVC spec. The default StorageClass has replica count as 3. The steps for creating Jiva Storage pool is mentioned in the above section. Specify the Jiva pool in the StoragePool annotation of StorageClass. Example StorageClass specification is given below.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-gpd-3repl
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: ReplicaCount
value: "3"
- name: StoragePool
value: gpdpool
provisioner: openebs.io/provisioner-iscsi

  • Copy the above content to the into a file called jiva-gpd-3repl-sc.yaml and create the pool using the following command

    kubectl apply -f jiva-gpd-3repl-sc.yaml

  • Verify if the StorageClass is created using the following command

    kubectl get sc

Setting up Jiva Storage Policies#

Below table lists the storage policies supported by Jiva. These policies can be added into StorageClass and apply them through PersistentVolumeClaim or VolumeClaimTemplates interface.

JIVA STORAGE POLICYMANDATORYDEFAULTPURPOSE
ReplicaCountNo3Defines the number of Jiva volume replicas
Replica Imageopenebs/m-apiserver:2.11.0To use particular Jiva replica image
ControllerImageopenebs/jiva:2.11.0To use particular Jiva Controller Image
StoragePoolYesdefaultA storage pool provides a persistent path for an OpenEBS volume. It can be a directory on host OS or externally mounted disk.
VolumeMonitorONWhen ON, a volume exporter sidecar is launched to export Prometheus metrics.
VolumeMonitorImageopenebs/m-exporter:2.11.0Used when VolumeMonitor is ON. A dedicated metrics exporter to the workload. Can be used to apply a specific issue or feature for the workload
Volume FSTypeext4Specifies the filesystem that the volume should be formatted with. Other values are xfs
Volume Space ReclaimfalseIt will specify whether data need to be retained post PVC deletion.
TargetNodeSelectorDecided by Kubernetes schedulerSpecify the label in key: value format to notify Kubernetes scheduler to schedule Jiva target pod on the nodes that match label.
Replica NodeSelectorDecided by Kubernetes schedulerSpecify the label in key: value format to notify Kubernetes scheduler to schedule Jiva replica pods on the nodes that match label.
TargetTolerationsDecided by Kubernetes schedulerConfiguring the tolerations for Jiva Target pod.
ReplicaTolerationsDecided by Kubernetes schedulerConfiguring the tolerations for Jiva Replica pods.
TargetResourceLimitsDecided by Kubernetes schedulerCPU and Memory limits to Jiva Target pod
TargetResourceRequestsDecided by Kubernetes schedulerConfiguring resource requests that need to be available before scheduling the containers.
AuxResourceLimitsDecided by Kubernetes schedulerconfiguring resource limits on the target pod.
AuxResourceRequestsDecided by Kubernetes schedulerConfigure minimum requests like ephemeral storage to avoid erroneous eviction by K8s.
ReplicaResourceRequestsDecided by Kubernetes schedulerConfiguring resource requests that need to be available to the Replica.
ReplicaResourceLimitsDecided by Kubernetes schedulerAllow you to specify resource limits for the Replica.
Target AffinityDecided by Kubernetes schedulerThe policy specifies the label key: value pair to be used both on the Jiva target and on the application being used so that application pod and Jiva target pod are scheduled on the same node.
OpenEBS Namespace Policy for Jiva PodsfalseJiva Pod will be deployed in PVC name space by default. With the value as true, Jiva Pods will run in OpenEBS namespace.

Replica Count Policy#

You can specify the Jiva replica count using the value for ReplicaCount property. In the following example, the jiva-replica-count is specified as 3. Hence, three replicas are created.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: ReplicaCount
value: "3"
provisioner: openebs.io/provisioner-iscsi

Replica Image Policy#

You can specify the jiva replica image using value for ReplicaImage property.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: ReplicaImage
value: openebs/m-apiserver:2.11.0
provisioner: openebs.io/provisioner-iscsi

Controller Image Policy#

You can specify the jiva controller image using the value for ControllerImage property.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: ControllerImage
value: openebs/jiva:2.11.0
provisioner: openebs.io/provisioner-iscsi

Volume Monitor Policy#

You can specify the jiva volume monitor feature which can be set using value for VolumeMonitor property.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- enabled: "true"
name: VolumeMonitor
provisioner: openebs.io/provisioner-iscsi

Storage Pool Policy#

A storage pool provides a persistent path for an OpenEBS volume. It can be a directory on any of the following.

  • host-os or
  • mounted disk

Note:

You must define the storage pool as a Kubernetes Custom Resource (CR) before using it as a Storage Pool policy. Following is a sample Kubernetes custom resource definition for a storage pool.

apiVersion: openebs.io/v1alpha1
kind: StoragePool
metadata:
name: default
type: hostdir
spec:
path: "/mnt/openebs"

This storage pool custom resource can now be used as follows in the storage class.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: StoragePool
value: default
provisioner: openebs.io/provisioner-iscsi

Volume File System Type Policy#

You can specify a storage class policy where you can specify the file system type. By default, OpenEBS comes with ext4 file system. However, you can also use the xfs file system.

Following is a sample setting.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-mongodb
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: FSType
value: "xfs"
provisioner: openebs.io/provisioner-iscsi

Volume Monitoring Image Policy#

You can specify the monitoring image policy for a particular volume using value for VolumeMonitorImageproperty. The following Kubernetes storage class sample uses the Volume Monitoring policy. By default, volume monitor is enabled.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: VolumeMonitorImage
value: openebs/m-exporter:2.11.0
provisioner: openebs.io/provisioner-iscsi

Volume Space Reclaim Policy#

Support for a storage policy that can disable the Jiva Volume Space reclaim. You can specify the jiva volume space reclaim feature setting using the value for RetainReplicaData property. If User would like to disable Jiva Volume Space reclaim (or in other words - retain the volume data post PVC deletion), set RetainReplicaData as true. RetainReplicaData specifies whether Jiva replica data folder should be cleared or retained. In the following example, the Jiva volume space reclaim feature is disabled. Hence, volume data will be retained post PVC deletion.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-jiva-default
annotations:
openebs.io/cas-type: jiva
cas.openebs.io/config: |
- name: RetainReplicaData
enabled: true
provisioner: openebs.io/provisioner-iscsi

Target NodeSelector Policy#

You can specify the TargetNodeSelector where Target pod has to be scheduled using the value for TargetNodeSelector. In following example, node: appnode is the node label.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: TargetNodeSelector
value: |-
node: appnode
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

Replica NodeSelector Policy#

You can specify the ReplicaNodeSelector where replica pods has to be scheduled using the value for ReplicaNodeSelector . In following sample storage class yaml, node: openebs is the node label.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: ReplicaNodeSelector
value: |-
node: openebs
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

TargetTolerations Policy#

You can specify the TargetTolerations to specify the tolerations for Jiva target.

- name: TargetTolerations
value: |-
t1:
key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
t2:
key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"

ReplicaTolerations Policy#

You can specify the ReplicaTolerations to specify the tolerations for Replica.

- name: ReplicaTolerations
value: |-
t1:
key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
t2:
key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"

TargetResourceRequests Policy#

You can specify the TargetResourceRequests to specify resource requests that need to be available before scheduling the containers.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: TargetResourceRequests
value: |-
memory: 1Gi
cpu: 200m
ephemeral-storage: "100Mi"
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

Target ResourceLimits Policy#

You can specify the TargetResourceLimits to restrict the memory and cpu usage of Jiva target pod within the given limit using the value for TargetResourceLimits .

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: TargetResourceLimits
value: |-
memory: 1Gi
cpu: 200m
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

AuxResourceLimits Policy#

You can specify the AuxResourceLimits which allow you to set limits on side cars.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: AuxResourceLimits
value: |-
memory: 1Gi
cpu: 100m
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

AuxResourceRequests Policy#

This feature is useful in cases where user has to specify minimum requests like ephemeral storage etc. to avoid erroneous eviction by K8s. AuxResourceRequests allow you to set requests on side cars. Requests have to be specified in the format expected by Kubernetes.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: AuxResourceRequests
value: |-
memory: 0.5Gi
cpu: 50m
ephemeral-storage: "50Mi"
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

ReplicaResourceRequests Policy#

You can specify the ReplicaResourceRequests to requests the resource requirements of replica pod by specifying memory, CPU and ephemeral-storage values.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: ReplicaResourceRequests
value: |-
memory: 1Gi
cpu: 200m
ephemeral-storage: "100Mi"
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

ReplicaResourceLimits Policy#

You can specify the ReplicaResourceLimits to restrict the memory usage of replica pod within the given limit using the value for ReplicaResourceLimits.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
cas.openebs.io/config: |
- name: ReplicaResourceLimits
value: |-
memory: 2Gi
openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

Target Affinity Policy#

The Stateful workloads access the OpenEBS storage volume by connecting to the Volume Target Pod. This policy can be used to co-locate volume target pod on the same node as workload.

  • This feature makes use of the Kubernetes Pod Affinity feature that is dependent on the Pod labels. User will need to add the following label to both Application and PVC.

    labels:
    openebs.io/target-affinity: <application-unique-label>

  • You can specify the Target Affinity in both application and OpenEBS PVC using the following way.

    The following is a snippet of an application deployment YAML spec for implementing target affinity.

    apiVersion: v1
    kind: Pod
    metadata:
    name: fio-jiva
    labels:
    name: fio-jiva
    openebs.io/target-affinity: fio-jiva

    For OpenEBS PVC, it will be similar to the following.

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
    name: fio-jiva-claim
    labels:
    openebs.io/target-affinity: fio-jiva

Note: This feature works only for cases where there is a single application pod instance associated to a PVC. Example YAML spec for application deployment can be get from here. In the case of STS, this feature is supported only for single replica StatefulSet.

OpenEBS Namespace Policy for Jiva Pods#

This StorageClass Policy is for deploying the Jiva pods in OpenEBS Namespace. By default, the value is false, so Jiva Pods will deploy in PVC namespace. The following are the main requirement of running Jiva pods in OpenEBS namespace.

  • With default value, granting additional privileges to Jiva pods to access hostpath might involve granting privileges to the entire namespace of PVC. With enabling this value astrue , Jiva pods will get additional privileges to access hostpath in OpenEBS namespace.

  • To avoid duplicate Jiva Pod creation during the restoration using Velero.

    The following is a snippet of an StorageClass YAML spec for running Jiva pods in openebs namespace.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
    name: jiva-pods-in-openebs-ns
    annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
    - name: DeployInOpenEBSNamespace
    enabled: "true"
    provisioner: openebs.io/provisioner-iscsi

See Also:#

Understanding Jiva

Was this page helpful? We appreciate your feedback