Daemons may have multiple config files. An example is that the scheduler will pull in 'config', 'apiserver', and 'scheduler'. In that order. Each file may overwrite the values of the previous file. The 'config' file is sourced by all daemons. The kube-apiserver config file is sourced by those daemons which must know how to reach the kube-apiserver. Each daemon has its own config file for configuration specific to that daemon.
4. There is no default for the IP address range of services. This uses 10.254.0.0/16 see: [KUBE_SERVICE_ADDRESSES](environ/apiserver)
Notes
-----
It may seem reasonable to use --option=${OPTION} in the .service file instead of only putting the command line option in the environment file. However this results in the possiblity of daemons being called with --option= if the environment file does not define a value. Whereas including the --option string inside the environment file means that nothing will be passed to the daemon. So the daemon default will be used for things unset by the environment files.
While some command line options to the daemons use the default when passed an empty option some cause the daemon to fail to launch. --allow_privileged= (without a value of true/false) will cause the kube-apiserver and kubelet to refuse to launch.
It also may seem reasonable to just use $DAEMON_ARGS and string all of these into one line in the environment file. While that makes the .service file simple it makes the admin job more difficult to locate and make appropriate changes to the config. This is a tradeoff between having to update the .service file to add new options or having the config files easy for an admin to work with. I choose: "easy for admin most of the time".
