What happened?
Webhook leader election timings are not configurable via Helm chart
Problem
The Spark Operator webhook enables leader election, but the Helm chart does not expose configuration for the leader election timing parameters (leaseDuration, renewDeadline, and retryPeriod).
In Kubernetes environments where API server requests may occasionally take longer to complete, the default leader election timings may not be sufficient. This can cause lease renewal requests to time out, resulting in leader election loss and webhook shutdown.
During leader election renewal, the webhook may encounter errors such as:
Failed to update lock optimistically: Client.Timeout exceeded while awaiting headers
error retrieving resource lock: context deadline exceeded
failed to renew lease: context deadline exceeded
Failed to start manager: leader election lost
Expected behavior
The Helm chart should expose the webhook leader election timing parameters so that operators can tune them according to their cluster characteristics while preserving the existing default behavior.
Example configuration:
webhook:
leaderElection:
enable: true
leaseDuration: 15s
renewDeadline: 10s
retryPeriod: 2s
Motivation
Making these parameters configurable improves the stability of the webhook in clusters with slower API servers or higher control-plane latency without changing the default behavior for existing users.
Reproduction Code
No response
Actual behavior
No response
Environment & Versions
- Kubernetes Version:
- Spark Operator Version:
- Apache Spark Version:
Additional context
No response
Impacted by this bug?
Give it a 👍 We prioritize the issues with most 👍
What happened?
Webhook leader election timings are not configurable via Helm chart
Problem
The Spark Operator webhook enables leader election, but the Helm chart does not expose configuration for the leader election timing parameters (leaseDuration, renewDeadline, and retryPeriod).
In Kubernetes environments where API server requests may occasionally take longer to complete, the default leader election timings may not be sufficient. This can cause lease renewal requests to time out, resulting in leader election loss and webhook shutdown.
During leader election renewal, the webhook may encounter errors such as:
Expected behavior
The Helm chart should expose the webhook leader election timing parameters so that operators can tune them according to their cluster characteristics while preserving the existing default behavior.
Example configuration:
Motivation
Making these parameters configurable improves the stability of the webhook in clusters with slower API servers or higher control-plane latency without changing the default behavior for existing users.
Reproduction Code
No response
Actual behavior
No response
Environment & Versions
Additional context
No response
Impacted by this bug?
Give it a 👍 We prioritize the issues with most 👍