kubernetes/kops · error

error getting instance group for MIG %q

Error message

error getting instance group for MIG %q

What it means

Returned by GetCloudGroups when matchInstanceGroup fails to map a GCE managed instance group to one of the cluster's kops InstanceGroup specs. Note the underlying matchInstanceGroup error is discarded — only the MIG name is reported — so this typically means the MIG's labels/tags do not correspond to any known instance group. This makes the cloud-group listing incomplete, so it is fatal.

Source

Thrown at upup/pkg/fi/cloudup/gce/instancegroups.go:177

	}

	for _, zoneName := range zones {
		migs, err := c.Compute().InstanceGroupManagers().List(ctx, project, zoneName)
		if err != nil {
			return nil, fmt.Errorf("error listing InstanceGroupManagers: %v", err)
		}
		for _, mig := range migs {
			name := mig.Name

			instanceTemplate := instanceTemplates[mig.InstanceTemplate]
			if instanceTemplate == nil {
				klog.V(2).Infof("ignoring MIG %s with unmanaged InstanceTemplate: %s", name, mig.InstanceTemplate)
				continue
			}

			ig, err := matchInstanceGroup(mig, cluster, instancegroups)
			if err != nil {
				return nil, fmt.Errorf("error getting instance group for MIG %q", name)
			}
			if ig == nil {
				if warnUnmatched {
					klog.Warningf("Found MIG with no corresponding instance group %q", name)
				}
				continue
			}

			g := &cloudinstances.CloudInstanceGroup{
				HumanName:     mig.Name,
				InstanceGroup: ig,
				MinSize:       int(mig.TargetSize),
				TargetSize:    int(mig.TargetSize),
				MaxSize:       int(mig.TargetSize),
				Raw:           mig,
			}
			groups[mig.Name] = g

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Re-run with klog V(2) and inspect matchInstanceGroup logic: compare the MIG name/labels against each kops InstanceGroup spec.
  2. Check the MIG's name and labels/tags: it must follow kops naming (<cluster>-<igname> pattern) so it can be matched.
  3. If the MIG is not kops-managed, delete it or exclude it from the cluster's zones.
  4. Ensure the cluster spec's instanceGroups section matches the MIGs actually present (no stale or duplicate groups).

Example fix

// before
return nil, fmt.Errorf("error getting instance group for MIG %q", name)
// after (preserve the cause for diagnosis)
ig, err := matchInstanceGroup(mig, cluster, instancegroups)
if err != nil {
    return nil, fmt.Errorf("error getting instance group for MIG %q: %v", name, err)
}
Defensive patterns

Strategy: validation

Validate before calling

// before calling kops commands, confirm every MIG maps to exactly one kops IG
for _, mig := range migs {
    matches := filterInstanceGroupsByNameOrLabels(instancegroups, mig.Name, mig.Labels)
    if len(matches) != 1 {
        log.Fatalf("MIG %s matches %d kops instance groups; fix the cluster spec", mig.Name, len(matches))
    }
}

Type guard

func isManagedByKops(mig *compute.InstanceGroupManager, clusterName string) bool {
    return mig != nil && strings.HasPrefix(mig.Name, clusterName+"-")
}

Try / catch

cloudGroups, err := gceCloud.GetCloudGroups(ctx, cluster, warnUnmatched, instancegroups)
if err != nil {
    if strings.Contains(err.Error(), "error getting instance group for MIG") {
        log.Warn("a MIG does not map to any kops instance group; inspect MIG names/labels or remove it")
    }
    return err
}

Prevention

When it happens

Trigger: Calling GetCloudGroups when matchInstanceGroup(mig, cluster, instancegroups) returns an error — most often because multiple or zero kops instance groups ambiguously match, or because internal matching logic fails (e.g. bad group naming/labels on the MIG created outside kops).

Common situations: MIGs created or renamed manually in the GCP console, instance groups whose kops cluster tag was altered, cloning an instance group without updating its name/labels, or a cluster spec where two instance groups map to the same MIG.

Related errors


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