kubernetes/kops · error
no networking mode set
Error message
no networking mode set
What it means
BuildOptions inspects cluster.spec.networking to decide whether kube-controller-manager should configure cloud routes. If none of the known networking modes (kubenet, external, CNI-based, etc.) is set, it cannot determine route behavior and returns this error. It guards against a cluster spec with an empty/unrecognized networking section.
Source
Thrown at pkg/model/components/kubecontrollermanager.go:134
// kcm should not allocate node cidrs with the CloudAllocator if we're using the external CCM
kcm.AllocateNodeCIDRs = new(false)
} else {
kcm.CIDRAllocatorType = new("CloudAllocator")
}
} else if networking.Kindnet != nil {
// We don't expect KCM to configure routes; it should be done by the CCM (or by the infrastructure)
kcm.ConfigureCloudRoutes = new(false)
// If the cloud is allocating the node CIDRs, that should be done by CCM
if o.GetCloudProvider() == kops.CloudProviderGCE && gce.UsesIPAliases(o) {
kcm.AllocateNodeCIDRs = new(false)
}
} else if networking.External != nil {
kcm.ConfigureCloudRoutes = new(false)
} else if UsesCNI(networking) {
kcm.ConfigureCloudRoutes = new(false)
} else {
return fmt.Errorf("no networking mode set")
}
if kcm.UseServiceAccountCredentials == nil {
kcm.UseServiceAccountCredentials = new(true)
}
if len(kcm.Controllers) == 0 {
var changes []string
if clusterSpec.IsKopsControllerIPAM() {
changes = append(changes, "-nodeipam")
}
if len(changes) != 0 {
kcm.Controllers = append([]string{"*"}, changes...)
}
}
return nil
}View on GitHub (pinned to 4c8573c808)
Solutions
- Set a networking mode in the cluster spec, e.g. spec.networking.cni: {} for CNI clusters
- Use spec.networking.kubenet: {} if relying on cloud routes
- Use spec.networking.external: {} for an external (CNI-managed) networking
- Re-run kops get/replace with a spec exported from a working cluster to restore the networking section
Example fix
// before (spec)
spec:
# networking section missing
// after
spec:
networking:
cni: {} Defensive patterns
Strategy: validation
Validate before calling
n := cluster.Spec.Networking
if n == nil || (n.Kubenet == nil && n.External == nil && n.CNI == nil && n.Kope == nil && n.Calico == nil && n.Canal == nil && n.Flannel == nil && n.Weave == nil && n.LyftVPC == nil && n.GCE == nil) {
return errors.New("cluster spec must set a networking mode before building")
} Prevention
- Always base new cluster specs on `kops get cluster -o yaml` output which includes networking
- Never delete the spec.networking block when editing YAML
- Set a minimal networking mode such as cni: {} for standard clusters
When it happens
Trigger: Calling BuildOptions on a cluster whose spec has no networking mode populated — spec.networking is empty or all networking option structs (Kubenet, CNI, External, etc.) are nil, so the final else branch is reached.
Common situations: Hand-editing a cluster spec and deleting the networking block; tooling that constructs a Cluster struct programmatically and forgets to set Networking; upgrading/merging YAML that dropped the networking section.
Related errors
- cannot mix egress values in private or IPv6-capable subnets
- classic networking not supported
- validation of the full cluster and instance group specs fail
- error populating configuration: %v
- configuration must include Subnets
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/87c36e62a3fa4847.
Report an issue: GitHub.