real dynamic client to get the object. If a real object does not
exist it attempts to get the object from the fake object store.

The above message is copied from the PR's description. It‘s not truth when the real client is instantiated and the given object doesn't exist in the cluster, it will mark the action as handled.

// handleGetAction tries to handle all GET actions with the dynamic client.
func (d *DryRun) handleGetAction(action testing.GetAction) (bool, runtime.Object, error) {
	if d.dynamicClient == nil {
		return false, nil, errors.New("dynamicClient is nil")
	}

	unstructuredObj, err := d.dynamicClient.
		Resource(action.GetResource()).
		Namespace(action.GetNamespace()).
		Get(context.Background(), action.GetName(), metav1.GetOptions{})
	if err != nil {
		return true, nil, err
	}

	newObj, err := d.decodeUnstructuredIntoAPIObject(action, unstructuredObj)
	if err != nil {
		return true, nil, err
	}

	return true, newObj, err
}

According to the implementation, it attempts to GET or LIST using the real dynamic client if it is instantiated, otherwise tries to GET or LIST the object from the fake client store. Is it desired?

Sorry, I didn't see the caller.

				handled, obj, err := d.handleGetAction(getAction)
				if err != nil {
					fmt.Fprintln(d.writer, "[dryrun] Real object does not exist. "+
						"Attempting to GET from followup reactors or from the fake client tracker")
					return false, nil, nil
				}

Please ingore above comments.

In dry-run mode, d.KubeConfigPath() always returns the kubeconfig path from a kubeadm tmp dir.

I'm not sure whether the created client is able to talk with the real cluster?

Do sub phases under init phase need a real cluster when a user run a sub phase with the --dry-run flag.

I'm not sure whether the created client is able to talk with the real cluster?

yes, it's a generated admin.conf, it just resides in the tmp dir.

Do sub phases under init phase need a real cluster when a user run a sub phase with the --dry-run flag.

that's a good Q because there is a problem with this it seems.
the phases can work with dry-run but the admin.conf in the TMP dir doesn't exist.

here is what happens:

sudo kubeadm init phase upload-config all --dry-run
error execution phase upload-config/kubeadm: failed to load kubeconfig: open /etc/kubernetes/tmp/kubeadm-init-dryrun3932008713/admin.conf: no such file or directory

so the CA and admin.conf don't exist for this scoped phase dry-run.
but sudo kubeadm init --dry-run as a whole would work as that tmp dir admin.conf will exist ad KubeConfigPath will return it.

even if the user runs:

sudo kubeadm init phase certs ca
sudo kubeadm init phase kubeconfig admin

sudo kubeadm init phase upload-config all --dry-run
error execution phase upload-config/kubeadm: failed to load kubeconfig: open /etc/kubernetes/tmp/kubeadm-init-dryrun3932008713/admin.conf: no such file or directory

it would fail as the non-dry-run commands generated a CA/kubeconfig in the default location /etc/kubernetes/

but the --dry-run is looking for an admin.conf that exists in the tmp dir.

i think to avoid this problem the logic in init.go can check if the tmp dir file exists and if it doesn't it can fall back to the default /etc/kubernetes/admin.conf

i need to test this idea or find a better one..

@carlory so i approached this differently. the problem is that a tmp dir is used for many files not only the admin.conf.

i think the only way to allow running individual phases in dry-run mode is to allow the user to specify the dry-run directory. we already had an env variable for that called KUBEADM_INIT_DRYRUN_DIR. i just added new ones for UPGRADE and JOIN as well. so here is how this can be used.

lubo@3B69Q73:~/go/src/k8s.io/kubernetes$ sudo kubeadm init phase certs ca --dry-run
W0925 15:27:34.028290  147394 constants.go:610] Using dry-run directory /etc/kubernetes/tmp/kubeadm-init-dryrun1123083720. To override it, set the environment variable KUBEADM_INIT_DRYRUN_DIR
[certs] Using existing ca certificate authority

lubo@3B69Q73:~/go/src/k8s.io/kubernetes$ sudo ls /etc/kubernetes/tmp/kubeadm-init-dryrun1123083720
ca.crt  ca.key
lubo@3B69Q73:~/go/src/k8s.io/kubernetes$ sudo KUBEADM_INIT_DRYRUN_DIR=/etc/kubernetes/tmp/kubeadm-init-dryrun1123083720
kubeadm init phase kubeconfig all --dry-run
[kubeconfig] Using kubeconfig folder "/etc/kubernetes/tmp/kubeadm-init-dryrun1123083720"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "super-admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file

so when not setting the env var a random dir is generted, but if the env var is set it can be used for phase dry-run.

i will push an update in a bit.

What's the purpose of isTesting? Can we remove it?

it's a left over from when i was testing with different ways to make the changes in token.go. i will remove it.

actually, it has a purpose. without it the function retrieveValidatedConfigInfo is difficult to unit test.
during tests retrieveValidatedConfigInfo gets isDryRun = false and isTesting = true, that results in no loading of additional kubeconfig files (retrieveValidatedConfigInfo loads kubeconfig files). during tests client is a fake client and during real usage client is a dryRun client. getClusterInfo() is called from retrieveValidatedConfigInfo() which complicates it further.

ideas to improve this are welcome, but i think it might be suitable for a new PR that would refactor / break apart retrieveValidatedConfigInfo. perhaps in multiple functions.

Is it possible to move the creating client logic to InitCfg() ?

yes, makes sense

moved this to fetchInitConfigurationFromJoinConfiguration as that func also needs tlsBootstrapCfg.

typo

Should file path be quoted using %q?