KEP for CoreDNS to GA. #1956

rajansandeep · 2018-03-21T17:22:39Z

This KEP is defined to graduate CoreDNS to GA.

rajansandeep · 2018-03-21T17:27:48Z

/sig network

johnbelamaric · 2018-03-21T18:04:44Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+## Motivation
+
+    * CoreDNS is more flexible and extensible than what kube-dns. 


@rajansandeep let's not indent these, we don't want it showing up as pre-formatted.

s/than what/than/

fturib · 2018-03-21T18:20:20Z

I think you need to add the file that hold the NEXT-KEP-NUMBER.
increment the number, and add the file in this PR. (to be sure no one else will take the number)

fturib · 2018-03-22T12:13:24Z

/review @bowei

stp-ip

CoreDNS for GA \o/

stp-ip · 2018-03-22T12:19:05Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+### Non-Goals
+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Retaining the ConfigMap of a custom/modified image of CoreDNS during upgrade. That is, if the user has modified the Corefile in the ConfigMap, those changes will not be retained (the user should back it up and redo the changes on the new ConfigMap).


Feels quite intrusive to overwrite user configuration on an upgrade without a path to prevent this. At least needs to be documented or warned for imo.

Ok, I can document that and also make this statement a little clearer.

Just to clarify, at upgrade time, the ConfigMap is not retained only if the coredns image we find is "unofficial" (not shipped with alpha (1.9) or beta (1.10)... ) and coredns will be upgraded to the latest image and default ConfigMap.

Agree - this is user-hostile. If you expose a ConfigMap you are publishing it as a mechanism to configure the app. If you intend to blow it away, you should just not expose it. at all.

Now we have to talk about defaults vs user-overrides.

Ok, but this is just for the ConfigMap, right? That is, how should we handle changes to the manifest/deployment itself?

In this case then we should add the new, updated default ConfigMap under a different name, to make it easy for the user to switch to that if they want to, or at least compare any differences. This also means that in the event of non-backwards compatible changes to the Corefile (which we might do, but only when we bump the minor - not patch - version), we will need to do something special.

@rajansandeep can you make sure the 1.0.x -> 1.1.x remains backwards compatible for the Corefile? If so we don't need to worry about that for a while.

@johnbelamaric : what about this proposition for upgrade 1-ConfigMap, 2-Deployment
1- never update the ConfigMap (as you suggest). It is created first time of installation of CoreDNS (either by upgrade from kube-dns, either by installation from scratch), and on subsequent upgrade, we keep that ConfigMap - Until we reach the issue of non-backward compatible corefile. At that time we figure out with special upgrade.

NOTE: does it worth to create a "coredns-default" ConfigMap ? It would show no more than the one of the coredns/deployment repository since kube-dns config no longer exist.

2- For the deployment part, first installation creates the deployment of CoreDNS. Subsequent upgrades only change the image of CoreDNS - unless admin prevent it by removing the label "kubeadm-auto-upgrade" that the first installation is setting.

stp-ip · 2018-03-22T12:19:43Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Retaining the ConfigMap of a custom/modified image of CoreDNS during upgrade. That is, if the user has modified the Corefile in the ConfigMap, those changes will not be retained (the user should back it up and redo the changes on the new ConfigMap).
+* Translation configuration of kube-dns to equivalent CoreDNS that is defined outside of the kube-dns ConfigMap. For example, modifications to the manifest or `dnsmasq` configuration.


Could be considered a breaking change and needs to be documented imo.

This should be required as there a users of kube-dns with the configmap, and their setups will break if this is not provided.

There isn’t anything that prevents them from continuing to use Kube-dns, which is backwards compatible.

I don’t think we should claim support for arbitrary customizations, and “customizer beware” is our default stance.

@bowei : we are converting the kube-dns ConfigMap to a CoreDns ConfigMap. this "non-goal" statement is to warn that a customized deployment of kube-dns with extra options on the cmd-lines of dnsmasq or kube-dns containers will not be translated.

in other words we support translation "StubDomains", "UpstreamNameServer" and "Federation" is supported.

To be clear - I read this as "we WILL support graceful upgrades from the kube-dns configmap, but we will NOT support upgrade from arbitrary other config" - is that right?

@thockin, yes. The options that can be configured in the kube-dns ConfigMap will be retained in the conversion to the Corefile. But we aren't going to tweak things for arbitrary config changes to the dnsmasq CLI options, etc. If the user has that, they should probably retain the kube-dns installation until they can upgrade in a more considered manner.

