kubernetes/kops · error

unexpected object type for Cluster %q: %T

Error message

unexpected object type for Cluster %q: %T

What it means

After successful decoding, fullClusterSpecs asserts the decoded object is a *kopsapi.Cluster. If the codec returned a different runtime.Object type (e.g. an InstanceGroup or a different registered kind stored at that path), it returns 'unexpected object type for Cluster %q: %T'. This guards against state-store content placed at the wrong key.

Source

Thrown at cmd/kops/get_cluster.go:302

	for _, cluster := range clusters {
		configBase, err := registry.ConfigBase(vfsContext, cluster)
		if err != nil {
			return nil, fmt.Errorf("error reading full cluster spec for %q: %v", cluster.ObjectMeta.Name, err)
		}
		configPath := configBase.Join(registry.PathClusterCompleted)
		b, err := configPath.ReadFile(ctx)
		if err != nil {
			return nil, fmt.Errorf("error loading Cluster %q: %v", configPath, err)
		}

		o, _, err := kopscodecs.Decode(b, nil)
		if err != nil {
			return nil, fmt.Errorf("error parsing Cluster %q: %v", configPath, err)
		}
		if fullSpec, ok := o.(*kopsapi.Cluster); ok {
			fullSpecs = append(fullSpecs, fullSpec)
		} else {
			return nil, fmt.Errorf("unexpected object type for Cluster %q: %T", configPath, o)
		}
	}
	return fullSpecs, nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

1. Inspect the object at the config path (`aws s3 cp`/`gsutil cat`) and check its `kind:` field — it must be `Cluster`.
2. Restore the correct cluster-completed.spec from backup or regenerate it with `kops update cluster <name>`.
3. Verify the state store prefix isn't mixing files from multiple clusters.
4. Use a matching kops binary version for the cluster's creation version.

Example fix

// before
# kind: InstanceGroup stored at cluster-completed.spec
// after
# restore correct spec
aws s3 cp correct-cluster-completed.spec s3://bucket/mycluster.example.com/cluster-completed.spec

# confirm the object at the config path is kind: Cluster
aws s3 cp "s3://bucket/mycluster.example.com/cluster-completed.spec" - | head -5 | grep -q '^kind: Cluster$' \
  || { echo "wrong object kind at cluster-completed.spec" >&2; exit 1; }

null

if ! kops get cluster "$CLUSTER" --full 2>err.txt; then
  grep -q 'unexpected object type' err.txt && \
    echo "object at cluster-completed.spec is not a Cluster manifest; restore or regenerate via kops update"
fi

When it happens

Trigger: `kops get cluster X --full` where the object at <configBase>/cluster-completed.spec decodes to a non-Cluster kops object — typically because someone wrote an unrelated manifest (e.g. instancegroup spec) to that path, or a kops version stored a different type there.

Common situations: Manual state-store surgery (copying files between cluster prefixes); custom tooling writing specs; kops version drift changing the stored object kind.

Related errors

• error loading Cluster %q: %v
• reading file %v: %w
• error loading NodeupConfig %q: %v
• error creating cluster: %v
• error querying cluster %q: %v

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