Subscription config should support overriding operator deployment replica count

[jsenko]

Problem

OLM's Subscription spec.config allows users to override several aspects of an operator's Deployment — env, envFrom, volumes, volumeMounts, tolerations, resources, nodeSelector, and affinity — and these overrides persist across operator upgrades.

However, there is no way to override the replica count of an operator Deployment through the Subscription. The replica count is defined in the CSV's spec.install.spec.deployments[].spec.replicas, and the only way to change it is by patching the CSV directly. CSV patches are lost whenever OLM installs a new CSV version during an operator upgrade, requiring users to re-apply the patch after every upgrade.

This makes it difficult for users to run operators in a high-availability configuration (multiple replicas with leader election) when installed via OLM, without the operator vendor shipping replicas > 1 as the default in the CSV — which increases resource usage for all users, including those who don't need HA.

Use case

We maintain a Kubernetes operator that supports leader election via the coordination.k8s.io/v1 Lease API. To achieve HA, users need to increase the replica count. For users installing via the install file (plain YAML), this is straightforward — they edit the Deployment directly.

For OLM-managed installations, users have no durable way to set the replica count. Patching the CSV works temporarily but is reverted on upgrade. The Subscription config supports affinity (useful for pod anti-affinity to spread replicas across nodes) and env (useful for configuring leader election parameters), but not replicas — making the HA setup incomplete.

Current workarounds

• Patch the CSV after each install/upgrade. This is fragile and easy to forget.
• Ship replicas > 1 in the CSV by default. This works but forces the resource cost of HA on all users.
• Provide a helper script that re-applies the CSV patch after upgrades. This adds operational burden.

Other operators face the same limitation. For example, Strimzi documents leader election and multiple replicas but accepts the CSV-patch-on-upgrade limitation for OLM installs. The Operator SDK has an open discussion about better documenting the HA use case with leader election, but the underlying platform gap remains.

References

• Subscription config design doc — lists supported fields (no replicas)
• OLM Subscription config bug #1912 — related issue about Subscription config overwriting CSV values
• Operator SDK HA discussion #6612 — request for better leader election + multiple replicas documentation
• Strimzi leader election — example of another operator dealing with the same limitation
• OLM affinity override docs — shows that Subscription config can override pod-level settings, but not Deployment-level ones like replicas

[jsenko]

This points to a deeper issue of lack of configurability for operators. Operands have CRDs, but operators do not have similar flexibility. There could be several solutions:

• Add the replicas field to Subscription. Straightforward, but only a surface-level solution.
• Support full PodTemplateSpec in Subscription. This might be an overkill and there are some problems with this, but it would be a more permanent solution.
• CRD-based operator configuration. OLM could define a CRD for operator configuration. Operators then define a CR describing which configuration options they support and package it within the bundle. OLM watches it and sends a requests to the operator which returns how it's Depoyment (or other resource) should change. Basically this would allow the operator to dynamically modify it's own Deployment. Advantage would be that Kubernetes console can present these operator-specific options in the UI. Disadvantage is that it's pretty complex.