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

  1. Set a networking mode in the cluster spec, e.g. spec.networking.cni: {} for CNI clusters
  2. Use spec.networking.kubenet: {} if relying on cloud routes
  3. Use spec.networking.external: {} for an external (CNI-managed) networking
  4. 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

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


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