kubernetes/kops · error

cannot apply changes to TargetPool: %v

Error message

cannot apply changes to TargetPool: %v

What it means

RenderGCE only supports creating a TargetPool or leaving it unchanged; if the computed diff shows any changes to an existing TargetPool, it refuses with this error. GCE target pools are largely immutable in kOps' model, so in-place updates are not attempted.

Source

Thrown at upup/pkg/fi/cloudup/gcetasks/targetpool.go:103

	name := fi.ValueOf(e.Name)

	o := &compute.TargetPool{
		Name: name,
	}

	if a == nil {
		klog.V(4).Infof("Creating TargetPool %q", o.Name)

		op, err := t.Cloud.Compute().TargetPools().Insert(t.Cloud.Project(), t.Cloud.Region(), o)
		if err != nil {
			return fmt.Errorf("error creating TargetPool %q: %v", name, err)
		}

		if err := t.Cloud.WaitForOp(op); err != nil {
			return fmt.Errorf("error creating TargetPool: %v", err)
		}
	} else {
		return fmt.Errorf("cannot apply changes to TargetPool: %v", changes)
	}

	return nil
}

type terraformTargetPool struct {
	Name         string                     `cty:"name"`
	HealthChecks []*terraformWriter.Literal `cty:"health_checks"`
}

func (_ *TargetPool) RenderTerraform(t *terraform.TerraformTarget, a, e, changes *TargetPool) error {
	name := fi.ValueOf(e.Name)

	tf := &terraformTargetPool{
		Name: name,
		HealthChecks: []*terraformWriter.Literal{
			e.HealthCheck.TerraformLink(),
		},

View on GitHub (pinned to 4c8573c808)

Solutions

1. Read the %v diff in the message to see which fields changed
2. Revert out-of-band GCP console changes so the target pool matches the spec
3. Delete the target pool (via kops/`gcloud`) and re-run `kops update cluster` to recreate it with the desired config
4. If the diff is caused by a spec change, plan for LB recreation (note downtime implications)

Example fix

// kops-side behavior
} else {
	return fmt.Errorf("cannot apply changes to TargetPool: %v", changes)
}
// user-side fix: delete and recreate
// gcloud compute target-pools delete <name> --region <region> && kops update cluster --yes

diff <(gcloud compute target-pools describe <name> --region <region> --format=yaml) <(kops toolbox dump / expected config)  # detect drift before applying

When it happens

Trigger: Find() returns an existing TargetPool whose fields differ from the spec (changes != empty), so RenderGCE hits the else branch and returns 'cannot apply changes to TargetPool: %v' with the diff in %v.

Common situations: Manually editing the target pool in GCP console so it drifts from the cluster spec; upgrading the cluster spec in ways that alter target pool properties; health-check or instance-group changes that surface as target pool diffs.

Related errors

• error getting TargetPool %q: %v
• error creating TargetPool %q: %v
• error creating TargetPool: %v
• creating gce IPAM controller: %w
• error building compute API client: %v

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