container k8s create handles failures differently depending on when they happen. An error while provisioning the node, running kubeadm init or waiting for readiness tears the node container down and removes any partial kubeconfig. If only the kubeconfig write fails, it logs a warning, leaves the cluster running and points to write-config. It also loads system config from local defaults, not from the daemon's roots as the main CLI does.

Impact: An operator who hits a kubeconfig failure gets a running cluster with no obvious error, and only a log line points them to the fix; anyone scripting create has to check for that case separately from every other failure, which tears everything down.

Recommendation (small effort): Have create surface the kubeconfig failure at error level (not just a warning) and print the write-config recovery command to standard error, so the difference between "nothing happened" and "cluster is up but unconfigured" is visible without reading logs.