[WFLY-18415] Support internal EJB client access to deployments on Ope…

[tadamski]

…nShift over HTTP

Please don't merge. This analysis is in initial state and the PR was open to take advantage of github in the design discussions.

[rachmatowicz]

@tadamski if you could convert this to a draft pull request, it wouldn't be merged until out of draft state.

Just FYI, mod-cluster is not (and is not currently planned to be) suitable for deployment in OpenShift, asked Rado specifically about this. The recommendation is to use a cloud native load balancer, such as a service.

[rachmatowicz]

Also, you mention stateful sets and persistent IP addresses: stateful sets don't provide stable IP addresses, but only stable hostnames (e.g. web-0, web-1, web-2): https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#stable-network-id

[rachmatowicz]

My view: if we assume that the deployment is via the Wildfly operator and that the EJB client application makes use of the "http" protocol (and so the wildfly-http-client library), all that is needed is an intermediary service between the client and the deployment which understands cookie based affinity management. If OpenShift provides such a service then that could be used, otherwise a custom cloud-native service could be written and deployed via the operator.

[rachmatowicz]

This note about internal load balancers may be of interest: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer