Change:
package upgrade import ( <ins> "fmt" </ins> "os" "github.com/coredns/corefile-migration/migration"

Discussion:
Any ideas how to solve this?
What does your look like?
/assign
I see that the plugin is present in the config. From what version of Kubernetes are you upgrading from?
I was on 1.15.3 and now trying upgrading to 1.15.4 first. Edit: I'm now on 1.15.4 but upgrade doesn't work to 1.16.0. I don't know what proxy plugin is... must be something that is comming automatic.
The preflight check is showing due to the presence of the plugin, as it has been deprecated. The plugin is to be used in its place. If the is the same as you've mentioned , you can use the while upgrading. The plugin will be replaced to use automatically.
Worked for me. Looks like all services are back up :-) Thanks!
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Having the same issue here. I installed clean k8s 1.13.4 , didn't install or anything. Just upgraded to 1.14.7, then to 1.15.4 and now see the same issue trying to upgrade to 1.16.0
Found and follow ups. removed from configMap kube-system/coredns no more complaints
Seems, I was a little bit to fast. After upgrading I saw a lot of errors in the coredns POD logs and (external) DNS resolution didn't work at all: Then I : Forwarding all requests to the nameservers in the nodes So the solution is replace in : with: see also:
I am having a similar issue, but this is related to rewrite plugin, which I believe is supported in the newer coredns version as well. I can workaround by skipping (or removing rewrite rule and adding it back again). Let me know if you want me to create a new issue to track this, or if this is already tracked. Kubernetes upgrade from 1.15.3 to 1.16.2 kubeadm upgrade plan coreFile
Yes, the upgrade should happen smoothly by just skipping the preflight check.

I’ll improve the functionality of the preflight check since more than a few users are having trouble with this. /reopen
Reopened this issue. <detailsIn response to : Yes, the upgrade should happen smoothly by just skipping the preflight check. I’ll improve the functionality of the preflight check since more than a few users are having trouble with this. /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/area kubeadm /sig cluster-lifecycle
Hi , I have the same issue here due to the plugin of coredns that is reported as unsupported. My coredns config: Result of Kubadm version: If I change my coredns configuration to remove usage of plugin, the upgrade plan works: I don't think plugin is unsupported by Coredns, unless I'm missing something.
Hosts is not currently supported by the . However, the presence of a plugin that is not supported by migration library should not be preventing the kubeadm upgrade from proceeding if you use the flag, per .
+1 Lets treat ignoring the error as the workaround users should do, for this unsupported scenario. /close
Closing this issue. <detailsIn response to : +1 Lets treat ignoring the error as the workaround users should do, for this unsupported scenario. </details
Sounds good. FWIW, The original reasoning for requiring the explicit ignoring of the pre-flight check was to make the user aware of the risk that proceeding with the upgrade could result in an invalid Corefile. So, in that sense, its working as intended, but the error message is perhaps too cryptic. Currently: "There are unsupported plugins in the CoreDNS Corefile" What was intended to be conveyed: "There are plugin configurations in the CoreDNS Corefile that cannot be migrated. Continuing with the upgrade without migrating those plugin configurations could result in an invalid Corefile and therefore DNS interruption."
I think improving the message is fine or even enumerating which plugins.
Why was this closed? As I understand the issue, kubeadm fails to upgrade without additional options because of a configuration that was created by a previous kubeadm?
i don't believe this part is true.

the "hosts" plugin is not part of the kubeadm 1.16 manifests, so it's user :
hosts is, but proxy was in the default:
the proxy plugin is mentioned as deprecated:
I know, but ignoring the preflight warning makes the upgrade go through just fine, including migration the ConfigMap. So what is the point of the warning?
I think the migration logic in kubeadm checks the supportability of the current config in all versions from the starting point to the destination - hence kubeadm was alerting incorrectly about proxy, which would have been valid in the current version, but then deprecated/removed by the destination version. It should instead check only the starting point - ensuring that there are no unsupported plugins present in the start version.
please reopen this issue if you think there are PRs that we should sent.
Yes after looking at the related code, it looks like kubeadm uses a "dry run" call to in the preflight check to see if there are any unsupported plugins. It should probably instead call , for the starting version only. /reopen
Reopened this issue. <detailsIn response to : Yes after looking at the related code, it looks like kubeadm uses a "dry run" call to in the preflight check to see if there are any unsupported plugins. It should probably instead call , for the starting version only. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Something didn't seem right about my explanation above so I took a second look - looks like there are two preflight checks. One dry run call to , which is OK as is. There is another preflight check, that calls . It is called with both the starting version and destination version, which checks if the existing config contains any plugins that are unsupported in any version from start to destination. Instead it should be called with only the starting version.
Totally agree with that. When I got the error, I did not know what to do. I had to go on google and hopefully found this post. I removed "proxy" module myself in configuration file, but the issue persisted. I had to look at the code to understand why I got this error. This is not something I should need to do.

Providing the list of unsuported modules would be a good starting point, because we would know why the preflight check is failing. Also, a more explicit error message would be great as well. If I understand well, the message could be something like this: "There are plugin in the CoreDNS Corefile that are not supported by Kubeadm or are deprecated in the next release. Please, review your CoreDNS configuration against Changelog to ensure all your plugins are supported by the new version of CoreDNS" (English is not my native language, so you may found better formulation).
Thanks, Just to summarize, there are two issues raised here: is a in kubeadm's CoreDNS configuration migration preflight check. When the proxy plugin is in use, the preflight check falsely alerts that the proxy plugin is not supported by the configuration migration when in fact it is - the migration will automatically replace proxy with the forward plugin. The workaround for this issue now is to ignore the false warning - i.e. skip the preflight check. plugins that are actually not supported by the configuration migrator (e.g. hosts for now), the warning is cryptic and should be expanded/rephrased to more clearly convey the following: The corefile contains plugins that kubeadm/CoreDNS does not know how to migrate. A list of those plugins should be provided in the preflight check message. To be safe, each plugin listed should be manually verified for compatibility with the newer version of CoreDNS. Once ready, the upgrade can be initiated by skipping the preflight check. During the upgrade, kubeadm will migrate the configuration while leaving the listed plugin configs untouched, but cannot guarantee that they will work with the newer version of CoreDNS. Perhaps a link to more detailed documentation if it gets too hard to succinctly explain this (could go in coredns/corefile-migration).