Support for Headless hostPort services

[kevincox]

It would be really convenient if I could push an A record pointing at the public IP address of each pod in an headless service. This way I can connect directly to the service.

Bonus points for publishing a SRV record with the node external IP and the hostPort value.

[Arttii]

So I was wondering on a good way to implement this. Based on the work done in #278. I guess we would have to query for the actual Pods to get at the HostIPs and Ports, using the selector from the Headless service? Or is this a bad approach?

I tried to address this in #324.

[hjacobs]

#324 was released in https://github.com/kubernetes-incubator/external-dns/releases/tag/v0.4.8, but we still need documentation for it describing how it's used (with FQDN template).

[hjacobs]

Just tested the new feature with v0.4.8 --- here what needs to be done to try it out:

• FQDN template option must be set, e.g. like --fqdn-template=extdns-{{.Name}}.example.org
• create a pod (manually or via some controller), note that the hostname field of the pod must be set and the container needs to expose a hostPort (only works if the PodSecurityPolicy allows it)!
• create a headless service selecting your pod(s), e.g.:

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    application: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  clusterIP: None

The resulting DNS entries will look like (assuming the pod's hostname was set to "pod-1"):

time="2017-11-22T19:52:25Z" level=info msg="Desired change: CREATE pod-1.extdns-my-service.example.org A" 
time="2017-11-22T19:52:25Z" level=info msg="Desired change: CREATE pod-1.extdns-my-service.example.org TXT" 

The DNS entries will point to the private IP of the node and the pod can be accessed via the exposed hostPort (depending on your firewall configuration and network setup).

[Arttii]

I wasn't sure where to add the docs, and was waiting for some comments on that, thanks for documenting it. Is there anything else we need to add?
A thing to note is it will also work if you provide a full annotation in the service, but you are right, using the fqdn template seems like a better approach.

[hjacobs]

@Arttii could you add a complete tutorial in the tutorials folder on how to use headless hostPort services?

[Arttii]

Yes sure, I'm out of the offcie currently, but I think I have some time to work on it tomorrow. Should be fairly straightforward.

[hjacobs]

@Arttii thanks! 😄

[akmistry]

There's something I'm really not understanding here. I got this up and running on my GKE cluster, and now I can have a headless service expose a DNS entry:
bootstrap.foo-root.internal.mistry.ninja. A 300
10.128.0.2
bootstrap.foo-root.internal.mistry.ninja. TXT 300
"heritage=external-dns,external-dns/owner=foo-dev-us-central1"

Except the IP address is the node (VM's) IP address, not the pod's. And this is a ClusterIP service which does not expose a port on the node. If instead I switch to a nodePort service, external-DNS doesn't recognise it, but now I have a connected port on the node. I can probably get around this by having two services, one for the external-dns registration, and one for the nodePort. This is extremely hacky and doesn't appear at all to be the desired functionality. What am I missing here?

[hjacobs]

@akmistry the current support was only implemented for "hostPort", i.e. you have to expose the port on the host by defining a hostPort on your pod. NodePort services are not yet supported, see #191

[hjacobs]

@akmistry we would be very happy to see your contribution/PR to support NodePort services (#191) 😄

[Arttii]

@akmistry I was wondering if you could explain what your desired functionality was? Do you want the NodeIPs or PodIPs exposed for your NodePort service?

[akmistry]

@hjacobs But NodePort services are what is effectively being supported here because the node's IP address is being advertised. I think NodePort->NodeIP and headless->PodIP is most intuitive.

@Arttii Headless services have their PodIPs (if clusterIP: None) registered under the service's name in kube-dns. I would expect the same in external-dns. I'm not interested in NodePort support.

Also, according to https://kubernetes.io/docs/concepts/configuration/overview/:
"Don’t use hostPort unless it is absolutely necessary (for example: for a node daemon). It specifies the port number to expose on the host. When you bind a Pod to a hostPort, there are a limited number of places to schedule a pod due to port conflicts— you can only schedule as many such Pods as there are nodes in your Kubernetes cluster."

[Arttii]

@hjacobs I added a small tutorial in #399 . Let me know what you think.