Closed darkmuggle closed 5 months ago
Hi @darkmuggle. Thanks for your PR.
I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test
on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test
label.
I understand the commands that are listed here.
Hi @darkmuggle, thank you for the contribution! Can you please give some more context on what bug you are seeing and what configuration triggers it?
The original idea here was to use port 443 if an Ingress
is used to expose the front-proxy, since then access to it is not available on port 8443. Maybe the if condition here is faulty though and should be checking for that directly (and not for the service type).
@mjudeikis compare https://github.com/kcp-dev/helm-charts/blob/main/charts/kcp/templates/front-proxy-deployment.yaml#L18. The frontproxy service uses also 8443, not 443. So to make the service work as entry-point the deployment must use 8443 also in non-LB mode.
Conversely, we could change the service's port.
@mjudeikis compare https://github.com/kcp-dev/helm-charts/blob/main/charts/kcp/templates/front-proxy-deployment.yaml#L18. The frontproxy service uses also 8443, not 443. So to make the service work as entry-point the deployment must use 8443 also in non-LB mode.
But that is confusing to me because the EXTERNAL_HOSTNAME
variable is set to Helm values' .externalHostname
. That should be the external DNS name (so kcp.beckers.dev
) usually and not the kcp-front-proxy.kcp.svc.cluster.local
service DNS name.
For me there are two deployment scenarios:
LoadBalancer
service type. Then I get an LB from e.g. AWS, I set a CNAME on kcp.beckers.dev
and my kcp front proxy endpoint is available as kcp.beckers.dev:8443
.kcp.beckers.dev:443
.As far as I understand, the point made is that there is a third option, where you don't expose kcp at all and just make it available via its front-proxy Service
endpoint within the cluster. Is that correct? If so, we need to refine this PR because it will break scenario (1).
To verify my understanding: You are setting .externalHostname=kcp-front-proxy.kcp.svc.cluster.local
?
Right, kcp is installed in-cluster and only accessed from there.
To verify my understanding: You are setting .externalHostname=kcp-front-proxy.kcp.svc.cluster.local?
yes
Shouldn't this be "templatable destination port on service object:?
targetPort: "{{ if eq .Values.kcpFrontProxy.service.type "LoadBalancer" }}8443{{ else }}443{{- end }}"
? I think @embik is right, and this will break case he mentions.
/ok-to-test
LGTM label has been added.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: embik
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Before this PR, the external port of the kcp server is set to 8443 for a
LoadBalancer
service type and 443 otherwise. The later is the case where an ingress is expected to be in-front of kcp. But when the actual usecase is to talk to the frontproxy directly via the service, this logic is wrong. Adding.Values.externalPort
allows the customize the port, overriding upper logic.