kubernetes/kops · error

no networking mode set

Error message

no networking mode set

What it means

NetworkingSpec.UsesKubenet() panics when called on a nil *NetworkingSpec. Since Go allows calling methods on nil pointer receivers, the library guards here and panics with "no networking mode set" to signal that the cluster spec had no networking section, which would make the answer meaningless. Callers such as UsesCNI rely on this never being nil.

Source

Thrown at pkg/apis/kops/networking.go:102

	LyftVPC    *LyftVPCNetworkingSpec    `json:"lyftvpc,omitempty"`
	GCP        *GCPNetworkingSpec        `json:"gcp,omitempty"`
	Kindnet    *KindnetNetworkingSpec    `json:"kindnet,omitempty"`
}

// ConfiguredOptions returns the set of networking options that are configured (non-nil)
// in the struct.  We only expect a single option to be configured.
func (n *NetworkingSpec) ConfiguredOptions() sets.Set[string] {
	options, err := reflectutils.FindSetFields(n, "classic", "kubenet", "external", "cni", "weave", "flannel", "calico", "kubeRouter", "romana", "amazonVPC", "cilium", "lyftvpc", "gcp", "kindnet")
	if err != nil {
		klog.Fatalf("error getting set fields: %v", err)
	}
	return options
}

// UsesKubenet returns true if our networking is derived from kubenet
func (n *NetworkingSpec) UsesKubenet() bool {
	if n == nil {
		panic("no networking mode set")
	}
	if n.Kubenet != nil {
		return true
	} else if n.GCP != nil {
		// GCP IP Alias networking is based on kubenet
		return true
	} else if n.External != nil {
		// external is based on kubenet
		return true
	}

	return false
}

// ClassicNetworkingSpec is the specification of classic networking mode, integrated into kubernetes.
// Support been removed since Kubernetes 1.4.
type ClassicNetworkingSpec struct{}

View on GitHub (pinned to 4c8573c808)

Solutions

1. Ensure the cluster spec always has a NetworkingSpec populated before calling UsesKubenet/UsesCNI.
2. Add a nil check in your code: if spec.Networking == nil { initialize or skip } before calling the method.
3. At cluster-creation/validation time, require a networking section so invalid specs fail early with a clear message.
4. Default to a known networking mode (e.g. Kubenet or CNI) when constructing specs programmatically.

Example fix

// before
usesKubenet := spec.Networking.UsesKubenet() // panics if nil
// after
if spec.Networking == nil {
    spec.Networking = &kops.NetworkingSpec{}
}
usesKubenet := spec.Networking.UsesKubenet()

if spec == nil || spec.Networking == nil {
    return false, fmt.Errorf("cluster spec has no networking section")
}

func hasNetworking(spec *kops.ClusterSpec) bool {
    return spec != nil && spec.Networking != nil
}

// Go panics: recover only as a last resort
func safeUsesKubenet(n *kops.NetworkingSpec) (result bool) {
    defer func() {
        if r := recover(); r != nil {
            result = false
        }
    }()
    return n.UsesKubenet()
}

When it happens

Trigger: Invoking n.UsesKubenet() (or UsesCNI) where n is a nil *NetworkingSpec — typically obtained from a partially constructed ClusterSpec, a decoded config missing the networking block, or code that dereferences spec.Networking without a nil check.

Common situations: Programmatically building a ClusterSpec and forgetting to set Networking, loading an old/minimal cluster manifest without a networking section, or unit tests constructing specs with only a few fields populated.

Related errors

• unable to parse assets as assetBuilder is not defined
• failed to parse template, error: %s
• Error parsing version %s: %v
• ReadOnlyError
• unexpected kind for cluster, got %T, want kops.Cluster

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