Using DNS for External Services in Kubernetes

Consul
,
1

Hello,

I have Consul set up with the official Consul Helm chart (v0.32.0) in K8s.
I am using DNS for service discovery, and have changed the coredns settings according to the documentation.

I can use <service>.service.consul URLs within the pods to talk to the other pods.

I want to be able to do the same for external services.
I set up an external service according to the External Service documentation by creating a “dummy” node like follows:

{
  "Node": "external-node",
  "Address": "external-service.that.is.publicly.accessible.com",
  "NodeMeta": {
    "external-node": "true",
    "external-probe": "true"
  },
  "Service": {
    "ID": "external",
    "Service": "external",
    "Port": 80
  }
}

I have also tried settings DNS recursors (Google’s 8.8.8.8 and 8.8.4.4 servers) either via the Helm chart value (so that -recursor parameters are added to the command line of the client and server pods), or via the extraConfig value in the Helm chart, so that it gets added to the extra-from-values.json ConfigMap.

However, trying to use external.service.consuldoes not work. When I try to ping it, I get ‘bad address’. Using dig, I can see it returning an A record in the end, but it’s like recursion doesn’t work outside of using dig.

external-node.node.service.consul works, but trying to remember which service uses which URL format runs kind of counter to service discovery IMO.

Inspecting the dig answers, they look identical except that the node URL also includes the NodeMeta entries as TXT records. Shouldn’t matter for my purposes here.

Using nslookup external.service.consul, the resolving stops at the CNAME.
Using nslookup external-node.node.service.consul, the A record is returned.

Is this a limitation or a bug or have I done something wrongin setting up either the external service or the DNS?

2

Exploring something similar.
@jon Did you get a solution eventually?

3

Hi @jon,

You should be able to resolve this issue by setting dns_config.enable_truncate to true in your client and server configs. See https://github.com/hashicorp/consul/issues/10551#issuecomment-919621937 for a config example.

Are you attempting to use this in the context of the service mesh, or a simple service discovery use case?

If the former, we’re looking to add support for routing through a terminating gateway to external services that are registered in Consul (e.g., <name>.service.consul) using transparent proxy in a near-term patch release for Consul 1.11. I recommend subscribing to issue #11091 for updates. In the interim, you’ll need to use a statically declared upstream in order to reach external services.