Coredns: The service with IP as ExternalName did not work

Created on 8 Oct 2018  路  3Comments  路  Source: coredns/coredns

My Env

kubernetes v1.11.3 (HA cluster) + k8s.gcr.io/coredns:1.1.3 + aws

What I did

  1. Create tests service like this
kind: Service
apiVersion: v1
metadata:
  name: test-domain-service
spec:
  type: ExternalName
  externalName: kubernetes.io
---
kind: Service
apiVersion: v1
metadata:
  name: test-ip-service
spec:
  type: ExternalName
  externalName: 104.198.14.52
  1. Login in(kubectl exec) one pod to access these services
    image

What I'm supposed to see (also works with kube-dns in kubeadm v1.6)

kubernetes can resolve these two service as well

image

What's more

Actually I want to create service below:

kind: Service
apiVersion: v1
metadata:
  name: test-domain-service
spec:
  type: ExternalName
  externalName: ip-10-10-10-204.xxxxxx.compute.internal
---
kind: Service
apiVersion: v1
metadata:
  name: test-ip-service
spec:
  type: ExternalName
  externalName: 10.10.10.204

As you see, they are aws EC2 private DNS name and private IP of one machine, the same result as the experiment.

I also have tried to create service like this but failed to resolve it:

kind: Service
apiVersion: v1
metadata:
  name: test-ip-service
spec:
  type: ExternalName
  externalName: 10.10.10.204
  ports:
    - port: 3306
      protocol: TCP

My question

Is there any feature or design that coreDns can't resolve service which forwards to an ip address?
Similary question : https://discuss.kubernetes.io/t/service-externalname-ip/494/5

kubernetes

Most helpful comment

It is unclear what you expect. In your example, you say that "kubernetes can resolve these two service...", but in the graphic that follows it, both results are "Not Found" ...

It's odd that an IP is allowed in the "externalName" field. The k8s documentation I found seems to infer that a IP in the field would not make sense:

ExternalName: Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up. This requires version 1.7 or higher of kube-dns.

... AFIAK, a CNAME value cant be an IP.

If you want a service that resolves to a statically defined ip address, you could ...

  • create a headless service
  • then create a statically defined endpoint for that service that contains the ip address.

e.g.

apiVersion: v1
kind: Service
metadata:
  name: gdns
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: dns
    port: 53
    protocol: UDP
---
kind: Endpoints
apiVersion: v1
metadata:
  name: gdns
  namespace: default
subsets:
  - addresses:
      - ip: 8.8.8.8
    ports:
      - port: 53
        name: dns
        protocol: UDP

All 3 comments

It is unclear what you expect. In your example, you say that "kubernetes can resolve these two service...", but in the graphic that follows it, both results are "Not Found" ...

It's odd that an IP is allowed in the "externalName" field. The k8s documentation I found seems to infer that a IP in the field would not make sense:

ExternalName: Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up. This requires version 1.7 or higher of kube-dns.

... AFIAK, a CNAME value cant be an IP.

If you want a service that resolves to a statically defined ip address, you could ...

  • create a headless service
  • then create a statically defined endpoint for that service that contains the ip address.

e.g.

apiVersion: v1
kind: Service
metadata:
  name: gdns
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: dns
    port: 53
    protocol: UDP
---
kind: Endpoints
apiVersion: v1
metadata:
  name: gdns
  namespace: default
subsets:
  - addresses:
      - ip: 8.8.8.8
    ports:
      - port: 53
        name: dns
        protocol: UDP

Thanks for response!

  1. I'm sorry that this case is kinda confusing, what I want to expect is that Service returns 404 differs from Can't resolve the service, that is, domain-service should perform the same as ip-service .
  2. Anyway, now I get the point , thanks again for explanation~~ The config works well, It helps!
    (hope there is no performance issue)
  3. BTW, In my later experience, the ip-valued-CNAME always work both in kubeadm v1.6 , It looks like some version issues : )

/label: kubernetes

Was this page helpful?
0 / 5 - 0 ratings