kubernetes/kops · error
no networking mode set
Error message
no networking mode set
What it means
When building the AWS cloud-controller-manager component, the builder must decide eccm.ConfigureCloudRoutes based on the cluster's networking mode (kubenet => true; CNI/external => false). If cluster.spec.networking is nil or set to a mode none of the branches (External, UsesCNI, kubenet) recognize, the mode is undecidable and the builder fails.
Source
Thrown at pkg/model/components/awscloudcontrollermanager.go:68
eccm.ClusterName = b.ClusterName
eccm.AllocateNodeCIDRs = new(!clusterSpec.IsKopsControllerIPAM())
if eccm.ClusterCIDR == "" && !clusterSpec.IsKopsControllerIPAM() {
eccm.ClusterCIDR = clusterSpec.Networking.PodCIDR
}
// TODO: we want to consolidate this with the logic from KCM
networking := &clusterSpec.Networking
if networking.Kubenet != nil {
eccm.ConfigureCloudRoutes = new(true)
} else if networking.External != nil {
eccm.ConfigureCloudRoutes = new(false)
} else if UsesCNI(networking) {
eccm.ConfigureCloudRoutes = new(false)
} else {
return fmt.Errorf("no networking mode set")
}
if eccm.Image == "" {
eccm.Image = "registry.k8s.io/provider-aws/cloud-controller-manager:v1.37.0"
}
return nil
}
View on GitHub (pinned to 4c8573c808)
Solutions
- Set an explicit networking mode in the cluster spec, e.g. `kops set cluster kubernetes.networking.cni.enabled=true` or edit spec.networking to include cni/calico/kubenet
- Run `kops edit cluster` and add a networking block, then `kops update cluster`
- Upgrade/align the kops CLI version with the cluster state if a newer networking mode is not recognized by this older builder
Example fix
# before
networking: {}
# after
networking:
cni: {} Defensive patterns
Strategy: validation
Validate before calling
if cluster.Spec.Networking == nil || (cluster.Spec.Networking.Kubenet == nil && cluster.Spec.Networking.CNI == nil && cluster.Spec.Networking.External == nil && cluster.Spec.Networking.Calico == nil && cluster.Spec.Networking.Canal == nil) {
return fmt.Errorf("cluster %s has no networking mode set", cluster.Name)
} Type guard
func networkingModeSet(n *kops.NetworkingSpec) bool {
return n != nil && n.Kubenet != nil || n != nil && n.CNI != nil || n != nil && n.External != nil
} Try / catch
if err := updateCluster(); err != nil {
if strings.Contains(err.Error(), "no networking mode set") {
// prompt user to set spec.networking and retry
}
return err
} Prevention
- Never leave `networking: {}` in cluster manifests
- Use `kops set cluster kubernetes.networking.cni.enabled=true` rather than hand-editing
- After upgrades, re-inspect spec.networking since some paths can drop it
When it happens
Trigger: Rendering the AWS CCM model for a cluster whose NetworkingSpec is empty ({}) or whose only networking selector is not one of the supported modes checked in this branch chain.
Common situations: A hand-edited cluster.yaml with `networking: {}`; an upgrade that dropped the networking section; specifying a networking option the kops version doesn't recognize.
Related errors
- multiple physical network interfaces found with MAC address
- cannot determine challenge endpoint for instance id: %s
- cannot mix egress values in private or IPv6-capable subnets
- cannot mix publicIP values in private or IPv6-capable subnet
- kops currently only supports re-use of either NAT EC2 Instan
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/361d1ee0e367bcb3.
Report an issue: GitHub.