kubernetes/kops · error

unexpected access type in template %q: %s

Error message

unexpected access type in template %q: %s

What it means

kOps models external IPs on GCE instance templates assuming the sole access config type is ONE_TO_ONE_NAT. If the matched template's single access config has a different Type value, Find cannot interpret it and returns this error naming the template and the unexpected type string.

Source

Thrown at upup/pkg/fi/cloudup/gcetasks/instancetemplate.go:173

			if len(ni.AliasIpRanges) != 0 {
				actual.AliasIPRanges = make(map[string]string)
				for _, aliasIPRange := range ni.AliasIpRanges {
					actual.AliasIPRanges[aliasIPRange.SubnetworkRangeName] = aliasIPRange.IpCidrRange
				}
			}

			if ni.Subnetwork != "" {
				actual.Subnet = &Subnet{Name: new(lastComponent(ni.Subnetwork))}
			}

			acs := ni.AccessConfigs
			if len(acs) > 0 {
				if len(acs) != 1 {
					return nil, fmt.Errorf("unexpected number of access configs in template %q: %d", *actual.Name, len(acs))
				}
				if acs[0].Type != accessConfigOneToOneNAT {
					return nil, fmt.Errorf("unexpected access type in template %q: %s", *actual.Name, acs[0].Type)
				}
				actual.HasExternalIP = new(true)
			} else {
				actual.HasExternalIP = new(false)
			}
		}

		for _, serviceAccount := range p.ServiceAccounts {
			for _, scope := range serviceAccount.Scopes {
				actual.Scopes = append(actual.Scopes, scopeToShortForm(scope))
			}
			actual.ServiceAccounts = append(actual.ServiceAccounts, &ServiceAccount{
				Email: &serviceAccount.Email,
			})
		}

		// When we deal with additional disks (local disks), we'll need to map them like this...
		//for i, disk := range p.Disks {

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Describe the template to confirm the access config type: `gcloud compute instance-templates describe <name>`
  2. Set the access config Type to ONE_TO_ONE_NAT (the standard external-IP config) or remove it entirely if no external IP is wanted
  3. Recreate the template via kOps so the network interface config matches the cluster spec
  4. If the template is not kOps-managed, rename/delete it so it no longer matches the NamePrefix
  5. Upgrade kOps in case support for the new access-config type was added

Example fix

// before
"accessConfig": [{ "type": "DIRECT_IPV6", ... }]
// after
"accessConfig": [{ "type": "ONE_TO_ONE_NAT", "networkTier": "PREMIUM" }]
# or recreate the template with kops update cluster
Defensive patterns

Strategy: validation

Validate before calling

# Verify access config type on matching templates:
for t in $(gcloud compute instance-templates list --format="value(name)" | grep '^<nameprefix>-'); do
  ty=$(gcloud compute instance-templates describe $t --format="value(properties.networkInterfaces[0].accessConfigs[0].type)")
  [ -z "$ty" ] || [ "$ty" = "ONE_TO_ONE_NAT" ] || echo "FAIL: $t accessConfig type=$ty"
done

Prevention

When it happens

Trigger: An instance template matching the NamePrefix has exactly one access config on its first network interface, but its Type is not "ONE_TO_ONE_NAT" — e.g. a manually created template using a different/unrecognized access config type value, or a template produced by newer GCP features/other tooling.

Common situations: Hand-edited templates or templates from other IaC tools that set access config types kOps doesn't recognize; experimentation with new GCE networking features that emit different access-config types; corrupted out-of-band edits.

Related errors


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