This means that the object is not mutated after construction, making
it easier to do validity checks (such as whether we have mounted the
same path twice).
We generate a kube-scheduler configuration file in the kops CLI, and
nodeup will use it if provided (instead of generating one).
We put the configuration file into the fileAssets.
Users can provide a kube-scheduler configuration in additional
objects, and this will be used as the base configuration (we add the
kubeconfig path).
Issue #13352
Co-authored-by: Ciprian Hacman <ciprian@hakman.dev>
* check if UsePolicyConfigMap flag is true
* use suggested changes
Co-authored-by: Ciprian Hacman <ciprian@hakman.dev>
Co-authored-by: Ciprian Hacman <ciprian@hakman.dev>
Mentioned in #6942
This change allows using the --config flag and a generated configfile to set
options that were not previously supported and the use via flags is deprecated.
(https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
I thought that it might be better to have them in a config file to ensure
support in newer kubernetes versions.
It also makes it easy to add more.
klog can now support logging both to a file and to streams, so we get the output both in docker & logfiles.
A few gotchas:
* The output previously was all on stdout, now it on stderr. That is more correct
* If something writes to stdout or stderr outside of klog, it will no longer end up in the logfile.
* There's some oddities still to be ironed out about the flag syntax https://github.com/kubernetes/klog/issues/60
For the master pods (apiserver, controller manager, scheduler) this is
unlikely to ever matter (the masters aren't expected to run out of
resources and need to evict things) but evictions of kube-proxy from worker
nodes are easy to trigger in clusters with PodPriority enabled. Since these
are static pods the configuration is also somewhat difficult to change.