Kubeadm: deprecate and remove kube-dns support in kubeadm

Created on 27 Nov 2019  Â·  26Comments  Â·  Source: kubernetes/kubeadm

this is a proposal to deprecate the kube-dns deployment with the release of 1.18 and remove the code for it in 1.21.

CoreDNS has been the default since 1.11 (if i recall correctly) and the kube-dns support is something we should decouple from kubeadm.

We haven't updated the kube-dns version in kubeadm since 2018.

ideally and long term, the users should be able to skip the DNS server deployment completely and install a custom one to their liking, either manually or via a "addon installer" of sorts.


actions for 1.18:


actions for 1.21:


UPDATE
sent notification to k-dev:
https://groups.google.com/d/msg/kubernetes-dev/m8suvuNBtcU/BglNo6tUAAAJ

kinapi-change kincleanup kindeprecation prioritimportant-longterm sinetwork

Most helpful comment

Indeed. It's becoming rather tricky to maintain a couple of possible DNS addons. Especially when one of them is not getting as much user attention than the other.

All 26 comments

i think that is a good location, yes.
still needs discussion if we want to deprecate it even.

@neolit123 - if kube-dns is being deprecated, we should do it too. But If @kubernetes/sig-network-misc didn't I think we should wait

/cc @bowei

technically, kubeadm is an opinionated deployer that can decide what addons to pick as their best practice cluster.

at the same time kubeadm allows skipping the DNS addon, and allowing the user to pick their own.
i haven't seen kube-dns kubeadm users since coredns went GA, so if we are keeping kube-dns it feels to me this needs a better argument.

@rajansandeep @chrisohaver i think we can proceed with this PR for preserving the replica count https://github.com/kubernetes/kubernetes/pull/85837 but we might need the refactor of not redeploying the CoreDNS/kube-dns completely from scratch, instead:

  • fetch existing deployment
  • change image tags if needed
  • migrate corefile

also me and @rosti discussed today that before that we should probably file the PR to deprecate kube-dns in 1.18 and stop maintaining it.

Indeed. It's becoming rather tricky to maintain a couple of possible DNS addons. Especially when one of them is not getting as much user attention than the other.

So shall we file a PR to deprecate kube-dns now?

yes, it was decided to file the deprecation but also gather feedback if someone is still using it with kubeadm.

note: we haven't updated the kube-dns version in kubeadm since 1.14.13 (20 Sept, 2018).
latest version is 1.15.8 from 21 Nov, 2019.

https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/constants/constants.go
https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/k8s-dns-kube-dns?gcrImageListsize=200

As soon as this becomes deprecated, documentation that mentions the _application_ called kube-dns should change to make that detail clear. AIUI kube-dns the application will remain even past the deprecation of kube-dns the addon.

IMO: it's enough to open an issue in k/website and leave the actual rewording and localization and localization to SIG Docs.

that may still be confusing for other reasons

$ kubectl cluster-info
Kubernetes master is running at https://127.0.0.1:32832
KubeDNS is running at
https://127.0.0.1:32832/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info
dump'.

On Fri, Jan 24, 2020 at 1:44 AM Tim Bannister notifications@github.com
wrote:

As soon as this becomes deprecated, documentation that mentions the
application called kube-dns should change to make that detail clear.
AIUI kube-dns the application will remain even past the deprecation of
kube-dns the addon.

IMO: it's enough to open an issue in k/website
https://github.com/kubernetes/website and leave the actual rewording
and localization and localization to SIG Docs.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubeadm/issues/1943?email_source=notifications&email_token=AAHADKZJUHCDTZGJYG7SWWTQ7K2AZA5CNFSM4JSMODOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ2H73I#issuecomment-578060269,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHADK4Y5XMCWT5D76NJSQLQ7K2AZANCNFSM4JSMODOA
.

The service is named "kube-dns" and changing that would probably break
various things ...

On Fri, Jan 24, 2020 at 5:47 PM Benjamin Elder bentheelder@google.com
wrote:

that may still be confusing for other reasons

$ kubectl cluster-info
Kubernetes master is running at https://127.0.0.1:32832
KubeDNS is running at
https://127.0.0.1:32832/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info
dump'.

On Fri, Jan 24, 2020 at 1:44 AM Tim Bannister notifications@github.com
wrote:

As soon as this becomes deprecated, documentation that mentions the
application called kube-dns should change to make that detail clear.
AIUI kube-dns the application will remain even past the deprecation of
kube-dns the addon.

IMO: it's enough to open an issue in k/website
https://github.com/kubernetes/website and leave the actual rewording
and localization and localization to SIG Docs.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubeadm/issues/1943?email_source=notifications&email_token=AAHADKZJUHCDTZGJYG7SWWTQ7K2AZA5CNFSM4JSMODOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ2H73I#issuecomment-578060269,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHADK4Y5XMCWT5D76NJSQLQ7K2AZANCNFSM4JSMODOA
.

originally SIG Network wanted to add the CoreDNS service as kube-dns to provide a smoother transition. https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction

The service is named "kube-dns" and changing that would probably break
various things

true.

+1 for adding a core DNS service + deprecate the kube-DNS one, but this is really up to SIG-network

I wonder if we can update kubectl cluster-info to say something like DNS is running at ... and prefer some annotated service entry or something like that.

doesn't seem _super_ important, but I could certainly see users being confused about "KubeDNS is running at" when we're not using kubedns...

Has https://github.com/kubernetes/kubeadm/issues/1943#issuecomment-578508089 been raised to SIG Network?

cc @johnbelamaric @chrisohaver
do you have comments about:

doesn't seem super important, but I could certainly see users being confused about "KubeDNS is running at" when we're not using kubedns...

I have been referring to the cluster service discovery DNS service in Kubernetes as "Cluster DNS", to distinguish it from other DNS services in the K8s equation... (Upstream DNS, Node Local Caching DNS).

I don't think we should change the service name, as pointed out it will break stuff (which is why we didn't do it before). The "KubeDNS" I believe comes from an annotation, that could be change, I would think. It could vary based on which DNS provider is installed. Or it could just read "Cluster DNS" as Chris suggests.

I'd like to help with this.

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.

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

/remove-lifecycle stale

@neolit123, I can handle the actions for 1.21

actions for 1.21:

 - clean kube-dns from the kubeadm codebase

 - clean any mentions of kube-dns + kubeadm in the k/website docs

/assign

thank you @rajansandeep !

Was this page helpful?
0 / 5 - 0 ratings