refactor: make kube-dns addon user-configurable#2393
refactor: make kube-dns addon user-configurable#2393jackfrancis merged 2 commits intoAzure:masterfrom
Conversation
|
/hold |
jackfrancis
force-pushed
the
addons-kube-dns
branch
from
5ff7055 to
67ccae3
Compare
Codecov Report
@@ Coverage Diff @@
## master #2393 +/- ##
==========================================
+ Coverage 72.08% 72.11% +0.03%
==========================================
Files 130 130
Lines 23341 23350 +9
==========================================
+ Hits 16825 16840 +15
+ Misses 5491 5488 -3
+ Partials 1025 1022 -3 |
|
/hold release |
|
/hold cancel |
| // First, Configure addons | ||
| cs.setAddonsConfig(isUpgrade) | ||
| // Defaults enforcement flows below inherit from addons configuration, | ||
| // so it's critical to enforce default addons configuration first |
There was a problem hiding this comment.
We're sure this comment enforce default addons configuration first is no longer true?
There was a problem hiding this comment.
Thank you for noticing this, forgot to add commentary.
Yes, specifically, kube-dns inherits some of its configuration from the kubelet config (I think it's correct to say that the kubelet config is the source of truth). Before this change, the sources of truth were held by various actors during runtime template generation, and then eventually the potato was mashed via sed into the yaml on disk.
I did some investigation based on the comments about addons needing to be first and they were overblown. Basically, all of these serially enforced default flows have to arranged rationally, such that changes to one area that may affect another area are reconciled. (See the // Pool-specific defaults that depend upon OrchestratorProfile defaults comment above for an example.)
Unfortunately we don't have any useful graph interfaces for expressing this, and so we are doing it by manually ordering imperative commands, and then (hopefully) writing comprehensive tests to validate the various inter-dependent default enforcements behave the way we want them to.
:(
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis, mboersma The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Related to #2251 |
3 participants
Reason for Change:
This PR makes the
kube-dnscomponent a user-configurable addon, exposed via the existingkubernetesConfig.addonsinterface.The existing "disable if 1.12" functionality has been carried over via addons upgrade defaults enforcement. This is a temporary arrangement (though functionally equivalent to what we do at present) until coredns is similarly converted to a user-configurable addon. At which point, we should consider relaxing the strict "you may only run kube-dns < 1.12 and you must run coredns if > 1.11" requirement. I.e., we should give users a choice to use either kube-dns or coredns (but default to coredns, as 1.12 support is going away soon anyways).
Issue Fixed:
Requirements:
Notes: