cc @luxas @jbeda @mattmoyer @miekg

@kubernetes/sig-network-feature-requests

What is the argument behind this switch?

Hi Kristian,

Here's a little background. CoreDNS is another CNCF project and is the successor to SkyDNS, which kube-dns is based on. It is a flexible, extensible authoritative DNS server and we have built a direct integration to the Kubernetes API. It can serve as cluster DNS, complying with the dns spec. We started discussions with @thockin, @matchstick and @bowei last year around KubeCon and they are open to it in principle, but of course it needs to be proven to be the right choice.

As for reasons to switch, CoreDNS has fewer moving parts than kube-dns, since it is a single executable and single process. It is written in Go so it is memory-safe (kube-dns includes dnsmasq which is not). It supports a number of use cases that kube-dns doesn't. As a general-purpose authoritative DNS server it has a lot of functionality that kube-dns couldn't reasonably be expected to add.

You may also want to check out the intro or coredns.io. There is also a webinar I did for CNCF a couple months back.

I would expect a proposal for this.

Ok, will do. I assume that means based on https://github.com/kubernetes/community/blob/master/contributors/design-proposals/Design_Proposal_TEMPLATE.md

Ok, here is the proposal. Sorry for all those commits referencing this.

https://github.com/kubernetes/community/pull/1100

Not sure this was meant to close

/reopen

@kargakis: you can't re-open an issue/PR unless you authored it or you are assigned to it.

@spxtr any idea how we can stop closing this because of fork cross-linking?

It's a GitHub bug feature. I asked them to change the behavior to stop closing when people update their forks, but there response was "if you don't want it to happen then stop saying 'fixes #soandso' in your commit messages."

How about a tool that validates commit messages?

Let's move the discussion in test-infra. I will open an issue to discuss.

It's possible. It only causes a problem if you say "fixes someorg/repo#number" rather than "fixes #number", because in the latter case it tries to close the issue in your fork where it doesn't exist.

@johnbelamaric :wave: Please open a documentation PR and add a link to the tracking spreadsheet. Thanks in advance!

Doc PR: https://github.com/kubernetes/website/pull/6463

@luxas : it was validated yesterday in SIG Network that CoreDNS will go BETA for k8s 1.10.

Should we flag here Stage/Beta ?

marked for beta 1.10

@johnbelamaric looks as though you need to update the doc for 1.10? In case it helps: https://github.com/kubernetes/website/blob/master/docs/tasks/administer-cluster/coredns.md
I can help if you like; looks as though feature state flag needs to be updated, but I'm not sure just how you want to refer to the 1.10 release and the move to beta.

[ Quoting notifications@github.com in "Re: [kubernetes/features] Switch de..." ]

@johnbelamaric looks as though you need to update the doc for 1.10? In case it helps: https://github.com/kubernetes/website/blob/master/docs/tasks/administer-cluster/coredns.md
I can help if you like; looks as though feature state flag needs to be updated, but I'm not sure just how you want to refer to the 1.10 release and the move to beta.

What exactly do you need here. The doc you linked only needs to say beta?
For the CoreDNS version to be used? That should be 1.0.6 or higher.

@miekg Looks as though I can make the doc updates. Wrangling merge conflicts atm, will post PR here and add you as reviewer when I'm done fixing.

@Bradamant3 thanks for the offer, but I can take care of this today, unless you really want to do it?

https://github.com/kubernetes/website/pull/7638

Go for it! Thanks!

@johnbelamaric
Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

This feature is

• ALPHA in k8s v1.9
• BETA in k8s v1.10
• There is a KEP in progress for GA : https://github.com/kubernetes/community/pull/1956

@justaugustus thanks - I am not a member so I don't have the access to change labels, etc. But as @fturib says it is targeted for GA in 1.11. @rajansandeep can you change the labels?

I don’t seem to have permissions to change the labels.
@cmluciano @idvoretskyi can update the labels here.

Updated

@cmluciano thank you!

Perfect. Thanks for the updates everyone!

This has changed now, we need to split into two features: CoreDNS available as an option, and CoreDNS as default. Can we just rename the issue and create a new one for making it default (targeting 1.12)?

@johnbelamaric / @cmluciano -- I've renamed the description of this feature and created a new one (#566) around enabling CoreDNS as the default DNS plugin. PTAL and let me know if there are any details I need to update on that feature issue.

