Che: We should use services hostname instead of ingresses for inter-components communications

Created on 17 Aug 2020  路  3Comments  路  Source: eclipse/che

Is your enhancement related to a problem? Please describe.

When wsmaster try to reach Keycloak it uses its external ingress/route hostname instead of using the internal service hostname. That makes sense only if Keycloak is external (the exception).

This is a problem because HTTP requests may need to follow a complicated and venturesome path going through proxies, firewalls etc...

This is NOT a wsmaster <--> keycloack specific problem. The plugin broker has the same issue when communicating with the registries and the wsmaster. And other Che components may have the same problem.

Describe the solution you'd like

All communications between Che services, by default, should use the cluster internal service hostname.

areoperator arewsmaster kinenhancement severitP1

Most helpful comment

Hello. @l0rd , @sleshchenko we are going to introduce cheCluster settings to enable internal network. Let's call it useInternalNetwork and it will be disabled by default. I think it will be safe way to start playing with this stuff.

All 3 comments

All communications between Che services, by default, should use the cluster internal service hostname.

I think it worths to declare that different communication should be configurable like Che and Keycloak are run in the same namespace and there is no reason to use external networking except external keycloak is used ( as is described in the issue ).
But Plugin Broker - Che Server communication should be configured according to cluster network policies, since those components are run in a different namespace and usually ( I think ) Che Server is not available for Plugin Broker via service hostname (internal network).

Che Server communication should be configured according to cluster network policies, since those components are run in a different namespace and usually ( I think ) Che Server is not available for Plugin Broker via service hostname (internal network).

@sleshchenko you are probably referring to the OpenShift Online cluster (che.osio) network policy that blocks communications across namespaces. That's a cluster with a peculiar configuration. By default communications across namespaces are enabled on both Kubernetes and OpenShift.

Hello. @l0rd , @sleshchenko we are going to introduce cheCluster settings to enable internal network. Let's call it useInternalNetwork and it will be disabled by default. I think it will be safe way to start playing with this stuff.

Was this page helpful?
0 / 5 - 0 ratings