kubernetes/kops · error
unhandled kind %q in %q
Error message
unhandled kind %q in %q
What it means
`kops replace` only supports a fixed set of kinds: Cluster, InstanceGroup, and SSHCredential. When the decoded object's GroupVersionKind is none of these, the command logs the Go type at V(2) and returns this error naming the unhandled gvk and the source file it was read from.
Source
Thrown at cmd/kops/replace.go:223
cluster, err := clientset.GetCluster(ctx, clusterName)
if err != nil {
return err
}
sshCredentialStore, err := clientset.SSHCredentialStore(cluster)
if err != nil {
return err
}
sshKeyArr := []byte(v.Spec.PublicKey)
err = sshCredentialStore.AddSSHPublicKey(ctx, sshKeyArr)
if err != nil {
return fmt.Errorf("error replacing SSHCredential: %v", err)
}
default:
klog.V(2).Infof("Type of object was %T", v)
return fmt.Errorf("unhandled kind %q in %q", gvk, f)
}
}
}
return nil
}
View on GitHub (pinned to 4c8573c808)
Solutions
- Split the bundle and only pass Cluster, InstanceGroup, or SSHCredential manifests to `kops replace`; use `kops create -f` / `kops update cluster` for other resources.
- Check `kind:` spelling and the apiVersion in the manifest.
- Upgrade/downgrade kops if the kind exists in another kops version.
- Set KOPS_LOG_LEVEL=2 (klog V(2)) to see the Go type that failed to dispatch.
Defensive patterns
Strategy: type-guard
Validate before calling
func isReplaceableKind(manifest []byte) bool {
var meta struct { Kind string `json:"kind"` }
if err := json.Unmarshal(manifest, &meta); err != nil { return false }
switch meta.Kind {
case "Cluster", "InstanceGroup", "SSHCredential":
return true
}
return false
} Type guard
func isReplaceableKind(gvk schema.GroupVersionKind) bool {
return gvk.GroupKind().Kind == "Cluster" ||
gvk.GroupKind().Kind == "InstanceGroup" ||
gvk.GroupKind().Kind == "SSHCredential"
} Prevention
- Split multi-kind bundles; route Cluster/IG/SSHCredential to kops replace and the rest to kubectl/kops create
- Pin the `kind:` and `apiVersion:` fields and lint them
- Keep manifest tooling and kops versions aligned
When it happens
Trigger: Replacing a manifest containing a kind outside the supported set — e.g. a KubernetesCluster addon manifest, keyset, secrets, or a plain Kubernetes object — via `kops replace -f file.yaml`.
Common situations: Feeding an `kops update`/`create -f` bundle (multiple kinds) into replace; typos in `kind:`; using manifests meant for kubectl against kops; older/newer kops manifests with kinds unsupported by this version.
Related errors
- unhandled kind %q in %s
- must specify %q label with cluster name to replace SSHCreden
- spec.PublicKey is required
- expected exactly one container in dns-controller Deployment,
- failed to annotate %q: %w
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/e8a464411c5b48aa.
Report an issue: GitHub.