Piraeus Operator

To understand the architecture and operational logic of Piraeus Datastore, refer to the following conceptual guides:

• Understanding Piraeus Datastore Components: Provides a short introduction to every individual component within the Piraeus Datastore ecosystem.
• How Piraeus Operator Selects Image Versions for Deployed Resources: Explains the image configuration format, the selection process used by the operator, and how to influence or override image versions.
• Satellite Deletion Policies: Details the various deletion policies available for Satellites in Piraeus Datastore.

The DRBD Module Loader is a component responsible for making the DRBD kernel module available and loading other essential kernel modules required for Piraeus functionality.

When active, it attempts to load the following modules if they are available on the host:

The linstor-csi-nfs-server Pods provide ReadWriteMany (RWX) support by exporting LINSTOR volumes via NFS.

Key Features:

• Deployment: Deployed as a DaemonSet on every node by default.
• High Availability: Uses DRBD Reactor to ensure high availability of NFS exports in case of node failures.
• Placement: NFS exports can run on any node that currently holds a replica of the volume.

The ha-controller is designed to accelerate the failover process for stateful workloads using Piraeus storage.

Operation:

• It is deployed on every node in the cluster.
• It listens for DRBD® events to detect storage failures on other nodes.
• When a failure is detected, it automatically evicts Pods that are using the inaccessible storage, allowing Kubernetes to reschedule them elsewhere.

The Piraeus Operator uses a default configuration to select component images, typically using the latest versions available at the time of the Operator's release. This configuration is stored in a ConfigMap named piraeus-operator-image-config and contains two primary YAML documents:

1. 0_piraeus_datastore_images.yaml: Contains image configurations for all Piraeus Datastore components.
2. 0_sig_storage_images.yaml: Contains image configurations for Kubernetes CSI components.

Images are constructed using a base registry, a component image name, and either a tag or a digest (which takes precedence).

The piraeus-operator-gencert component manages the TLS lifecycle for the Piraeus Operator. It creates and maintains the TLS key and certificate required for the Operator to serve its validation endpoint for custom resources.

Key details:

• TLS Secret: The generated certificate is stored in a Kubernetes secret named webhook-server-cert. This secret is a prerequisite for starting the piraeus-operator Pod.
• Webhook Management: This component also keeps the ValidatingWebhookConfiguration for the Piraeus Operator up-to-date.
• Dependency Reduction: This component was introduced to remove the dependency on cert-manager for Piraeus deployments.

Consistency groups allow you to combine multiple volumes into a single LINSTOR® resource. This ensures that replicas and snapshots always present a consistent view of the entire set of volumes.

By default, every PersistentVolume is a separate LINSTOR resource replicated independently. This can lead to data inconsistency during fail-overs if one volume is up-to-date while another is outdated.

Key benefits of Consistency Groups:

• Atomic Replication: All PersistentVolumeClaims sharing a linstor.csi.linbit.com/consistency-group label share one replication connection and one replication state.
• Consistent Placement: All members of a group are always placed on the same set of nodes.
• Atomic Snapshots: Snapshots of group members are captured simultaneously as a single LINSTOR snapshot, ensuring every volume is at the same point in time.

Piraeus Datastore automatically detects ClusterAPI by looking for cluster.x-k8s.io/machine and cluster.x-k8s.io/cluster-namespace annotations.

When using the Evacuate policy, Piraeus uses Machine deletion hooks to ensure the Machine remains running until all LINSTOR resources are safely evacuated. This process respects the LinstorCluster.spec.maxConcurrentEvacuations setting; if the limit is reached, the Machine's pre-drain hook remains in place, preventing ClusterAPI from proceeding with the node removal until an evacuation slot becomes available.

The linstor-satellite is a stateless service that runs on every node as a DaemonSet. It acts as the local configuration agent for LINSTOR managed storage on that specific node.

Key Operational Details:

• Privileged Access: Satellites are deployed as privileged containers to interact directly with the host operating system.
• Network Namespace: Any DRBD® device inherits the network namespace of the Satellite Pod. If Satellites are not using host networking, DRBD will be unable to replicate data without a running Satellite Pod.
• UTS Namespace: The Satellite process is spawned in a separate UTS namespace. This ensures that DRBD tools always report the Kubernetes node name as the hostname, even if the Pod name is different. This is transparent to users; running kubectl exec into a satellite Pod allows you to run drbdadm commands as expected.