kubernetes/kops · error

error deleting Address %s: %v

Error message

error deleting Address %s: %v

What it means

Wraps a failure from Compute Addresses().Delete in deleteAddress during cluster teardown. NotFound is treated as success; other failures surface with the address SelfLink and raw error. The most characteristic cause is a 412/400 conflict because the address is still reserved/in-use by a forwarding rule or VM that hasn't been deleted yet.

Source

Thrown at pkg/resources/gce/gce.go:876

}

func deleteAddress(cloud fi.Cloud, r *resources.Resource) error {
	c := cloud.(gce.GCECloud)
	t := r.Obj.(*compute.Address)

	klog.V(2).Infof("Deleting GCE Address %s", t.SelfLink)
	u, err := gce.ParseGoogleCloudURL(t.SelfLink)
	if err != nil {
		return err
	}

	op, err := c.Compute().Addresses().Delete(u.Project, u.Region, u.Name)
	if err != nil {
		if gce.IsNotFound(err) {
			klog.Infof("Address not found, assuming deleted: %q", t.SelfLink)
			return nil
		}
		return fmt.Errorf("error deleting Address %s: %v", t.SelfLink, err)
	}

	return c.WaitForOp(op)
}

func (d *clusterDiscoveryGCE) listSubnets() ([]*resources.Resource, error) {
	// Templates are very accurate because of the metadata, so use those as the sanity check
	templates, err := d.findInstanceTemplates()
	if err != nil {
		return nil, err
	}
	subnetworkUrls := make(map[string]bool)
	for _, t := range templates {
		for _, ni := range t.Properties.NetworkInterfaces {
			if ni.Subnetwork != "" {
				subnetworkUrls[ni.Subnetwork] = true
			}
		}

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Delete the load balancer/forwarding rule holding the IP first, then re-run kops delete cluster (teardown is resumable).
  2. Check for other resources using the address in the GCP console (VPC network > IP addresses shows in-use status).
  3. Verify compute.addresses.delete IAM permission on the project.
  4. Retry on 429/5xx after a short backoff.
  5. If truly orphaned, release the address in the console and remove it from a manual resource-tracking run.
Defensive patterns

Strategy: retry

Validate before calling

// check the address is not still in use before delete
addr, err := computeService.Addresses.Get(project, region, addrName).Do()
if err == nil && addr.Status == "IN_USE" {
    return fmt.Errorf("address %s still in use by %s; delete the LB first", addrName, addr.Users)
}

Type guard

func isGCEAPIError(err error) (*googleapi.Error, bool) {
    var gerr *googleapi.Error
    return gerr, errors.As(err, &gerr)
}

Try / catch

err := deleteAddress(t)
var gerr *googleapi.Error
if err != nil {
    if errors.As(err, &gerr) && gerr.Code == 404 { return nil } // already gone
    if errors.As(err, &gerr) && (gerr.Code == 409 || gerr.Code == 412 || gerr.Code == 429 || gerr.Code >= 500) {
        // dependent LB still alive or transient — backoff and retry
    }
    return err
}

Prevention

When it happens

Trigger: c.Compute().Addresses().Delete(u.Project, u.Region, u.Name) returns 403 permission denied, 409/412 in-use by another resource, 429 rate limit, or 5xx. Ordering issues in teardown (load balancer still holding the IP) trigger this most often.

Common situations: Static IP still attached to a surviving load balancer/forwarding rule after partial teardown failure; shared VPC IAM gaps; concurrent kops delete runs; credential rotation mid-deletion.

Related errors


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