BeeGFS CSI Driver

Contents

• Overview
• Compatibility
• Support
• Getting Started
• Basic Use and Examples
• Contributing
• Releases
• Versioning
• License
• Maintainers

Overview

The BeeGFS Container Storage Interface (CSI) driver provides high performing and scalable storage for workloads running in container orchestrators like Kubernetes. This driver allows containers to access existing datasets or request on-demand ephemeral or persistent high speed storage backed by BeeGFS parallel file systems.

The driver can be easily deployed using the provided Kubernetes manifests. Optionally the BeeGFS CSI Driver Operator can be used to automate day-1 (install/ configure) and day-2 (reconfigure/update) tasks for the driver. This especially simplifies discovery and installation from Operator Lifecycle Manger (OLM) enabled clusters like Red Hat OpenShift.

Notable Features

• Integration of Storage Classes in Kubernetes with storage pools in BeeGFS, allowing different tiers of storage within the same file system to be exposed to end users.
• Management of global and node specific BeeGFS client configuration applied to Kubernetes nodes, simplifying use in large environments.
• Specify permissions in BeeGFS from Storage Classes in Kubernetes simplifying integration with BeeGFS quotas and providing visibility and control over user consumption of the shared file system.
• Set striping parameters in BeeGFS from Storage Classes in Kubernetes to optimize for diverse workloads sharing the same file system.
• Support for ReadWriteOnce, ReadOnlyMany, and ReadWriteMany access modes in Kubernetes allow workloads distributed across multiple Kubernetes nodes to share access to the same working directories and enable multi-user/application access to common datasets.

Compatibility

The BeeGFS CSI driver must interact with both Kubernetes and a BeeGFS filesystem. To ensure compatibility with relevant versions of these key software components regular testing is done throughout each release cycle. The following table describes the versions of each component used in testing each release of the BeeGFS CSI driver. These configurations should be considered compatible and supported.

See the compatibility guide for more details on expectations of compatibility for the BeeGFS CSI driver.

Support

Support for the BeeGFS CSI driver is "best effort". The following policy is in no way binding and may change without notice.

Only the latest version of the BeeGFS CSI driver is supported. Bugs or vulnerabilities found in this version may be fixed in a patch release or may be fixed in a new minor version. If they are fixed in a new minor version, upgrading to this version may be required to obtain the fix.

Fixes for old minor versions of the driver or backporting fixes to an older minor release of the driver should not be expected. The maintainers may choose to release a fix in a patch for an older release at their discretion.

Support for the BeeGFS driver can be expected when the driver is used with components listed in the compatibility table. The ability to provide support for issues with components outside of the compatibility matrix will depend on the details of the issue.

If you have any questions, feature requests, or would like to report an issue please submit them at https://github.com/NetApp/beegfs-csi-driver/issues.

Getting Started

Prerequisite(s)

• Deploying the driver requires access to a terminal with kubectl.
• The BeeGFS DKMS client must be preinstalled to each Kubernetes node that needs BeeGFS access.
  • Note: As part of this setup the beegfs-helperd and beegfs-utils packages must be installed, and the beegfs-helperd service must be started and enabled.
  • Note: Experimental support for OpenShift environments with RedHat CoreOS nodes negates this requirement.
• Each BeeGFS mount point uses an ephemeral UDP port. On Linux the selected ephemeral port is constrained by the values of IP variables. Ensure that firewalls allow UDP traffic between BeeGFS management/metadata/storage nodes and ephemeral ports on Kubernetes nodes.
• One or more existing BeeGFS file systems should be available to the Kubernetes nodes over a TCP/IP and/or RDMA (InfiniBand/RoCE) capable network (not required to deploy the driver).

Quick Start

The steps in this section allow you to get the driver up and running quickly. For production use cases or air-gapped environments it is recommended to read through the full kubectl deployment guide or operator deployment guide.

1. On a machine with kubectl and access to the Kubernetes cluster where you want to deploy the BeeGFS CSI driver clone this repository: git clone https://github.com/NetApp/beegfs-csi-driver.git
2. Change to the BeeGFS CSI driver directory (cd beegfs-csi-driver) and run: kubectl apply -k deploy/k8s/overlays/default
   • Note by default the beegfs-csi-driver image will be pulled from DockerHub.
3. Verify all components are installed and operational: kubectl get pods -n beegfs-csi

As a one-liner: git clone https://github.com/NetApp/beegfs-csi-driver.git && cd beegfs-csi-driver && kubectl apply -k deploy/k8s/overlays/default && kubectl get pods -n beegfs-csi

Provided all Pods are running the driver is now ready for use. See the following sections for how to get started using the driver.

Basic Use

This section provides a quick summary of basic driver use and functionality. Please see the full usage documentation for a complete overview of all available functionality. The driver was designed to support both dynamic and static storage provisioning and allows directories in BeeGFS to be used as Persistent Volumes (PVs) in Kubernetes. Pods with Persistent Volume Claims (PVCs) are only able to see/access the specified directory (and any subdirectories), providing isolation between multiple applications and users using the same BeeGFS file system when desired.

Dynamic Storage Provisioning:

Administrators create a Storage Class in Kubernetes referencing at minimum a specific BeeGFS file system and parent directory within that file system. Users can then submit PVCs against the Storage Class, and are provided isolated access to new directories under the parent specified in the Storage Class.

Static Provisioning:

Administrators create a PV and PVC representing an existing directory in a BeeGFS file system. This is useful for exposing some existing dataset or shared directory to Kubernetes users and applications.

Examples

Example Kubernetes manifests of how to use the driver are provided. These are meant to be repurposed to simplify creating objects related to the driver including Storage Classes, Persistent Volumes, and Persistent Volume Claims in your environment.

Contributing to the Project

The BeeGFS CSI Driver maintainers welcome improvements from the BeeGFS and open source community! Please see CONTRIBUTING.md for how to get started.

Releases

The goal is to release a new driver version three to four times per year (roughly quarterly). Releases may be major, minor, or patch at the discretion of the maintainers in accordance with needs of the community (i.e. large features, small features, or miscellaneous bug fixes).

Versioning

The BeeGFS CSI driver versioning is based on the semantic versioning scheme outlined at semver.org. According to this scheme, given a version number MAJOR.MINOR.PATCH, we increment the:

• MAJOR version when:
  • We make significant code changes beyond just a new feature.
  • Backwards incompatible changes are made.
• MINOR version when:
  • New driver features are added.
  • New versions of Kubernetes or BeeGFS are supported.
• PATCH version when: small bug or security fixes are needed in a more timely manner.

License

Apache License 2.0

Maintainers

• Joe McCormick (@iamjoemccormick).
• Eric Weber (@ejweber).
• Garrett Marks (@gmarks-ntap).
• Cole Krizek (@ckrizek).