PTR records can collide

[thockin]

As pointed out at the end of #25, it's possible to make PTR records collide with manual endpoints, in which case someone can hijack the PTR record, even across namespaces.

apiVersion: v1
kind: Service
metadata:
  name: manual-1
spec:
  clusterIP: None
  ports:
  - port: 80

apiVersion: v1
kind: Service
metadata:
  name: manual-2
spec:
  clusterIP: None
  ports:
  - port: 80

apiVersion: v1
kind: Endpoints
metadata:
  name: manual-1
subsets:
- addresses:
  - ip: 10.10.10.10
    hostname: foo
  ports:
  - port: 80

apiVersion: v1
kind: Endpoints
metadata:
  name: manual-2
subsets:
- addresses:
  - ip: 10.10.10.10
    hostname: bar
  ports:
  - port: 80

This sort of makes PTR records, as implemented, useless. @sadlil offers #101, but I am worried about the impact of that when there are many DNS replicas. I don't think it will fly, and we really really do not want DNS to watch Pods (some crazy people run DNS on every node, and it will CRUSH the apiserver).

There's also an issue of adding PTR records for IPs that are not pods, I will open a different issue.

We need to find a solution to this ASAP or revert #25 and eat some crow.

We need some authoritative place that can confirm IP->pod mapping, but that seems impossible to do without creating an O(num-pods) watch, or else trusting Endpoints to not hijack.

[thockin]

@smarterclayton

[tamalsaha]

PTR records are needed for running some popular applications using StatefulSet. Some examples are GlusterFS, HBase. ref: kubernetes/kubernetes#33470 . We ourselves use GlusterFS. So, we like to have this feature not get reverted.

From #25 (comment) :
Given the potential performance issues, can this feature be put behind some annotation that users apply to the service, say service.beta.kubernetes.io/ptr: true . If that annotation is present, #101 will be applied. This will avoid performance issues for those who don't need this feature.

[thockin]

We need to do something with this for 1.8

[sadlil]

@thockin unless there is some kind of validation with endpoints, if we want ptr what about only apply #101 (get and check with pod) if there is an annotation applied in the service? This could avoid API calls and also solves our scenario.

[cmluciano]

@bowei Is this still targeted for 1.8? I think it might classify as a bug-fix, so we might be able to merge post freeze.

[bowei]

Leave leave it targeted for 1.8 for the post-freeze for now. I want to take care of it, but am bandwidth constrained pre-freeze :-|

[chrislovecnm]

See #25 (comment) for another way to break this where only one record is ever created, and it is never updated. It works once, then it is set to the original pod name, and never again.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close