Code change:
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, "The path to the configuration file.") fs.StringVar(&o.WriteConfigTo, "write-config-to", o.WriteConfigTo, "If set, write the default configuration values to this file and exit.") fs.StringVar(&o.config.ClientConnection.Kubeconfig, "kubeconfig", o.config.ClientConnection.Kubeconfig, "Path to kubeconfig file with authorization information (the master location can be overridden by the master flag).") <del> fs.StringVar(&o.config.ClusterCIDR, "cluster-cidr", o.config.ClusterCIDR, "The CIDR range of pods in the cluster. When configured, traffic sent to a Service cluster IP from outside this range will be masqueraded and traffic sent from pods to an external LoadBalancer IP will be directed to the respective cluster IP instead") </del> <ins> fs.StringVar(&o.config.ClusterCIDR, "cluster-cidr", o.config.ClusterCIDR, "The CIDR range of pods in the cluster. When configured, traffic sent to a Service cluster IP from outside this range will be masqueraded and traffic sent from pods to an external LoadBalancer IP will be directed to the respective cluster IP instead. This parameter is ignored if a config file is specified by --config.") </ins> fs.StringVar(&o.config.ClientConnection.ContentType, "kube-api-content-type", o.config.ClientConnection.ContentType, "Content type of requests sent to apiserver.") fs.StringVar(&o.master, "master", o.master, "The address of the Kubernetes API server (overrides any value in kubeconfig)") fs.StringVar(&o.hostnameOverride, "hostname-override", o.hostnameOverride, "If non-empty, will use this string as identification instead of the actual hostname.")

Related discussion:
text: Start service with a config file without specifying the argument in the config file, instead, pass the value via the CLI args, the value is just ignored, for example, I have a config file as this, NOTE: I have not specified the in the config file, but give a value for the via the CLI, the proxy mode is still set as after the service is started. The reason for this is that CLI args is parsed before the loading of the config file, if the config file haven't specified the or leave it as empty, then it will be use the default value instead. Two choices from my side, Add a note somewhere, maybe where the option is defined, just say that the CLI args will be ignored when the config file is provided regardless the option is specified in the config file or not (this should be noted for lots of options). Merge the value passed from CLI with the config file if the option has an empty value, but we need to consider the backward compatibility. and check which mode is effective. No response_ vanilla deployment with code in the upstream. <details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig network Hey Tim, WDYT? /assign
Heh, this is a recurrent topic :smile: , you did a great analysis: I think that explains here why merging flags and config overriding defaults is not a desirable option (the whole thread is worth reading) I'm in favor of documenting the behavior
thanks for showing the earlier thread, I have created a simple PR to document this in the CLI option.