bowei · 2018-03-23T04:50:41Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Retaining the ConfigMap of a custom/modified image of CoreDNS during upgrade. That is, if the user has modified the Corefile in the ConfigMap, those changes will not be retained (the user should back it up and redo the changes on the new ConfigMap).
+* Translation configuration of kube-dns to equivalent CoreDNS that is defined outside of the kube-dns ConfigMap. For example, modifications to the manifest or `dnsmasq` configuration.


This should be required as there a users of kube-dns with the configmap, and their setups will break if this is not provided.

bowei · 2018-03-23T04:51:01Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+## Graduation Criteria
+
+* Passing all e2e conformance and DNS related tests.
+


Scalability tests

@bowei : what have you in mind ?

a manual scale test, as we did here : Add coredns proposal #1100 (comment) (using Kubemark)

or an extension of these perf-test for DNS (adapting those for CoreDNS) ?

or another kind of scalability included in kubernetes/tests/e2e ?

Sorry about the terseness, I mean that we should get the CoreDNS running as a part of regular k8s scale tests.

Having it possible to be run as target of perf-test for DNS would be great.

We have looked at the perf-test for DNS, we can do that but it will require a lot of changes to those tests. They are geared toward discovering/testing varying levels of resources devoted to dnsmasq and kube-dns.

I think we should have an integration style test for CoreDNS in that style given the surprises we've experienced wrt to resource limits etc from the past.

Note: there are two items:

CoreDNS as part of the regular k8s scale runs (e.g. up to 5k nodes)

Integration test style resource determination.

@bowei : Let me verify I understand your 2 points:

CoreDNS as part of the regular k8s scale runs (e.g. up to 5k nodes)

That means have CoreDNS be part of the regular k8s scale runs at 5k nodes
Therefore ensure we have a DNS e2e tests with the flag "[Feature:Performance]".
It will automatically run with all perf-tests like "ci-kubernetes-kubemark-gce-scale" (which is the one running 5k nodes with Kubemark)

integration test style resource determination

From this sentence, and your comment before, I understand you advise to extend those perf-test for DNS and create some dedicated tests for CoreDNS to measure the resources used by CoreDNS under stress of queries.

is my understanding correct ?

miekg · 2018-03-23T10:56:09Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+## Motivation
+
+* CoreDNS is more flexible and extensible than what kube-dns. 


drop "what" here.

