Allow namespace rather than kubelet to supply the added DNS client config about enhancements

[thockin]

So the goal here is to run multiple DNS servers, one for each tenant (inasmuch as you can model the concept)? This intersects really badly with the evolving design of DNS, which was likely to end up with a node-local cache/proxy.

@bprashanth @bowei

[ardnaxelarak]

Proof-of-concept/work-in-progress at https://github.com/ardnaxelarak/kubernetes/tree/31017_namespace_dns_client_config_annotations

[idvoretskyi]

@ardnaxelarak what is the current status of the feature submission? Which milestone does it target?

[duglin]

Can we target this for 1.6 ?

[duglin]

@thockin is there a doc describing the DNS you're referring to? Does your "intersect" mean in a "bad" way or just a "big" way? Would a node-local cache imply that pods in different namespaces on the same node would see each other's DNS entries? Seems like a complementary PR would be to make this node-local cache be namespace aware too.

[thockin]

Doug,

kubernetes/kubernetes#32749 talks about some of
the ideas of installing a cache per-node. That would be fine with
per-namespace DNS policy, but it gets harder in the face of multi-tenancy.
But we're going to have to solve that.

I am OK with the idea of per-namespace DNS policies, but we need a more
thorough proposal that addresses the issues:

• DNSPolicy is currently specced as part of the apiversion
• Annotations are fine for prototyping something like this, but probably
  not "for real", but new api objects are sort of under a moratorium
• Need to consider how it intersects with caching (positive and negative)
  and eventual multi-tenancy

probably more I can't think of.

On Mon, Nov 21, 2016 at 10:38 AM, Doug Davis [email protected]
wrote:

@thockin https://github.com/thockin is there a doc describing the DNS
you're referring to? Does your "intersect" mean in a "bad" way or just a
"big" way? Would a node-local cache imply that pods in different namespaces
on the same node would see each other's DNS entries? Seems like a
complementary PR would be to make this node-local cache be namespace aware
too.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#75 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOcyuyp2H4WNzcNJhjLiJYk7dLRGks5rAeUrgaJpZM4JsZkB
.

[cmluciano]

@thockin Is the per-node DNS cache the place to start prior to this multi-tenant implementation? I'd like to shepherd the latter along while remaining cognizant to the future of DNS.

[thockin]

@bowei

[idvoretskyi]

As there's no clear proposal and final decision, I'd skip this one for 1.6 in favor of 1.7 or latter.

[fejta-bot]

Issues go stale after 30d 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