You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hit an issue the other day when trying to setup up two knative-services in two different namespaces with domainMapping for two different subdomains of the same domain where the domainMapping references a wildcarded cert for that domain. This resulted in one service working with the custom domain however the second does not. Note that while the domain being mapped was not a wildcard the cert being used was.
I could be wrong or misunderstanding how knative/net-istio works since I'm relatively new to knative-serving but I think this is because net-istio generates multiple wildcarded TLS gateways both referecing the *.foo.com domain on port 443. The first gateway to be created gets applied to the ingress-gateway and works. However the second does not get applied and is not visable as a listener in the ingress-gateway config, because the host port pair is already being used for the previously created wildcarded gateway. This breaks traffic for the second service, because the knative-serving virtualServices routes reference the gateway the traffic has to pass through as part of the route's matching criteria and that means there is no way of routing any traffic the second service on the custom domain, sinces it matches the first gateways wildcarded listener but then there is no route because there are no virtualServices with routes for that host bound to the gateway for the first service.
Looking through the code it looks like multiple wildcarded gateways get created intentionally. When reconciling the knative-ingress the referenced secrets get catigorised based on if they contain a wildcarded cert or not and if is wildcarded then a wildcard gateway gets created. I think the problem here lies with the fact that even if the ingress has a fully specified name e.g. bar.foo.com the generated gateway created use the decoded infro from the cert and creates a wildcarded gateway.
Is there a reason to not always use the host from the knative-ingress regardless of what is in the cert info? If the host was not wildcarded (link my instance above) I think this would have generated a working configuration with a gateway for each fully qualified domain served using the wildcarded cert.
The text was updated successfully, but these errors were encountered:
HI guys,
I hit an issue the other day when trying to setup up two knative-services in two different namespaces with
domainMapping
for two different subdomains of the same domain where thedomainMapping
references a wildcarded cert for that domain. This resulted in one service working with the custom domain however the second does not. Note that while the domain being mapped was not a wildcard the cert being used was.I could be wrong or misunderstanding how knative/net-istio works since I'm relatively new to knative-serving but I think this is because
net-istio
generates multiple wildcarded TLS gateways both referecing the*.foo.com
domain on port 443. The first gateway to be created gets applied to the ingress-gateway and works. However the second does not get applied and is not visable as a listener in the ingress-gateway config, because the host port pair is already being used for the previously created wildcarded gateway. This breaks traffic for the second service, because the knative-serving virtualServices routes reference the gateway the traffic has to pass through as part of the route's matching criteria and that means there is no way of routing any traffic the second service on the custom domain, sinces it matches the first gateways wildcarded listener but then there is no route because there are no virtualServices with routes for that host bound to the gateway for the first service.Looking through the code it looks like multiple wildcarded gateways get created intentionally. When reconciling the knative-ingress the referenced secrets get catigorised based on if they contain a wildcarded cert or not and if is wildcarded then a wildcard gateway gets created. I think the problem here lies with the fact that even if the ingress has a fully specified name e.g.
bar.foo.com
the generated gateway created use the decoded infro from the cert and creates a wildcarded gateway.Is there a reason to not always use the host from the knative-ingress regardless of what is in the cert info? If the host was not wildcarded (link my instance above) I think this would have generated a working configuration with a gateway for each fully qualified domain served using the wildcarded cert.
The text was updated successfully, but these errors were encountered: