MasterConfiguration parameters not propagated to /var/lib/kubelet/config.yaml #1077
Labels
priority/awaiting-more-evidence
Lowest priority. Possibly useful, but not yet enough support to actually get it done.
What keywords did you search in kubeadm issues before filing this one?
"MasterConfiguration", "swap", "KubeletConfiguration"
This may be related to #1028 and #1066 although in both those cases there is an explanation provided for the non-overrides (security enforced defaults and typo, respectively).
Is this a BUG REPORT or FEATURE REQUEST?
BUG REPORT
Versions
kubeadm version (use
kubeadm version
):Environment:
kubectl version
):Cloud provider or hardware configuration: Single VM node.
OS (e.g. from /etc/os-release):
uname -a
):Linux kubehead0 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
What happened?
While trying to start a master node in a VM with swap on, parameters from the config passed to
kubeadm init
were not making it into/var/lib/kubelet/config.yaml
. This resulted in the kubelet service remaining in a crashloop as thefailSwapOn
parameter was set totrue
.The configuration passed to
kubeadm init
is below:The error returned by kubelet was:
This error stopped
kubeadm init
from completing successfully.By manually editing the
/var/lib/kubelet/config.yaml
(settingfailSwapOn: false
) while kubelet was in a crashloop, the service was able to start andkubeadm init
to finish successfully.What you expected to happen?
I would expect the
failSwapOn: false
option specified in the configuration passed tokubeadm init
to be reflected in/var/lib/kubelet/config.yaml
.How to reproduce it (as minimally and precisely as possible)?
At this point kubelet does not exit the crashloop state due to the swap unsupported failure.
By editing
/var/lib/kubelet/config.yaml
at this point and settingfailSwapOn: false
, kubelet will start andkubeadm init
will complete successfully.The text was updated successfully, but these errors were encountered: