The order of k8s resource when using spark-submit on k8s as follows:
<code>// pre-resource
kubernetesClient.resourceList(preKubernetesResources: _*).forceConflicts().serverSideApply()
// pod
kubernetesClient.pods().inNamespace(conf.namespace).resource(resolvedDriverPod).create()
// other resource (including configmap)
kubernetesClient.resourceList(otherKubernetesResources: _*).serverSideApply()
</code>
<code>// pre-resource
kubernetesClient.resourceList(preKubernetesResources: _*).forceConflicts().serverSideApply()
// pod
kubernetesClient.pods().inNamespace(conf.namespace).resource(resolvedDriverPod).create()
// other resource (including configmap)
kubernetesClient.resourceList(otherKubernetesResources: _*).serverSideApply()
</code>
// pre-resource
kubernetesClient.resourceList(preKubernetesResources: _*).forceConflicts().serverSideApply()
// pod
kubernetesClient.pods().inNamespace(conf.namespace).resource(resolvedDriverPod).create()
// other resource (including configmap)
kubernetesClient.resourceList(otherKubernetesResources: _*).serverSideApply()
Is the order suitable? Some resources such configmap is created after pod creation, and if those resources are not created successfully, the pod will keep stucking in ContainerCreating state and will never become Ready or auto clean
I have met the situation configmap is not created successfully, when I use spark operator, driver pod is created by calling spark-submit on k8s, oom will kill spark-submit process and configmap will not be created successfully
Please help, thanks!
A suitable resource creation order
New contributor
Tao Yang is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.