fix bug with delete externalName service

[sergeylanzman]

On delete service from namespace kube-dns get event EndpointAdd.
Func addDNSUsingEndpoints generate RecordsForHeadlessService in cache to service type externalName.
After this delete from a cache, it's deleted an empty record, but a record of Entries for externalName stuck forever.
Solution: don't generate the empty record for externalName

[BenTheElder]

/ok-to-test

[sergeylanzman]

@BenTheElder travis-ci broked in the master branch.
Fix in #206.

[sergeylanzman]

@BenTheElder Any updated?

[BenTheElder]

@sergeylanzman I'm not the right person to review this PR, but Prow tests are passing at least. To get Travis to re-run I think you can close / reopen it. We have /retest and /test foo for Prow but I don't think Travis allows anyone besides the repo owner to reschedule testing directly.

[BenTheElder]

/assign @MrHohn

[sergeylanzman]

/retest

[MrHohn]

Thanks for the fix, this makes sense. According to the specification and doc on kubernetes.io, endpoints controller does not create Endpoints records for externalName service (users might be able to be that should have no effect) and such service only gets a CNAME record.

/lgtm

[sergeylanzman]

@MrHohn what about release 1.14.9? I need this fix, today I can't delete externalname service

[MrHohn]

@sergeylanzman We are planing on releasing 1.14.9 ~next week.

While I agree we shouldn't generate unnecessary record for extenalName service, it is not quite clear to me how you have hit this. "On delete service from namespace kube-dns get event EndpointAdd" sounds a bit odd, deleting a service shouldn't have any endpoint to be created, or do you have some custom logic that triggers this?

[sergeylanzman]

Step to reproduce

1. Create deployment + 1 pod
2. Create clusterIP service with a selector for pod deployment
3. Delete clusterIP service
4. Create externalName service with the same name as clusterIP service(replace service)
5. Delete externaName service and create again clusterIP

I continue to receive DNS resolve with externalName CName value

[MrHohn]

@sergeylanzman Interesting, sounds like the endpoints controller was tricked and thought the yet to be deleted endpoint belongs to the externalName service. Did you create the externalName service with the same selector (which should have no effect)?

[sergeylanzman]

@MrHohn I create extername service with kubectl create, without selector, but it's create with selector from clusterIP(maybe cache in apiserver)