kubernetes/kops · error

cannot apply changes to InstanceGroupManager: %v

Error message

cannot apply changes to InstanceGroupManager: %v

What it means

During RenderGCE for an existing GCE InstanceGroupManager (managed instance group), kOps only knows how to update three mutable fields in place: TargetPools, InstanceTemplate, and TargetSize. After applying those updates it checks whether any other changed fields remain in the `changes` struct; if so, it refuses with this error because applying them would require recreating the group, which the task does not support.

Source

Thrown at upup/pkg/fi/cloudup/gcetasks/instancegroupmanager.go:182

			newSize := int64(0)
			if i.TargetSize != 0 {
				newSize = int64(i.TargetSize)
			}
			op, err := t.Cloud.Compute().InstanceGroupManagers().Resize(t.Cloud.Project(), *e.Zone, i.Name, newSize)
			if err != nil {
				return fmt.Errorf("error resizing InstanceGroupManager: %v", err)
			}

			if err := t.Cloud.WaitForOp(op); err != nil {
				return fmt.Errorf("error resizing InstanceGroupManager: %v", err)
			}

			changes.TargetSize = nil
		}

		empty := &InstanceGroupManager{}
		if !reflect.DeepEqual(empty, changes) {
			return fmt.Errorf("cannot apply changes to InstanceGroupManager: %v", changes)
		}
	}

	return nil
}

type terraformInstanceGroupManager struct {
	Lifecycle                   *terraform.Lifecycle       `cty:"lifecycle"`
	Name                        *string                    `cty:"name"`
	Zone                        *string                    `cty:"zone"`
	BaseInstanceName            *string                    `cty:"base_instance_name"`
	ListManagedInstancesResults string                     `cty:"list_managed_instances_results"`
	Version                     *terraformVersion          `cty:"version"`
	TargetSize                  *int64                     `cty:"target_size"`
	UpdatePolicy                *terraformUpdatePolicy     `cty:"update_policy"`
	TargetPools                 []*terraformWriter.Literal `cty:"target_pools"`
}

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Inspect the printed `changes` struct to identify which field(s) kOps wants to change
  2. Revert the out-of-band change in GCP (or update the kOps cluster spec so the field matches what's in GCP) so no unexpected diff remains
  3. If the change is intentional and unsupported in-place, delete and recreate the instance group (or the whole cluster with `kops delete cluster` / replace the MIG)
  4. Check kOps release notes / issues for the field; a newer kOps may support updating it — upgrade kOps
  5. Run with `--v=10` and use `kops update cluster --dry-run` to preview the diff before applying

Example fix

// changes printed: {BaseInstanceName:&"ig--nodes-1x" ...}
// before: MIG base instance name edited manually in GCP console
// after: revert in GCP so it matches kOps spec, or change spec to match:
//   kops edit instancegroup nodes  # align fields; then kops update cluster
Defensive patterns

Strategy: validation

Validate before calling

// Preview drift before applying:
//   kops update cluster <cluster> --target dryrun --v=10
// In CI, guard against out-of-band edits:
//   kops get instancegroups <cluster> -o yaml > spec.yaml
//   kops update cluster <cluster> --target terraform -o out/ && git diff --exit-code out/

Prevention

When it happens

Trigger: Running `kops update cluster --target direct` against GCE when an existing managed instance group has drifted in any field other than TargetPools/InstanceTemplate/TargetSize — e.g. someone manually edited the MIG's name, zone, base instance name, or auto-healing/health-check settings in the GCP console, or a kOps version change altered how a field is modeled.

Common situations: Out-of-band edits to the MIG via gcloud/console; upgrading kOps to a version that represents a new InstanceGroupManager field (so it appears as a change on first run); attempting to change immutable properties like the group's base instance name or network through the cluster spec.

Related errors


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