2 Replies Latest reply on Sep 4, 2018 2:26 PM by Cheng Fang

    Integrate JBeret with OpenShift / Kubernetes Jobs Capability

    Cheng Fang Master

      Kubernetes and OpenShift contain jobs and job scheduling API, to facilitate batch processing in cloud platforms.  At a high level, it beans a similarity to JSR-352, the batch spec in that both are trying to define a standard for batch processing.  It also shows importance of batch processing in the era of cloud computing and containerized microservices.  How do we leverage Kubernetes and OpenShift jobs api to better support JBeret in developing cloud-native batch processing applications?  I'd like to share what I've been thinking of and would love to get your thoughts on this topic.


      1,  as a launcher for running batch applications written as standalone Java application.  It roughtly involves the following steps:


      1.1, build standalone Java application as a uber jar (fat jar);

      1.2, deploy it to OpenShift, based on image stream Red Hat Enterprise Linux (or CentOS) + Red Hat OpenJDK, which will create an application image inside OpenShift;

      1.3, from OpenShift command line (oc), create a job (in Kubernetes term) which will start the job execution in OpenShift

      1.4, after the job execution ends, the container is also terminated.


      2, as a job scheduler for scheduling delayed or recurring executions of standalone Java application.


      Since batch spec, as of version 1.0, does not define a standard scheduling api, the jobs and scheduling api in OpenShift can be a great supplement to the existing JBeret-specific scheduling capability.  The steps involved are similar to the above.  The oc command to schedule the job execution (cron jobs) is slightly different.


      For more details, see JBERET-349 (Integrate JBeret with openshift scheduled job capability).  I've created a sample batch application, jberet-simple, to experiment with these scenarios, and you are welcome to clone it and try it out.


      Feel free to leave comments in the JIRA issue or in this thread.