Storage must exist in the underlying infrastructure before it can be mounted as
a volume in OpenShift. All that is required for Fibre Channel persistent storage is the targetWWNs (array of Fibre Channel target’s World Wide Names),
a valid LUN number, and filesystem type, and the PersistentVolume
API. Note, the number of LUNs must correspond to the number of Persistent Volumes that
are created. In the example below, we have LUN as 2, therefore we have created two Persistent Volume definitions.
Example 1. Persistent Volumes Object Definition
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
fc:
targetWWNs: ['500a0981891b8dc5', '500a0981991b8dc5']
lun: 2
fsType: ext4
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0002
spec:
capacity:
storage: 1Gi
accessModes:
- ReadOnlyMany
fc:
targetWWNs: ['500a0981891b8dc5', '500a0981991b8dc5']
lun: 2
fsType: ext4
|
Changing the value of the fstype parameter after the volume has been
formatted and provisioned can result in data loss and pod failure.
|
Enforcing Disk Quotas
Use LUN partitions to enforce disk quotas and size constraints. Each LUN is one persistent volume. Kubernetes enforces
unique names for persistent volumes.
Enforcing quotas in this way allows the end user to request persistent storage
by a specific amount (e.g, 10Gi) and be matched with a corresponding volume of
equal or greater capacity.
Fibre Channel Volume Security
Users request storage with a PersistentVolumeClaim
. This claim only lives in
the user’s namespace and can only be referenced by a pod within that same
namespace. Any attempt to access a persistent volume across a namespace causes
the pod to fail.
Each Fibre Channel LUN must be accessible by all nodes in the cluster.