kubernetes/kops · error

getting rest config: %w

Error message

getting rest config: %w

What it means

RunRollingUpdateCluster builds a Kubernetes client to drain/validate nodes. When rolling-update is not in CloudOnly mode, it first obtains a REST config for the target cluster via f.RESTConfig; failure to construct that config (typically no usable admin kubeconfig/credentials for the cluster) aborts with this wrapped error.

Source

Thrown at cmd/kops/rolling-update_cluster.go:253

}

func RunRollingUpdateCluster(ctx context.Context, f *util.Factory, out io.Writer, options *RollingUpdateOptions) error {
	clientset, err := f.KopsClient()
	if err != nil {
		return err
	}

	cluster, err := GetCluster(ctx, f, options.ClusterName)
	if err != nil {
		return err
	}

	var nodes []v1.Node
	var k8sClient kubernetes.Interface
	if !options.CloudOnly {
		restConfig, err := f.RESTConfig(ctx, cluster, options.CreateKubecfgOptions)
		if err != nil {
			return fmt.Errorf("getting rest config: %w", err)
		}

		httpClient, err := f.HTTPClient(restConfig)
		if err != nil {
			return fmt.Errorf("getting http client: %w", err)
		}

		k8sClient, err = kubernetes.NewForConfigAndClient(restConfig, httpClient)
		if err != nil {
			return fmt.Errorf("getting kubernetes client: %w", err)
		}

		nodeList, err := k8sClient.CoreV1().Nodes().List(ctx, metav1.ListOptions{})
		if err != nil {
			fmt.Fprintf(os.Stderr, "Unable to reach the kubernetes API.\n")
			fmt.Fprintf(os.Stderr, "Use --cloudonly to do a rolling-update without confirming progress with the k8s API\n\n")
			return fmt.Errorf("error listing nodes in cluster: %v", err)
		}

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Refresh admin credentials: `kops export kubecfg <cluster> --admin` (or `kops get credentials` per version) and retry.
  2. Verify the cluster name/`--name` and KOPS_STATE_STORE match the target cluster.
  3. Ensure the kubeconfig on disk (KUBECONFIG) points to the cluster and is readable.
  4. If you only need cloud-side rebooting and cannot reach the API server, re-run with `--cloudonly` (accepting that node draining is skipped).

Example fix

# before
kops rolling-update cluster mycluster.example.com --yes
// getting rest config: ...
# after
kops export kubecfg mycluster.example.com --admin
kops rolling-update cluster mycluster.example.com --yes
Defensive patterns

Strategy: fallback

Validate before calling

// Ensure a working admin kubeconfig before rolling update
if _, err := os.Stat(kubeconfigPath); err != nil {
    exec.Command("kops", "export", "kubecfg", clusterName, "--admin").Run()
}

Try / catch

err := runRollingUpdate(...)
if err != nil && strings.Contains(err.Error(), "getting rest config") {
    // fall back to cloud-only rolling update (skips drain/validation)
    log.Printf("no API access (%v); retrying with --cloudonly", err)
    return runRollingUpdateCloudOnly(...)
}

Prevention

When it happens

Trigger: `kops rolling-update cluster` without --cloudonly when the admin kubeconfig is missing, expired, or unreadable: cluster never had kubecfg generated, `kops export kubecfg --admin` not run or expired (admin credentials typically expire after ~15m-18h), wrong KOPS_STATE_STORE so kubeconfig can't be located/refreshed.

Common situations: Running rolling-update from a fresh CI machine with no kubeconfig; admin certificate expired after waiting too long between export and update; cluster name mismatch so the wrong kubeconfig context is used; VPC/network changes preventing even config assembly from the state store.

Related errors


AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/dcd609e65012d571. Report an issue: GitHub.