The 1.2.0 version of the BeeGFS CSI driver is here! It brings a number of small enhancements, progress towards supporting a new container orchestrator, and a huge new feature. Some highlights include:
- Support for newer versions of Kubernetes, BeeGFS, and now Red Hat OpenShift,
- Support for BeeGFS mount options in Kubernetes Persistent Volumes and Storage Classes,
- Documentation and examples for deploying the driver to Hashicorp Nomad (no official support yet),
- A brand new BeeGFS CSI driver operator designed for integration with Operator Lifecycle Manager (OLM) and Red Hat OpenShift.
As always, consult the changelog for a complete description of changes and improvements.
Operators and the Operator Pattern
The operator pattern is a fairly common means of deploying and managing applications in Kubernetes. The idea is for a software “operator” with deep systemic knowledge to manage a set of services in place of a human “operator”. Even a relatively simple application like the BeeGFS CSI driver requires the following Kubernetes objects to run correctly:
- A Stateful Set to ensure the CSI controller service runs on an appropriate node with correct permissions, volume access, and arguments,
- A Daemon Set to ensure the CSI node service runs on all appropriate nodes with correct permissions, volume access, and arguments,
- Service Accounts, Roles, and Role Bindings to give these services limited access to the Kubernetes API,
- A CSI Driver object to inform Kubernetes about the driver and its capabilities.
The new BeeGFS CSI driver operator (like all Kubernetes operators) consists of two components:
- A custom controller capable of deploying, updating, and deleting the objects listed above,
- A Custom Resource, which allows for the declarative configuration of the driver as a whole.
An administrator creates or modifies the Custom Resource and applies it to the cluster. In response, the custom controller reads the Custom Resource and deploys, updates, or deletes the driver objects it owns. This pattern has the effect of simplifying management for the administrator. They can modify the Custom Resource and/or update the operator and expect appropriate changes to be made to the deployed objects.
Operator Lifecycle Manager, OperatorHub, and OpenShift
For most basic Kubernetes clusters, we will continue to support and recommend BeeGFS CSI driver deployment via Kustomize manifests. While the operator CAN replace Kustomize for deploying the BeeGFS CSI driver in a typical cluster, it is itself software that must be installed and managed with Kustomize. This doesn’t do much to lower the barrier of entry for administrators.
The main goal of the operator is to simplify deployment in Red Hat OpenShift clusters and in non-OpenShift clusters equipped with Operator Lifecycle Manager (OLM). OLM “extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators on a cluster.” Operators in OLM-equipped clusters are first-class citizens. After an administrator declares the intent to “subscribe” to an operator, OLM automatically installs the operator and its Custom Resources on a cluster. If a new version of the operator is released, OLM can (optionally) automatically upgrade the operator, which in turn updates its owned objects. In addition, operators, including the BeeGFS CSI driver operator, can be made available on OperatorHub. OperatorHub is a community-maintained registry that makes it easy for administrators to discover and subscribe to operators for a wide variety of applications.
Today, BeeGFS is especially popular on-premises, and Red Hat OpenShift is likely the most widely used on-premises Kubernetes distribution. Operators are everywhere in OpenShift. Even its core services are managed by them. Also, OLM is a key component of OpenShift and OperatorHub is baked right into the web console. As we will demonstrate, this makes installing the BeeGFS CSI driver as simple as a few clicks.
Installing the BeeGFS CSI driver in OpenShift with the operator
First, a few caveats:
- Today, all nodes that will run the driver must have the BeeGFS client packages preinstalled.
- The BeeGFS client packages are NOT supported on Red Hat CoreOS (RHCOS), which is the default for OpenShift master and worker nodes. However, OpenShift also allows Red Hat Enterprise Linux (RHEL) nodes, and RHEL runs BeeGFS well.
To install the operator, in the web console of an OpenShift 4.8 cluster:
- Navigate to the OperatorHub pane.
- Search for the BeeGFS CSI driver.
- Click Install.
- Accept the defaults (including the default beegfs-csi namespace).
- Click Install.
To install the driver using the operator, in the web console of an OpenShift 4.8 cluster:
- Navigate to the Installed Operators pane.
- Select the installed BeeGFS CSI driver operator.
- Select the BeeGFS Driver API tab.
- Click Create BeegfsDriver.
- Modify the BeegfsDriver Custom Resource. In this step, you can adjust how the driver’s Kubernetes objects are deployed or add any of the BeeGFS client configuration the driver has supported since its initial release. Make adjustments quickly and easily in Form view or explore the schema and modify the YAML directly in YAML view.
- Click Create.
Installation really is that simple! Your cluster is now ready to handle BeeGFS Storage Classes, Persistent Volumes, and Persistent Volume Claims. If you accepted the default operator installation parameters, the operator (and the driver) will update seamlessly and automatically when new versions are released.
Of course, we’ve included a more complete set of instructions, including instructions for using the operator outside of OpenShift, in the project.
The operator is an exciting new addition to the BeeGFS CSI driver and is the culmination of quite a bit of work! Next up will be a 1.2.1 release that should address minor issues while we continue to plan for some interesting new features in 1.3.0 and beyond. Until then, feel free to open an issue on our GitHub page, reach out to the core development team at email@example.com, or explore other NetApp AI and HPC solutions at netapp.com/ai.