{"action":"opened","issue":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/31017","repository_url":"https://api.github.com/repos/kubernetes/kubernetes","labels_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/31017/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/31017/comments","events_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/31017/events","html_url":"https://github.com/kubernetes/kubernetes/issues/31017","id":172191200,"number":31017,"title":"Feature Request: Allow namespace rather than kubelet to supply the added DNS client config","user":{"login":"ardnaxelarak","id":7015167,"avatar_url":"https://avatars.githubusercontent.com/u/7015167?v=3","gravatar_id":"","url":"https://api.github.com/users/ardnaxelarak","html_url":"https://github.com/ardnaxelarak","followers_url":"https://api.github.com/users/ardnaxelarak/followers","following_url":"https://api.github.com/users/ardnaxelarak/following{/other_user}","gists_url":"https://api.github.com/users/ardnaxelarak/gists{/gist_id}","starred_url":"https://api.github.com/users/ardnaxelarak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ardnaxelarak/subscriptions","organizations_url":"https://api.github.com/users/ardnaxelarak/orgs","repos_url":"https://api.github.com/users/ardnaxelarak/repos","events_url":"https://api.github.com/users/ardnaxelarak/events{/privacy}","received_events_url":"https://api.github.com/users/ardnaxelarak/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-08-19T18:25:26Z","updated_at":"2016-08-19T18:25:26Z","closed_at":null,"body":"The use case for this new feature is a Kubernetes operator who is\r\nproviding a multi-tenat service based on namespaces.  Each namespace\r\nbelongs to one tenant.  One tenant should not have a view of the whole\r\ncluster; rather the tenant's view should be constricted properly.\r\n\r\nThere are a few facets to this problem.  One of them is the DNS client\r\nconfiguration applied in the tenant's pods.  The k8s API has an optional\r\n`dnsPolicy` field in a `PodSpec`, and that field's value can be either\r\n`ClusterFirst` or `Default`; the default behavior is that of\r\n`ClusterFirst`.  The `Default` setting means that the pod uses its\r\nhost's DNS client configuration.  The `ClusterFirst` setting means\r\nthat the pod's DNS client configuration is constructed from the host's\r\nby conditionally prepending some stuff.  The kubelet's `--cluster-dns`\r\nparameter, if supplied, is prepended to the DNS server list.  The\r\ndomain search list is prepended by the kubelet's `--cluster-domain`\r\nparameter if there is one, and then `svc.cluster.local`\r\n`cluster.local` (where the `cluster.local` part can be varied by\r\nanother kubelet parameter) unconditionally.\r\n\r\nThe idea in this proposal is to allow a namespace to override the\r\nbehavior of the `ClusterFirst` setting to make it mean that the stuff\r\nprepended comes from a new namespace field rather than kubelet\r\nparameters.  We introduce into `NamespaceSpec` an optional field\r\n`dnsClientConfig` of a new type `DNSClientConfig`.  A\r\n`DNSClientConfig` holds a list of DNS server addresses and a list of\r\nstrings (search domains).  If the `dnsClientConfig` is present in a\r\nnamespace then for every pod in that namespace the `ClusterFirst`\r\nbehavior is to derive the pod's DNS client config by prepending the\r\ncontents of the namespace's `DNSClientConfig` (rather than the\r\nsettings derived from the kubelet parameters) to the config from the\r\nhost."}}
{"actor":{"display_login":"ardnaxelarak"}}