Enable to set che.api.internal .

[monaka]

What does this PR do?

Enables to set che.api.internal that is used by in-container pods.
This property will be passed to pods as the environment variable named CHE_API_INTERNAL in pods.
Almost all users don't need to care about this because the default value is set.

che.api is bound to the environment variable CHE_API and CHE_API_EXTERNAL.
It is same as the current implementation.

Note that che.api.external have not existed until now. And it won't provided in the future also.

What issues does this PR fix or reference?

• An alternative of Use properties che.api.{external,internal} if exist. #13774 .
• Will fix Can't set CHE_API_INTERNAL. #15663 .

[skabashnyuk]

Why do we need this change (I understand that we can't set it from the configuration, I mean what are the user-story behind it)? How it would be used? Should we document that?

[monaka]

@skabashnyuk At least it's strange that CHE_API is from CheApiInternalEnvVarProvider.
It should be bound to CheApiExternalEnvVarProvider. This is not a user-story but a code context.

And the viewpoint of processes in containers, there is no merit to access API via Ingress and external load-balancer. Actually they will suppress performance, decrease reliability.

Of course end users must access API via Ingress because they are out of K8s/OpenShift cluster.
So CHE_API should be provided with the public domain name.
At the same, it is also required URL with local DNS name like http://che-server:8080.

Referring to code of Che-Theia, it supports CHE_API_INTERNAL. But it is not used with effective as WsMaster doesn't care it.

[amisevsk]

I support the addition of internal communication as an option in Che, particularly because I've run into use cases where a cluster interferes with a cluster-internal pod communicating with an external-facing endpoint. However there are a few issues:

• Che is not built with internal communication in mind, so many components don't distinguish when external vs internal API endpoints should be used
• It's a documentation and setup burden, as some configurations of OpenShift/Kubernetes don't allow for inter-namespace communication via service.
• I don't think maintaining support for equivalent env vars CHE_API and CHE_API_EXTERNAL is a good idea -- one of these should be removed.

Even so, I think this is a good addition.

[amisevsk]

Javadoc for this class should be updated ("URL of Che API" is unclear if we're supporting both public endpoint and internal service).

[monaka]

It's a documentation and setup burden, as some configurations of OpenShift/Kubernetes don't allow for inter-namespace communication via service.

@amisevsk Nice catch.
It will be required to provide NetworkPolicies in some strict K8s/OpenShift clusters.
And I suppose there can be two level supports.

1. Making suggestion to set che.api.internal the same value as che.api.
2. Providing NetworkPolicy template to the users.

In transitional, plan 1. will be enough, IMO. Plan 1. will work same as the current Che.
Of course plan 2. is best.

[monaka]

I created new PR #15697 similar to this PR. I think that will be more acceptable than this.
After merged that to the master, I'll rebase here.

[che-bot]

Can one of the admins verify this patch?

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.