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
- Describe the template to confirm the access config type: `gcloud compute instance-templates describe <name>`
- 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
- Recreate the template via kOps so the network interface config matches the cluster spec
- If the template is not kOps-managed, rename/delete it so it no longer matches the NamePrefix
- 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
- Only use ONE_TO_ONE_NAT access configs (standard external IP) on kOps-managed templates
- Make networking changes through the kOps cluster spec, not gcloud/console edits
- Audit templates for manual modifications after any out-of-band GCP automation runs
- Keep kOps up to date so newly supported access-config types are handled
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
- unexpected number of access configs in template %q: %d
- instance %s did not have Version set
- ig name not set on instance template %s
- failed to parse subnet CIDR %q: %w
- error listing networks: %v
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/c361dd1a123a9bf3.
Report an issue: GitHub.