kubernetes/kops · error

unknown group type for group %q

Error message

unknown group type for group %q

What it means

RollingUpdate partitions all instance groups into API-server, control-plane, and bastion buckets by role; a group whose InstanceGroup.Spec.Role matches none of those falls into the default case and aborts the whole update with 'unknown group type'. Only specific roles (Master/ControlPlane, APIServer, Bastion) plus a broad default are recognized — groups with role BareMetal or a zero-valued Role hit this.

Source

Thrown at pkg/instancegroups/rollingupdate.go:134

	var resultsMutex sync.Mutex
	results := make(map[string]error)

	masterGroups := make(map[string]*cloudinstances.CloudInstanceGroup)
	apiServerGroups := make(map[string]*cloudinstances.CloudInstanceGroup)
	nodeGroups := make(map[string]*cloudinstances.CloudInstanceGroup)
	bastionGroups := make(map[string]*cloudinstances.CloudInstanceGroup)
	for k, group := range groups {
		switch {
		case group.InstanceGroup.Spec.Role.HasNode():
			nodeGroups[k] = group
		case group.InstanceGroup.Spec.Role.HasAPIServer():
			apiServerGroups[k] = group
		case group.InstanceGroup.Spec.Role.HasControlPlane():
			masterGroups[k] = group
		case group.InstanceGroup.Spec.Role.HasBastion():
			bastionGroups[k] = group
		default:
			return fmt.Errorf("unknown group type for group %q", group.InstanceGroup.ObjectMeta.Name)
		}
	}

	// Upgrade bastions first; if these go down we can't see anything
	{
		var wg sync.WaitGroup

		for _, k := range sortGroups(bastionGroups) {
			wg.Add(1)
			go func(k string) {
				resultsMutex.Lock()
				results[k] = fmt.Errorf("function panic bastions")
				resultsMutex.Unlock()

				defer wg.Done()

				err := c.rollingUpdateInstanceGroup(ctx, bastionGroups[k], c.BastionInterval)

View on GitHub (pinned to 4c8573c808)

Solutions

1. Check the InstanceGroup: `kops get ig -o yaml` and set a valid `spec.role` (Node, Master/ControlPlane, Bastion, APIServer)
2. If the field is missing, re-apply after adding it: `kops replace -f ig.yaml` then re-run the rolling update
3. Upgrade/downgrade kOps to a version matching your cluster spec format if a version mismatch caused role parsing to fail

Example fix

// before
kind: InstanceGroup
metadata:
  name: nodes-a
spec:
  machineType: t3.medium
// after
kind: InstanceGroup
metadata:
  name: nodes-a
spec:
  role: Node
  machineType: t3.medium

for _, ig := range igs {
    r := ig.Spec.Role
    if !r.HasControlPlane() && !r.HasAPIServer() && !r.HasBastion() && !r.HasNode() {
        return fmt.Errorf("instance group %q has invalid role %q", ig.Name, r)
    }
}

func roleIsKnown(r api.InstanceGroupRole) bool {
    switch r {
    case api.InstanceGroupRoleControlPlane, api.InstanceGroupRoleAPIServer,
        api.InstanceGroupRoleBastion, api.InstanceGroupRoleNode:
        return true
    }
    return false
}

When it happens

Trigger: An InstanceGroup in the cluster spec has an unset or unrecognized Spec.Role (e.g. role not set in YAML, typo, or a role only valid for other purposes), so when RunRollingUpdateCluster iterates groups the switch hits the default branch.

Common situations: Hand-edited InstanceGroup YAML missing the `spec.role` field; cluster specs created by older kOps versions with role values that newer code no longer buckets; copy-pasted manifests where role was accidentally deleted.

Related errors

• DeleteGroup not implemented on azureCloud
• cannot find subnet %q (declared in instance group %q, not fo
• InstanceGroup name is missing
• instance group %q not found
• rollingUpdate is missing a k8s client

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