How can we route a request to every pod under a kubernetes service on Openshift?

1/21/2017

We are building a Jboss BRMS application with two microservices in spring-boot, one for rule generation (SRV1) and one for rule execution (SRV2). The idea is to generate the rules using the generation microservice (SRV1) and persist them in the database with versioning. The next part of the process is having the execution microservice load these persisted rules into each pods memory by querying the information from the shared database.

There are two following scenarios when this should happen :

  • When the rule execution service pod/pods starts up, it queries the db for the lastest version and every pod running the execution application loads those rules from the shared db.

  • The second senario is we manually want to trigger the loading of a specific version of rules on every pod running the execution application preferably via a rest call.

Which is where the problem lies!

Whenever we try and issue a rest request to the api, since it is load balanced under a kubernetes service, the request hits only one of the pods and the rest of them do not load the specific rules.

Is there a programatic or design change that may help us achieve that or is there any other way we construct our application to achieve a capability to load a certain version of rules on all pods serving the execution microservice.

-- ahjashish
application-design
kubernetes
microservices
openshift-enterprise
restful-architecture

1 Answer

3/13/2017

The second senario is we manually want to trigger the loading of a specific version of rules on every pod running the execution application preferably via a rest call.

What about using Rolling Updates? When you want to change the version of rules to be fetched within all execution pods, tell OpenShift to do rolling update which kills/starts all your pods one by one until all pods are on the new version, thus, they fetch the specific version of rules at the startup. The trigger of Rolling Updates and the way you define the version resolution is up to you. For instance: Have an ENV var within a pod that defines the version of rules that are going to be fetched from db, then change the ENV var to a new value and perform Rollling Updates. At the end, you should end up with new set of pods, all of them fetching the version rules based on the new value of the ENV var you set.

-- Radek Koubsky
Source: StackOverflow