Nonresolvable domains don't play nicely with `func invoke`

[psschwei]

This came up in a Slack discussion today.

In Serving v1.8.0, we updated the default domain to be svc.cluster.local (https://github.com/knative/serving/pull/13259). Since this isn't reachable outside of the cluster, the user will need to configure DNS to be able to curl it. One option is to use temporary DNS, where the user would configure a dummy domain (say, example.com) and then curl it by passing service as a header (for example, curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198).

Note that after patching the domain, our service has different URL / address:

$ kubectl get ksvc hello -o json | jq ".status | {address, url}"
{
  "address": {
    "url": "http://hello.default.svc.cluster.local"
  },
  "url": "http://hello.default.example.com"
}

However, this scenario doesn't play nicely with func invoke, as the URL isn't able to be resolved:

$ kn func invoke
E1108 12:36:00.410545   55740 v2.go:105] io: read/write on closed pipe
Error: Post "http://hello.default.example.com": failed to exec in pod: command terminated with exit code 1 (stderr: "2022/11/08 17:36:00 socat[7] E getaddrinfo(\"hello.default.example.com\", \"NULL\", {1,0,1,6}, {}): Name does not resolve\n")
Error: exit status 1

If, instead, we pass in the internal address, then everybody's happy:

$ kn func invoke --target http://hello.default.svc.cluster.local
Received response
POST / HTTP/1.1 hello.default.svc.cluster.local
  Accept-Encoding: gzip
  K-Proxy-Request: activator
  X-Forwarded-For: 10.244.0.10, 10.244.0.3
  X-Forwarded-Proto: http
  X-Request-Id: b14936d3-a094-4ea1-9c36-4e6ec4e4416a
  User-Agent: Go-http-client/1.1
  Content-Length: 25
  Content-Type: application/json
  Forwarded: for=10.244.0.10;proto=http
Body:
E1108 12:37:57.900245   56078 v2.go:105] io: read/write on closed pipe

In an ideal world, users wouldn't need to pass in a target in this scenario (possibly func invoke could fall back to the internal address if the external URL isn't resolvable?).

I don't think this is a super-common scenario, though we've been seeing an uptick in issues in Serving relating to the domain change so that may change.

/kind bug

[matejvasek]

@lkingland would you please look at this? You are most knowledgeable about this.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[zroubalik]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[lance]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.