Description of problem:
OCP3.x supported changing the API port.
Certain environments and situations (customer policy, etc) mean that any tool that doesn't talk across a standard port (80/443) may be blocked. In that case, anything that needs to access the API on 6443 would be blocked.
This would break the CLI, IDE, and any RESTful API integrations.
The web console is available over 443, and one could get access to a CLI running "inside" the OCP environment, however that still leaves IDE and API integrations broken.
This looks like a duplicate of 1663453. Is there any new information that needs to be considered or can this be closed?
This is not a dupe of 1663453
1663453 says "put the API port on 8443".
This BZ is "make the API port configurable".
Okay, maybe not a dup, but it shares the same conclusion:
> We've decided to stick with 6443 for the API. We'll make a point to educate customers about the port change.
Unless there is a compelling reason to do so, we should not allow the API port to be customized.
Not allowing for the customization of the API port means that there are some potential users who will not be able to access the API for whatever reason.
If we don't allow for moving the API port, then we likely need to document and support some type of proxy solution in front of the API.
I'm not convinced. These potential users would have to be smart enough to block access to 6443 but not smart enough to provide a proxy. That seems very unlikely and since we don't have any concrete examples, I'm going to close this. We can revisit this if it proves to be problematic in the future.
Can we understand why putting the api on a non-standard SSL port is necessary or useful in the first place? In OpenShift 3.x, we used 8443 for the API because it was possible/supported to run the router on the control plane, and we needed to avoid port conflicts on the host. But in OpenShift 4, we require dedicated control plane hosts and taint the those servers so nothing else gets scheduled there. There are no port conlficts to protect against. Why wouldn't we run the api on 443 by default?
There is a growing use case for edge clusters, which don't have any worker nodes. In these environments, the port conflict does exist.
Adding my perspective from a hosted perspective (OpenShift Dedicated/OpenShift Online). Most of these customer's are much less technical, which is why they're investing in a hosted solution. Typically there are corporate policies put in place at a higher level, that the hosted customers (typically just developers) don't have any chance of being to change or workaround with a proxy.
Because this limitation exists in the installer, we have *no way* of supporting these customers.
We already have 1 concrete example of a customer being blocked by this, and OSD on v4 is still fairly small. This will absolutely be a hinderance to the expansion and adoption of our hosted offerings.