[
https://issues.apache.org/jira/browse/SPARK-57466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Attila Mészáros updated SPARK-57466:
------------------------------------
Description:
Add a second option, for mount-based source for dynamic configuration overrides
and makes the dynamic-config mechanism pluggable, while retaining the existing
ConfigMap-informer behavior for backwards compatibility.
A new config option `spark.kubernetes.operator.dynamicConfig.source` selects
the source:
- **`configMap`** (default) — the existing behavior: a dedicated `Operator`
runs `SparkOperatorConfigMapReconciler`, watching a ConfigMap via a Kubernetes
informer. Requires RBAC to read ConfigMaps.
- **`file`** — a new `DynamicConfigMonitor` periodically reloads a properties
file mounted from a ConfigMap volume, requiring no extra RBAC.
Both paths funnel through the same `SparkOperatorConfManager.refresh(...)` +
watched-namespace update logic, so runtime behavior is identical once overrides
are applied.
was:
Reworks the dynamic-config feature so the operator no longer runs a dedicated
{{Operator}} instance with a ConfigMap controller. Instead, the dynamic-config
ConfigMap is mounted into the operator pod as a volume, and a new
{{DynamicConfigMonitor}} periodically re-reads the properties file from disk.
When the file content changes, {{SparkOperatorConfManager}} is refreshed and
the watched-namespaces updater is invoked, exactly as the previous
{{SparkOperatorConfigMapReconciler}} did.
The controller-based approach required the operator to hold cluster/namespace
RBAC on ConfigMaps and ran a second JOSDK controller purely to watch a single
ConfigMap. Mounting the ConfigMap directly is simpler, removes the RBAC
requirement,
and avoids the second controller failure modes. The kubelet already propagates
ConfigMap edits to mounted volumes, so polling the file gives equivalent
behavior with much less moving machinery.
With the current design it might be also possible with only {{post}} permission
to create a ConfigMap with the target labels that would override the current
configurations, this removed this possible attack surface.
> Replace dynamic-config controller with mounted-ConfigMap file watcher
> ---------------------------------------------------------------------
>
> Key: SPARK-57466
> URL: https://issues.apache.org/jira/browse/SPARK-57466
> Project: Spark
> Issue Type: Improvement
> Components: Kubernetes
> Affects Versions: kubernetes-operator-1.0.0
> Reporter: Attila Mészáros
> Priority: Major
> Labels: pull-request-available
>
> Add a second option, for mount-based source for dynamic configuration
> overrides and makes the dynamic-config mechanism pluggable, while retaining
> the existing ConfigMap-informer behavior for backwards compatibility.
> A new config option `spark.kubernetes.operator.dynamicConfig.source`
> selects the source:
> - **`configMap`** (default) — the existing behavior: a dedicated `Operator`
> runs `SparkOperatorConfigMapReconciler`, watching a ConfigMap via a
> Kubernetes informer. Requires RBAC to read ConfigMaps.
> - **`file`** — a new `DynamicConfigMonitor` periodically reloads a
> properties file mounted from a ConfigMap volume, requiring no extra RBAC.
> Both paths funnel through the same `SparkOperatorConfManager.refresh(...)`
> + watched-namespace update logic, so runtime behavior is identical once
> overrides are applied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
