kubernetes/kops · error
found multiple Akamai (Linode) VPCs named %q
Error message
found multiple Akamai (Linode) VPCs named %q
What it means
This is a kops-side ambiguity error, not a Linode API error: Find() iterated the VPC list and matched more than one VPC with the same label (and region, when specified). Because the task matches VPCs by Name/label, duplicates make it impossible to determine which VPC the cluster spec refers to, so Find() aborts instead of guessing.
Source
Thrown at upup/pkg/fi/cloudup/linodetasks/vpc.go:73
}
vpcs, err := cloud.Client().ListVPCs(c.Context(), listOptions)
if err != nil {
return nil, fmt.Errorf("error listing Akamai (Linode) VPCs: %w", err)
}
var found *linodego.VPC
name := fi.ValueOf(v.Name)
for i := range vpcs {
candidate := &vpcs[i]
if candidate.Label != name {
continue
}
if v.Region != nil && candidate.Region != fi.ValueOf(v.Region) {
continue
}
if found != nil {
return nil, fmt.Errorf("found multiple Akamai (Linode) VPCs named %q", name)
}
found = candidate
}
if found == nil {
return nil, nil
}
actual := &VPC{
Name: new(found.Label),
ID: new(found.ID),
Lifecycle: v.Lifecycle,
Description: new(found.Description),
Region: new(found.Region),
}
v.ID = actual.ID
return actual, nilView on GitHub (pinned to 4c8573c808)
Solutions
- List VPCs in the Linode console/API (linode-cli vpcs list), identify the duplicate, and delete the stale/unmanaged one
- Rename the leftover VPC's label so only the intended one matches the cluster spec's VPC name
- If the wrong VPC should be adopted, set the ID in the task/spec so matching is unambiguous
- Ensure each cluster spec uses a unique VPC name within the account and region
Example fix
// before: two VPCs both labeled "my-cluster-vpc"; delete the orphan via CLI $ linode-cli vpcs list # note duplicate IDs $ linode-cli vpcs delete 12345 // after: only one VPC matches; kops Find() succeeds
Defensive patterns
Strategy: validation
Validate before calling
// Guard before running the update: ensure exactly one VPC matches
func ensureUniqueVPC(ctx context.Context, client *linodego.Client, name, region string) error {
vpcs, err := client.ListVPCs(ctx, &linodego.ListOptions{Filter: "{\"label\": \"" + name + "\"}"})
if err != nil {
return err
}
n := 0
for _, v := range vpcs {
if region == "" || v.Region == region {
n++
}
}
if n > 1 {
return fmt.Errorf("%d VPCs named %q in region %q; delete or rename duplicates", n, name, region)
}
return nil
} Type guard
func isAmbiguousResourceError(err error) bool {
return err != nil && strings.Contains(err.Error(), "found multiple Akamai (Linode) VPCs")
} Try / catch
if err := run(); err != nil {
if isAmbiguousResourceError(err) {
// stop automation; require manual dedup - do not auto-delete
return fmt.Errorf("manual cleanup required: %w", err)
}
return err
} Prevention
- Use globally unique VPC names per account/region in every cluster spec
- Clean up orphaned VPCs after failed or abandoned cluster deletes
- Never hand-create VPCs with labels matching kops cluster specs
- Rename (not copy) VPC names when cloning cluster specs
- Audit `linode-cli vpcs list` before running updates against an account with multiple clusters
When it happens
Trigger: Two or more Linode VPCs in the account share the same label that equals fi.ValueOf(v.Name) and, if v.Region is set, live in the same region - e.g. leftover VPCs from a previous abandoned cluster, a manually created VPC colliding with a kops-managed one, or a case/normalization mismatch that bypassed the label filter.
Common situations: Re-running cluster creation after a failed cleanup left orphaned VPCs; a developer manually created a VPC with the same label as the one in the cluster spec; copying a cluster spec to a new cluster in the same account/region without renaming the VPC.
Related errors
- error creating Akamai (Linode) VPC %q: %w
- cannot specify additional objects when multiple clusters are
- duplicate InstanceGroup Name found: %q
- error listing Akamai (Linode) VPCs: %w
- error listing Akamai (Linode) VPC subnets for VPC %s(%d): %w
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/704fb7d5d2c7d40f.
Report an issue: GitHub.