Separate StatefulSet Templates for Arbiters and Data Members

[sina-grz]

Separate StatefulSet Templates for Arbiters and Data Members

Problem Description

Currently, the MongoDB Kubernetes Operator uses the same StatefulSet template for both arbiters and data members. This design causes significant resource waste because:

• Storage Waste: Arbiters don't store data but receive the same PVC (Persistent Volume Claim) template as data members
• Resource Waste: Arbiters have minimal CPU and memory requirements compared to data members, but inherit the same resource requests and limits
• Operational Inefficiency: This leads to unnecessary infrastructure costs and resource allocation

---

Current Behavior

Both arbiters and data members use identical StatefulSet configurations, including:

• PVC templates for persistent storage
• CPU and memory resource requests/limits
• Container specifications

---

Proposed Solutions

Solution 1: Separate StatefulSet Templates in CR Definition

Modify the Custom Resource (CR) definition to allow separate StatefulSet configurations:

spec:
  members: 
    count: 3
    statefulSet:
      spec:
        # Member-specific configuration
        volumeClaimTemplates: [...]
        template:
          spec:
            containers:
              resources:
                requests:
                  memory: "4Gi"
                  cpu: "1000m"
  arbiters: 
    count: 1
    statefulSet:
      spec:
        # Arbiter-specific configuration (minimal resources)
        template:
          spec:
            containers:
              resources:
                requests:
                  memory: "512Mi"
                  cpu: "100m" 

Pros:

Full customization control for users
Clear separation of concerns
Explicit resource allocation

Cons:

Breaking change to CR API
Increased configuration complexity
Requires migration path for existing deployments

Solution 2: Context-Aware Default Templates

Modify the BuildMongoDBReplicaSetStatefulSetModificationFunction to accept an isArbiter parameter and apply different default templates based on the StatefulSet's purpose.

Implementation:

Pass isArbiter boolean to the build function
Apply arbiter-optimized defaults (no PVC, minimal resources) when isArbiter=true
Maintain current behavior for data members
Keep spec.statefulSet for member customization only

Pros:

Non-breaking change
Automatic resource optimization
Simpler user configuration
Backward compatibility

Cons:

Less granular control for arbiter customization
Fixed arbiter template

Notes:

I have implemented the solution 2 in this branch

[mehrdadbn9]

We’ve run into this same problem in our environment as well.

• Arbiters are currently receiving PVCs and resource requests identical to data members, which results in wasted storage .

• This leads to unnecessary infrastructure costs for us too.

We’re interested in a solution that separates arbiter StatefulSet templates from data members (e.g., no PVCs and minimal resources for arbiters).

[ZebcoWeb]

I have the same issue. We hope a solution will be found.