Skip to content

Latest commit

 

History

History
155 lines (132 loc) · 4.33 KB

using_quobyte_volumes.md

File metadata and controls

155 lines (132 loc) · 4.33 KB
Raw

Volume Access

Quobyte volumes can be accessed from Pods in multiple ways. Either, via the QuobyteVolumeSource like in deploy/example-pod.yaml

volumes:
- name: quobytevolume
  quobyte:
    registry: ignored:7861 # Unused string required for API compatibility
    volume: testVolume
    readOnly: false
    user: username
    group: groupname

or as a PersistentVolumeClaim, which is defined in the same namespace, where the accessing pod is running. The claim (volumes/claim.json)

{
  "kind": "PersistentVolumeClaim",
  "apiVersion": "v1",
  "metadata": {
    "name": "test"
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "3Gi"
      }
    },
    "storageClassName": "base"
  }
}
$ kubectl -n quobyte create -f volumes/claim.json

is mounted in the Pod like (see volumes/example-pod.yaml):

volumes:
  - name: quobytepvc
    persistentVolumeClaim:
      claimName: test

The PersistentVolumeClaim is bound to a PersistentVolume which is created by an administrator for existing Quobyte Volumes or dynamically by the StorageClass (volumes/storageclass.yaml).

If a Quobyte Volume already exists, the administrator can make it available as a PersistentVolume by creating a resource (volumes/pv.yaml). Please note that Quobyte currently ignores the required capacity.storage field, since its using internal quota mechanisms.

kind: PersistentVolume
apiVersion: v1
metadata:
  name: test
  labels:
    type: quobyte
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: "base"
  quobyte:
    registry: ignored:7861 # Unused string required for API compatibility
    volume: test
    readOnly: false
    user: username
    group: groupname
$ kubectl -n quobyte create -f volumes/pv.yaml

For dynamic provisioning, a StorageClass is created, which manages the lifecycle of Quobyte volumes. Each provisioner is bound to a Quobyte tenant, which is specified in the 'quobyteTenant' field. The UUID of the tenant can be found in the Webconsole. For Kubernetes > 1.10, the 'quobyteTenant' can specify the name of the tenant.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: base
provisioner: kubernetes.io/quobyte
parameters:
    quobyteAPIServer: "http://api.quobyte:7860"
    registry: "registry.quobyte:7861"
    adminSecretName: "quobyte-admin-secret"
    adminSecretNamespace: "kube-system"
    user: "username"
    group: "groupname"
    quobyteConfig: "BASE"
    quobyteTenant: "uuid of tenant"
    createQuota: "False"

To enable it, first create the Quobyte admin secret according to your API credentials in volumes/quobyte-admin-secret.yaml (defaults to admin:quobyte):

apiVersion: v1
kind: Secret
metadata:
  name: quobyte-admin-secret
type: "kubernetes.io/quobyte"
data:
  password: cXVvYnl0ZQ==
  user: YWRtaW4=
type: kubernetes.io/quobyte

The password and user strings are base64 encoded and can be created like echo -n "quobyte" | base64.

$ kubectl -n kube-system create -f volumes/quobyte-admin-secret.yaml
$ kubectl -n quobyte create -f volumes/storageclass.yaml

Quobyte Tenants and Kubernetes Namespaces

Quobyte supports multiple tenants and provides a secure mapping of containers to users known in Quobyte. For a longer read, please see the article on the Quobyte blog: The State of Secure Storage Access in Container Infrastructures

The Kubernetes deployments of the Quobyte client use the --allow-usermapping-in-volumename, which allows to map all accesses to the volume to a particular user/group, independent of the accessing user. If you specify user#group@volume_name instead of just the volumename, the Quobyte client will map all storage accesses to the user:group. For example, if your container runs internally with id 0, or you have multiple arbitrary user ids in your containers, all files in the Quobyte volume will be owned by user:group.

Further Readings