miekg · 2018-03-23T10:58:44Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+### Goals
+
+* Have CoreDNS run as the default DNS server both after a new installation and an upgrade of the existing installation.
+* Make CoreDNS available as an [image in gcr.io](https://github.com/kubernetes/kubernetes/pull/59753) and define a workflow/process to update the CoreDNS versions in the future.


Should probably file a coredns issue for this as well.

@miekg : maybe, but I propose we wait to have a better understanding of who is doing what in the new process. Specifically who will have the responsibility to generating the image and push to gcr.io

We should probably keep a fork of CoreDNS in github.com/kubernetes (or in a new, related org) and cut our own containers from there. We should be doing that for everything we ship.

miekg · 2018-03-23T11:00:21Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+## Graduation Criteria
+
+* Passing all e2e conformance and DNS related tests.
+


autoscaling?

@miekg : autoscaling is generic and should work with coredns.
However I noticed an issue in the e2e tests of autoscaling with DNS - because the test itself waits for kube-dns to run. This issue will have to be fixed. See kubernetes/kubernetes#61176

smarterclayton · 2018-03-23T14:59:29Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+### Goals
+
+* Have CoreDNS run as the default DNS server both after a new installation and an upgrade of the existing installation.


+1 on this.

smarterclayton · 2018-03-23T15:00:50Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Retaining the ConfigMap of a custom/modified image of CoreDNS during upgrade. That is, if the user has modified the Corefile in the ConfigMap, those changes will not be retained (the user should back it up and redo the changes on the new ConfigMap).
+* Translation configuration of kube-dns to equivalent CoreDNS that is defined outside of the kube-dns ConfigMap. For example, modifications to the manifest or `dnsmasq` configuration.


There isn’t anything that prevents them from continuing to use Kube-dns, which is backwards compatible.

I don’t think we should claim support for arbitrary customizations, and “customizer beware” is our default stance.

thockin · 2018-03-23T20:56:40Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+* CoreDNS has fewer moving parts than kube-dns, taking advantage of the plugin architecture, making it a single executable and single process.
+* It is written in Go, making it memory-safe (kube-dns includes dnsmasq which is not). 
+* CoreDNS has [better performance](https://github.com/kubernetes/community/pull/1100#issuecomment-337747482) than [kube-dns](https://github.com/kubernetes/community/pull/1100#issuecomment-338329100) in terms of greater QPS, lower latency, and lower memory consumption. 
+* It supports a number of [use cases](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/) 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.


This is outside the DNS spec for Kube, so it is pretty irrelevant to this plan

thockin · 2018-03-23T20:57:55Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+### Goals
+
+* Have CoreDNS run as the default DNS server both after a new installation and an upgrade of the existing installation.
+* Make CoreDNS available as an [image in gcr.io](https://github.com/kubernetes/kubernetes/pull/59753) and define a workflow/process to update the CoreDNS versions in the future.


We should probably keep a fork of CoreDNS in github.com/kubernetes (or in a new, related org) and cut our own containers from there. We should be doing that for everything we ship.

thockin · 2018-03-23T20:59:50Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+### Non-Goals
+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Retaining the ConfigMap of a custom/modified image of CoreDNS during upgrade. That is, if the user has modified the Corefile in the ConfigMap, those changes will not be retained (the user should back it up and redo the changes on the new ConfigMap).


Agree - this is user-hostile. If you expose a ConfigMap you are publishing it as a mechanism to configure the app. If you intend to blow it away, you should just not expose it. at all.

Now we have to talk about defaults vs user-overrides.

thockin · 2018-03-23T21:01:10Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Retaining the ConfigMap of a custom/modified image of CoreDNS during upgrade. That is, if the user has modified the Corefile in the ConfigMap, those changes will not be retained (the user should back it up and redo the changes on the new ConfigMap).
+* Translation configuration of kube-dns to equivalent CoreDNS that is defined outside of the kube-dns ConfigMap. For example, modifications to the manifest or `dnsmasq` configuration.


To be clear - I read this as "we WILL support graceful upgrades from the kube-dns configmap, but we will NOT support upgrade from arbitrary other config" - is that right?

thockin · 2018-03-23T21:04:24Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+    * Supporting [Autopath](https://coredns.io/plugins/autopath/), which reduces the high query load caused by the long DNS search path in Kubernetes
+    * Making an alias for an external name [#39792](https://github.com/kubernetes/kubernetes/issues/39792)
+    * Dynamically adding services to another domain, without running another server [#55](https://github.com/kubernetes/dns/issues/55)
+    * Adding an arbitrary entry inside the cluster domain (for example TXT entries [#38](https://github.com/kubernetes/dns/issues/38))


I do not think we should document, endorse, or emphasize operations that do not go through Kubernetes API, except with the explicit warning that it is coredns specific and non-portable.

Ok. So are you thinking we should pull these from the KEP?

Maybe instead of listing the various extra features of CoreDNS, just link to a CoreDNS specific document. That way it's linked, but can be made clear it's out of scope for this KEP and k8s in general.

fturib · 2018-04-02T19:16:00Z

@bowei @thockin : the KEP has been updated with the comments. Can you have a second look to check it integrates all your concerns. Thanks!

rramkumar1 · 2018-04-05T21:18:54Z

keps/sig-network/0006-20180314-coredns-GA-proposal.md

+* Fate of kube-dns in future releases, i.e. deprecation path.
+
+## Graduation Criteria
+


Can we be more specific here? For example, can we say what is the minimum amount of test runs that need to pass before we say we are "passing all e2e conformance and DNS related tests". Similar for all criteria listed here. That way, there are clear numbers that need to be hit and there is no ambiguity.

@rramkumar1 Just to clarify:
I submit a PR to merge now making CoreDNS default in kubeadm, kube-up... to see if the tests are "passing" and if we're satisfied with the result, we keep the PR, else we revert.

And what is the right number of runs to determine it's a success?

@rramkumar1 : why would we need to specify "amount of test runs" ? I would think that one is enough no ? as long as all test are OK with CoreDNS then CoreDNS is acceptable.

Are you worry about kind of flaking tests ? or other commits that would interfere and failed some of the "conformance" tests (independently of DNS service) ?

To prevent to have a wrong view do to other errors )not linked to the DNS service), we could propose to have one of the "conformance" + "DNS" tests running with kube-dns and one with CoreDNS. so we can validate we have the same level of passing tests.

For e2e test, I would propose:

all tests filtered by "--ginkgo.skip=\[Slow\]|\[Serial\]|\[Disruptive\]|\[Flaky\]|\[Feature:.+\]"
(the regular tests "xxx-kubernetes-e2e-gce").

As the success of each test depends of the code itself (not only the DNS Service), we would verify that CoreDNS is equivalent to kube-dns in regards of the passed e2e tests. That means validate
"ci-kubernetes-e2e-gce-gci-ci-master" against the exact same test "ci-kubernetes-e2e-gce-gci-ci-master-kube-dns" with kube-dns deployed.

They are supposed to be always the same, or at least none of the success tests with kube-dns is failing with coredns.

fturib · 2018-04-12T21:30:33Z

@rramkumar1 : the point on e2e tests to validate is modified to be more precise. We are not proposing a sequence of run to be green, but rather a comparison for the same commit between CoreDNS and the former kube-dns : we want to validate that CoreDNS is able to replace kube-dns.

For the e2e performance tests, the same way, we just want that those performances are not hit by CoreDNS, in other words we want the test to stay green.

Let me know if you agree with the new verbiage.
Thanks!

rramkumar1 · 2018-04-16T14:49:19Z

@fturib LGTM. Thanks for clarifying!

cblecker · 2018-04-16T17:11:51Z

/ok-to-test

thockin · 2018-05-24T21:32:52Z

keps/sig-network/0010-20180314-coredns-GA-proposal.md

+
+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Translation configuration of kube-dns to equivalent CoreDNS that is defined outside of the kube-dns ConfigMap. For example, modifications to the manifest or `dnsmasq` configuration.
+* Fate of kube-dns in future releases, i.e. deprecation path.


Making coredns the default in every installer

thockin · 2018-05-24T21:33:36Z

one small nit - please xref the other KEP

rajansandeep · 2018-05-25T14:51:04Z

@thockin done.
Let me know if there are any other comments to be addressed for approval! Thanks!

johnbelamaric

A couple minor tweaks.

johnbelamaric · 2018-05-25T15:02:51Z

keps/sig-network/0010-20180314-coredns-GA-proposal.md

+creation-date: 2018-03-21
+last-updated: 2018-05-18
+status: provisional
+succeeded by: https://github.com/kubernetes/community/pull/2167


I think you were thinking of "superseded-by", but we don't want to use that in this KEP (it is for ones that get replaced by a new KEP). Instead use "see-also" (which takes a list).

johnbelamaric · 2018-05-25T15:03:34Z

keps/sig-network/0010-20180314-coredns-GA-proposal.md

+* Translation of CoreDNS ConfigMap back to kube-dns (i.e., downgrade).
+* Translation configuration of kube-dns to equivalent CoreDNS that is defined outside of the kube-dns ConfigMap. For example, modifications to the manifest or `dnsmasq` configuration.
+* Fate of kube-dns in future releases, i.e. deprecation path.
+* Making CoreDNS the default in every installer.


Reference/link the new KEP here too.

fturib · 2018-05-29T14:18:10Z

@johnbelamaric : the KEP was updated following your comments. Can you review/verify/approve ? thanks!.

KEP coredns for GA only

thockin · 2018-05-31T00:09:42Z

/lgtm
/approve

k8s-ci-robot · 2018-05-31T00:09:47Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thockin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~keps/sig-network/OWNERS~~ [thockin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

fturib · 2018-05-31T00:32:03Z

Thanks @thockin !

Automatic merge from submit-queue (batch tested with PRs 63445, 63820). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. DNS record scale test **What this PR does / why we need it**: Adds e2e scalability test for querying DNS with a scaled up number of records. Specifically, it creates ~~30 services per node~~ 10000 services, then queries the cluster DNS and validates the response. This relates to a graduation criteria listed in kubernetes/community#1956. **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: none **Special notes for your reviewer**: **Release note**: ```release-note NONE ```

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Mar 21, 2018

k8s-ci-robot requested review from caseydavenport and thockin March 21, 2018 17:22

k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Mar 21, 2018

k8s-ci-robot added the sig/network Categorizes an issue or PR as relevant to SIG Network. label Mar 21, 2018

k8s-github-robot added the sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. label Mar 21, 2018

johnbelamaric reviewed Mar 21, 2018

View reviewed changes

fturib mentioned this pull request Mar 22, 2018

Make kubeadm config imageRepository can implement coredns kubernetes/kubernetes#59753

Closed

stp-ip approved these changes Mar 22, 2018

View reviewed changes

bowei reviewed Mar 23, 2018

View reviewed changes

miekg reviewed Mar 23, 2018

View reviewed changes

smarterclayton reviewed Mar 23, 2018

View reviewed changes

thockin reviewed Mar 23, 2018

View reviewed changes

rramkumar1 mentioned this pull request Mar 26, 2018

sig-network needs clearly defined roadmap for Alpha -> Beta -> GA #1837

Closed

fturib mentioned this pull request Apr 4, 2018

Enable CoreDNS as default - when k8s is installed with kube-up kubernetes/kubernetes#62147

Closed

rramkumar1 reviewed Apr 5, 2018

View reviewed changes

k8s-ci-robot removed the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Apr 16, 2018

fturib mentioned this pull request Apr 17, 2018

Enable CoreDNS as a DNS plugin for Kubernetes kubernetes/enhancements#427

Closed

caseydavenport approved these changes Apr 18, 2018

View reviewed changes

MrHohn mentioned this pull request Apr 19, 2018

e2e network/config-map - adapt the ConfigMap change depending the kind of DNS Server running. kubernetes/kubernetes#62865

Closed

fturib mentioned this pull request Apr 24, 2018

CoreDNS - Add 2 e2e jobs running kube-dns for comparisons kubernetes/test-infra#7838

Closed

chrisohaver mentioned this pull request May 18, 2018

Add jobs for CoreDNS scalability tests kubernetes/test-infra#8078

Closed

rajansandeep mentioned this pull request May 18, 2018

KEP for CoreDNS to Default DNS #2167

Merged

rajansandeep force-pushed the corednskep branch 2 times, most recently from 8bd12a2 to af066fe Compare May 23, 2018 14:59

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 23, 2018

rajansandeep force-pushed the corednskep branch from af066fe to e1ee703 Compare May 23, 2018 15:02

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 23, 2018

johnbelamaric approved these changes May 23, 2018

View reviewed changes

thockin reviewed May 24, 2018

View reviewed changes

rajansandeep force-pushed the corednskep branch from e1ee703 to 660c858 Compare May 25, 2018 14:48

johnbelamaric suggested changes May 25, 2018

View reviewed changes

rajansandeep force-pushed the corednskep branch from 660c858 to e2b64f3 Compare May 25, 2018 15:13

johnbelamaric approved these changes May 29, 2018

View reviewed changes

fturib approved these changes May 29, 2018

View reviewed changes

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 30, 2018

rajansandeep force-pushed the corednskep branch from e2b64f3 to 46da38b Compare May 30, 2018 22:01

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 30, 2018

initial commit

46da38b

KEP coredns for GA only

k8s-ci-robot assigned thockin May 31, 2018

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 31, 2018

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 31, 2018

k8s-ci-robot merged commit bc690fa into kubernetes:master May 31, 2018

rajansandeep mentioned this pull request Oct 25, 2018

Add e2e tests for kube-dns for comparison with CoreDNS kubernetes/test-infra#9921

Merged


		## Motivation

		* CoreDNS is more flexible and extensible than what kube-dns.

		## Graduation Criteria

		* Passing all e2e conformance and DNS related tests.


		### Goals

		* Have CoreDNS run as the default DNS server both after a new installation and an upgrade of the existing installation.

		* Fate of kube-dns in future releases, i.e. deprecation path.

		## Graduation Criteria

KEP for CoreDNS to GA. #1956

KEP for CoreDNS to GA. #1956

Conversation

rajansandeep commented Mar 21, 2018 • edited Loading

rajansandeep commented Mar 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fturib commented Mar 21, 2018 • edited Loading

fturib commented Mar 22, 2018

stp-ip left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CoreDNS as part of the regular k8s scale runs (e.g. up to 5k nodes)

integration test style resource determination

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fturib commented Apr 2, 2018

rramkumar1 Apr 5, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fturib commented Apr 12, 2018

rramkumar1 commented Apr 16, 2018

cblecker commented Apr 16, 2018

Choose a reason for hiding this comment

thockin commented May 24, 2018

rajansandeep commented May 25, 2018

johnbelamaric left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fturib commented May 29, 2018

thockin commented May 31, 2018

k8s-ci-robot commented May 31, 2018

fturib commented May 31, 2018

rajansandeep commented Mar 21, 2018 •

edited

Loading

fturib commented Mar 21, 2018 •

edited

Loading

rramkumar1 Apr 5, 2018 •

edited

Loading