Details
-
Feature Request
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
False
-
None
-
False
-
Not Selected
-
0
-
0%
Description
| What are you experiencing? What are you expecting to happen? Given a StatefulSet defining a Persistent Volume Claim template pvct-v and two container template definitions cont-a and cont-b, it runs all three in a pod whereby each time the StatefulSet is scaled out a new claim is created from pvct-v and when new containers are scheduled from cont-a and cont-b they are bound (as each other's sidecars) to the new pvct-v claim (if each container is configured to mount it) and the three make up a new replica pod. The difference with Deployments is that there is a separate ReplicaSet object managing the replica pods for the Deployment, and also Deployments cannot have volumeClaimTemplates like pvct-v in the example above, whereas StatefulSets directly own the pods they scale horizontally and their respective volume claims. How can the StatefulSet be defined to also contain a CronJob (template/definition) to run in a container defined as cont-c which also scales out (or in) with the stateful set - that is, when a new replica pod is created by the stateful set with a new claim from pvct-v and respectively a new corresponding PV bound and mounted to the new instances of the cont-a and cont-b containers, a new instance of the CronJob is scheduled to run in the same new pod by temporarily spinning up a container cont-c, also with access to the shared PV from pvct-v, mount the volume, execute the scheduled script and stop cont-c while the script is not running? Define the value or impact to you or the business Need to scale scheduled jobs with the pods of a StatefulSet in order to access the volume bound to each pod's (also horizontally scaled) shared PVC |
Regarding CronJobs being completely separate objects in upstream k8s from StatefulSets, while I accept that, PVCs are also completely separate objects from Deployments - but there is a valid use case for volume claims dynamically scaling along with pods and this is what a StatefulSet does in a way - it is somewhat similar to a Deployment (or a "StatelessSet" if you will) but with volumeClaimTemplates in addition to the container templates to go with a scalable "prototype" of a pod. Similarly, Secrets and ConfigMaps are strictly namespace-scoped objects in upstream k8s - but Red Hat has seen a valid use case for SharedSecret and SharedConfigMap and is working on a future implementation (it is already in TP and hopefully in GA soon).
I believe scaling job templates (such as CronJobs) and instantiating new (dynamically named) jobs relative to scaled pods (under Deployments/ReplicaSets or under StatefulSets) is another valid use case - just like PVCs are normally "handcrafted" at the Project scope - but StatefulSets streamline this process and tie it to the horizontal scaling of a set of pods. Adding jobs to volumes is another "natural" extension to the scope of a StatefulSet relative to that of a Deployment. Therefore please consider raising this functionality as a Request for Enhancement - initially as a quality differentiator for OpenShift (relative to "vanilla k8s") and eventually why not upstream as well?