@justaugustus thanks!

@justaugustus what's the difference between the current one and #566?

@idvoretskyi the current one does not enable it by default. It just declares it a GA feature that can be enabled. Enabling it by default (on new installs and on upgrades) will come later.

@johnbelamaric it's clear, thanks.

I'm not sure two feature issues are needed for that though. If CoreDNS is GA in v1.11 it's up to every deployment tool (kubeadm, kops, GKE, AKS, EKS, etc.) to enable it by default in their own pace. You can't dictate a default for an option for all of the installer options, as some of them are unreachable to the OSS world. I'd go with just this one. If you want to track the enabling of CoreDNS as a feature for a _specific deployment_ like GKE, then you might optionally do that in a separate issue.

Does that make sense to you?

@luxas I see your point. However, don't we need to provide a recommendation at some point as to which of the options to use? What if we want to deprecate kube-dns at some point?

This "replace a component" is new territory, so we're trying to figure out the best process.

When CoreDNS is GA, I'd expect it to be the default for new clusters as it's the new thing.
That's the implicit recommendation from the feature status for me at least.
If CoreDNS is ready to technically be default in all new clusters in v1.11, I'd graduate it to GA now and deprecate kube-dns. kube-dns would be supported as an option for backwards-compability for a year (approx. four releases; until v1.15) though, as of GA: 1 year or 2 releases (whichever is longer) in https://kubernetes.io/docs/reference/deprecation-policy/

@luxas I expect there will be additional features (if there aren't already) in which you choose between several GA options that provide similar functionality. For example, whether to use iptables or ipvs for kube-proxy. I think we need a model for managing those situations.

@johnbelamaric I am the CI Signal lead for 1.11 and also work on Conformance testing program for K8s. I see this feature is going to Stable in 1.11.
I also see you have some e2e test changes for this feature. I am following up to see if and which of those tests should we promote to the conformance suite in 1.11.
As part of the process to increase conformance coverage, outlined by Conformance WG and Sig-Arch, we expect features going into stable/GA to have representation in Conformance suite. Your update on the same will help us evaluate this feature better.

I would expect the existing DNS conformance tests to cover this. I
would not expect use of coredns to be required to be conformant.

All that said - are our dns conformance tests sufficient in scope to
cover the dns minimum requirements?

@AishSundar : CoreDNS is replacing kube-dns. As such we ensured already that CoreDNS is conform to existing DNS Conformance test.
We have a suite test for CoreDNS running here : http://k8s-testgrid.appspot.com/sig-network-gce#gci-gce-coredns (that is larger than Conformance)

As such, CoreDNS has already a representation in Conformance suite (the same as kube-dns, the feature it replaces).

We also ensured that CoreDNS is compliant to all DNS test running in e2e. that is why we have some e2e test changes. But those are not part of the conformance suite.

Adapt existing test to CoreDNS, verifying the configuration by Configmap change : https://github.com/kubernetes/kubernetes/pull/63265

Create a new test for DNS, by adding a specific DNS related test on scalability (asked by sig-networking) : https://github.com/kubernetes/kubernetes/pull/63820

Extends all DNS tests for IPv6 use case : https://github.com/kubernetes/kubernetes/pull/59894

@smarterclayton CoreDNS is conformant in the default configuration.

Thanks

On Thu, May 24, 2018 at 9:04 AM, John Belamaric notifications@github.com
wrote:

@smarterclayton https://github.com/smarterclayton CoreDNS is conformant
in the default configuration.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/427#issuecomment-391706882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p5HuTwCmZPQTctXv2FUS15nuzKC6ks5t1q_bgaJpZM4PU9YV
.

Thanks @fturib for the clarification and PR pointers here

@johnbelamaric --
We're doing one more sweep of the 1.11 Features tracking spreadsheet.
Would you mind filling in any incomplete / blank fields for this feature's line item?

@justaugustus I updated it to "Draft". We have several PRs in various states of merged and under review for the docs. There is already a link in there to the tracking issue.

@johnbelamaric thanks for the update!
Looks like everything is fine on that tracking issue. My only note would be that that tracking issue would be better suited as an issue in k/k or k/website, not the Kubeadm project.

Closing this as the feature is GA in 1.11. Please feel free to reopen if there is still a need to track this.
/close