HwangDongJun commented on code in PR #58187:
URL: https://github.com/apache/spark/pull/58187#discussion_r4163441250
##########
resource-managers/kubernetes/core/src/main/scala/org/apache/spark/deploy/k8s/submit/KubernetesClientApplication.scala:
##########
@@ -136,43 +188,75 @@ private[spark] class Client(
val driverPodName = resolvedDriverPod.getMetadata.getName
// setup resources before pod creation
- val preKubernetesResources =
resolvedDriverSpec.driverPreKubernetesResources
- try {
- kubernetesClient.resourceList(preKubernetesResources:
_*).forceConflicts().serverSideApply()
- } catch {
- case NonFatal(e) =>
- logError("Please check \"kubectl auth can-i create [resource]\"
first." +
- " It should be yes. And please also check your feature step
implementation.")
- kubernetesClient.resourceList(preKubernetesResources: _*).delete()
- throw e
- }
+ // SPARK-38079: the driver's own base config map (mounted as
SPARK_CONF_VOLUME_DRIVER
+ // above) must also be created before the pod itself, to avoid a
"configmap ... not
+ // found" mount race between the driver pod and the config map it depends
on.
+ val preKubernetesResources =
resolvedDriverSpec.driverPreKubernetesResources ++ Seq(configMap)
+
+ // SPARK-38079: some of the pre-resources above (e.g. the Kerberos
keytab/delegation token
+ // secrets, the driver Kubernetes credentials secret) carry credentials.
They are created
+ // here without an owner reference -- the owner reference is only added
once the driver pod
+ // exists (see "Refresh all pre-resources' owner references" below), since
Kubernetes owner
+ // references require the owner's UID, which does not exist before the pod
is created. If
+ // this process is terminated abruptly in that window (e.g. Ctrl-C,
SIGTERM, or a fatal JVM
+ // error), the pre-resources would otherwise be silently orphaned in the
namespace forever,
+ // since Kubernetes only garbage-collects via owner references. This
shutdown hook makes a
+ // best-effort attempt to delete them (and the driver pod, if this
submission created it) in
+ // that case. It is a no-op -- and removed entirely, see the `finally`
below -- once the
+ // owner-reference refresh has completed; from that point on the existing
owner references
+ // make normal Kubernetes garbage collection sufficient, and e.g. Ctrl-C
while waiting for
+ // the application to complete must keep today's behavior of just
detaching.
+ val preResourcesApplied = new AtomicBoolean(false)
+ val podCreatedByUs = new AtomicBoolean(false)
+ val cleanupHookRef = shutdownHookOps.addHook(() =>
cleanupOrphanedPreResources(
+ preKubernetesResources, driverPodName, preResourcesApplied.get(),
podCreatedByUs.get()))
var watch: Watch = null
var createdDriverPod: Pod = null
try {
- createdDriverPod =
-
kubernetesClient.pods().inNamespace(conf.namespace).resource(resolvedDriverPod).create()
- } catch {
- case NonFatal(e) =>
- kubernetesClient.resourceList(preKubernetesResources: _*).delete()
- logError("Please check \"kubectl auth can-i create pod\" first. It
should be yes.")
- throw e
- }
+ try {
+ kubernetesClient.resourceList(preKubernetesResources:
_*).forceConflicts().serverSideApply()
+ preResourcesApplied.set(true)
+ } catch {
+ case NonFatal(e) =>
+ logError("Please check \"kubectl auth can-i create [resource]\"
first." +
+ " It should be yes. And please also check your feature step
implementation.")
+ kubernetesClient.resourceList(preKubernetesResources: _*).delete()
Review Comment:
`configMapNameDriver` is now a `def`, not a `val` (see
`KubernetesClientUtils.scala`):
- Each call re-evaluates `KubernetesUtils.uniqueID()`, so every submission
from the same JVM gets its own name instead of sharing one. The scenario you
describe — app B's failed apply deleting app A's live ConfigMap by name —
requires two submissions to land on the same name, which can no longer happen
within a single JVM.
- `configMapNameExecutor` is left as a `val` on purpose: it's set up once by
`KubernetesClusterSchedulerBackend` and then read independently by
`BasicExecutorFeatureStep` for every executor of that application, so every
call must agree on the same name. `configMapNameDriver` has no such requirement
— it's read once per submission into a local `val` reused for that submission.
Added a test asserting `configMapNameDriver` differs across calls while
`configMapNameExecutor` stays the same, to pin this down
(`KubernetesClientUtilsSuite`).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
