Add support for Kubernetes ExternalName service

[alejandro-llanes]

Proposed changes

I've tried to use ExternalName service with this ingress-controller but doesn't work, so I perform some changes to the controller.go to use backend.ServiceName:backend.ServicePort as a default endpoint instead of look for them in kubernetes objects.

These changes are based in the issue #262 and this comment ExternalName

I've just modify getEndpointsForIngressBackend method to add these lines:

	if svc.Spec.Type == api_v1.ServiceTypeExternalName {
		var endpoints []string
		endpoint := fmt.Sprintf("%s:%d", backend.ServiceName, int32(backend.ServicePort.IntValue()) )
		endpoints = append(endpoints, endpoint)
		return endpoints, nil
	}

Hope this help 😃

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto master
• I will ensure my PR is targeting the master branch and pulling from my branch from my own fork

[pleshakov]

@sombralibre thx for the PR.

Unfortunately, the suggested solution has limitations:

• Stale DNS records. Once a DNS name of an ExternalName service is resolved by NGINX during a configuration reload, NGINX will not try to re-resolve it, even when the TTL of the resolved records expires. NGINX will only be able to re-resolve the name during any subsequent configuration reload.
• Potential reload failures. If a DNS name cannot be resolved, NGINX will fail to reload. Please note that if the Ingress Controller tries to make any further changes to NGINX configuration -- for example, as a result of the changes that affect other Ingress resources -- those changes will not be applied by NGINX until the DNS name can be resolved again and therefore NGINX can be successfully reloaded.

Those limitations come from the fact that NGINX doesn't support dynamic DNS resolution. More info about this topic is written in https://www.nginx.com/blog/dns-service-discovery-nginx-plus/

Additionally, the suggested solution assumes that the Ingress Controller and the service in question is deployed in the same namespace. This is an example of the generated config: server my-service:80 max_fails=1 fail_timeout=10s;. If the my-service service is deployed in a different namespace, NGINX will not be able to resolve it.

As a workaround for the externalname services, I suggest to try to use a service without a selector, described here https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors In this case, in addition to a service resource you will have to create a corresponding endpoints resources that contains the list of IPs of the service.
Can this approach work for you?

Note that we are implementing support of type ExternalName services for NGINX Plus, because it supports dynamic DNS resolving.

[alejandro-llanes]

It's ok, that make sense.

So there isn't reason to keep this PR open.

Thanks for you help and accurate explanation.