WIP: prune dns-controller

[justinsb]

When switching from gossip to dns=none, the rolling-update fails because the dns-controller addon is still present (because it isn't removed, as we never merged #13962). However, the configuration for the dns-controller addon still assumes gossip is running on protokube (which it isn't).

WIP because there are a few ways to tackle this: we could implement addon removal (but I would rather we did it very carefully, perhaps with explicit removal). We could simply keep dns-controller but not install it. Or we could do what we do here - install a different (empty) manifest.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from justinsb. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[johngmyers]

Couldn't one start with gossip plus external-dns?

[johngmyers]

I can't find validation preventing gossip + external-dns, but external-dns doesn't have gossip configuration support.

[johngmyers]

Still, switching from external-dns to none should probably uninstall external-dns.

[johngmyers]

Okay, this is confusing. There's ExternalDNSProviderNone, which is different than DNSTypeNone. Changing the ExternalDNS.Provider should probably prune any previous provider, though this is arguably a separate PR.

[hakman]

DNSTypeNone means no DNS work at all. Anyone that wants to use external DNS is free to deploy it on its own.

[zetaab]

@justinsb fyi:

in case of AWS there is some downtime:

In case of AWS the nodes will lose its connection to control plane.

OpenStack migration is almost working:

I have executed gossip -> dns none to about 100+ openstack clusters. The only problem that I saw was that kops-controller goes to crashloopbackoff and that will block the rolling-update. The solution for that was that I just terminated the instance where that was located and when new controlplane instance started the problem was gone. Sometimes it happened after first control plane instance update, sometimes after 2 control plane instance updates and sometimes it was working. So it was kind of random when it went through.

[k8s-ci-robot]

@justinsb: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kops-test	47f36f9	link	true	/test pull-kops-test
pull-kops-e2e-k8s-aws-calico	47f36f9	link	true	/test pull-kops-e2e-k8s-aws-calico
pull-kops-kubernetes-e2e-ubuntu-gce-build	47f36f9	link	true	/test pull-kops-kubernetes-e2e-ubuntu-gce-build

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten