serving
serving copied to clipboard
Default domain in config-domain should be svc.cluster.local instead of example.com?
What version of Knative?
Expected Behavior
Default domain should be svc.cluster.local
Actual Behavior
Default domain is example.com
Steps to Reproduce the Problem
This is not really a bug, but more of an API/usability suggestion.
Our ops drones find the way that you globally configure default cluster-local traffic in config-domain with svc.cluster.local: "" confusing and it has turned into a bikeshed. The question that comes up is "That's redundant with k8s DNS, why would you do that?"
The other downside is that it's not obvious how it will interact with the domain-template in config-network, as I might expect that customization to apply to all domains, including "*.svc.cluster.local". (It does not.)
The default example.com is not actually usable in any case, and will be one of the first things that gets customized.
I edit configmap like follows, it works:
root@cesign [11:41:48 PM] [+45.0°C] [~/git/group-service-acceleration] [main *]
-> # kubectl get configmap coredns -nkube-system -oyaml
apiVersion: v1
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cesign.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
rewrite name regex (.*)\.example\.com kourier-internal.kourier-system.svc.cesign.local
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
kind: ConfigMap
metadata:
creationTimestamp: "2022-08-08T16:37:44Z"
name: coredns
namespace: kube-system
resourceVersion: "839289"
uid: f33f8487-2370-4b9b-9a64-b80ceaa58946
The key part is: rewrite name regex (.*)\.example\.com kourier-internal.kourier-system.svc.cesign.local, after update and wait one minute, it works
That will only work for Kourier, and is even more complex than the documented way of setting the default. The request is to make the default value "svc.cluster.local" as the API definition to avoid confusion.
FWIW +1. Having the default be example.com means that you can't easily make it svc.cluster.local unless/until the default-domain job is run.
These days I generally just use svc.cluster.local and expose things with DomainMapping.
What I think is, we should allow let user use {svc}.{namespace}.{domain} or other templates to call service in cluster.
+1. If no objections, I think it is alright to change the default and no big impact because any current users are supposed to change the example.com.
One disadvantage I come up with is that we cannot quickly veirfy the ksvc after the installation by curl -H "Host: hello.default.example.com" ${LB_IP}. But I guess it is trivial.
+1 from me. Based on a quick look, should just require an update to the DefaultDomain and some tests that were expecting "example.com".
/triage accepted
I guess we need the following steps to proceed this change.
- Send a temporary PR to change the default domain.
- Just to see how much work we need to do for this. As Paul mentioned, I think we need some tweak.
- Send an announcement for serveless-dev@ and knative-users@ ML if there is any objections or concerns.
- Merge the PR step-1 and change the default.
Please feel free to leave a comment if there is anything to do for the change. Also, please feel free to let us know if there is anyone who wants to tackle this issue.
- Send a temporary PR to change the default domain.
#13259
I'll tackle this next week if no one else picks it up before then
Emailed announcement to knative-dev / knative-users
This is confusing because the route is added to the external gateway even when using svc.cluster.local.
If you do this, it may be a good idea to modify the set to add the route to the internal gateway in the case of svc.cluster.local.
For example, if networking.knative.dev/visibility=cluster-local is not described, the route is added to the external gateway, but if it is described, the route is added to the internal gateway.
This is confusing because the route is added to the external gateway even when using
svc.cluster.local. If you do this, it may be a good idea to modify the set to add the route to the internal gateway in the case ofsvc.cluster.local.
Is this an issue in all cases when using svc.cluster.local or is it just due to setting it as the default domain? Assuming it's the latter, I don't think that's blocking here. cc @nak3
Sorry for the late response. In addition to Paul's comment, Could you elaborate on "the route is added to the external gateway even when using svc.cluster.local" ? I think I don't understand about it.