[Feature] Bare cluster check is too strict, no room for custom CNIs and kube-proxy-less deployments

[avoidik]

What feature/behavior/change do you want?

Perhaps I'm doing something wrong, but at the moment I am not able to deploy custom CNIs using eksctl due to the fact that the aws-vpc-cni addon is a compulsory addon. Nevertheless, I believe this is not a hard requirement.

I would like to suggest to demote the following showstopper error into a warning:

fields nodeGroups, managedNodeGroups, fargateProfiles, karpenter, gitops, iam.serviceAccounts, and iam.podIdentityAssociations are not supported during cluster creation in a cluster without VPC CNI if Auto Mode is disabled; please remove these fields and add them back after cluster creation is successful

The error stated that it's unsupported configuration, while in reality it works, and actually it's a part of the CNI deployment pattern, including Cilium.

Why do you want this feature?

To be able to deploy CNIs without the kube-proxy and aws-vpc-cni addons. I want to be able to control myself what to deploy in terms of CNIs.

[github-actions]

Hello avoidik 👋 Thank you for opening an issue in eksctl project. The team will review the issue and aim to respond within 1-5 business days. Meanwhile, please read about the Contribution and Code of Conduct guidelines here. You can find out more information about eksctl on our website

[avoidik]

Relevant block of code.

https://github.com/eksctl-io/eksctl/blob/v0.214.0/pkg/ctl/cmdutils/configfile.go#L489-L502

Changing return errors.New to logger.Warning(...); return nil works just fine, in this case a CNI could be installed manually.

[naclonts]

Hi @avoidik, do you mind giving an example of what you're trying to install? Looking to understand your use case here to see what behavior would make sense.

[avoidik]

hello,

here's an example:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: galaxy
  region: eu-central-1
  version: "1.33"
iam:
  withOIDC: true
addonsConfig:
  disableDefaultAddons: true
addons:
  - name: coredns
  - name: aws-ebs-csi-driver
managedNodeGroups:
  - name: workers
    instanceType: m5.xlarge
    desiredCapacity: 0
    minSize: 0
    maxSize: 2
    amiFamily: AmazonLinux2023
    privateNetworking: true

[naclonts]

Thanks for the example @avoidik. In this scenario, eksctl doesn't allow a managed node group to be created without a CNI installed, since the nodes wouldn't be functional without it (pods wouldn't be able to communicate, etc).

For a custom CNI a working flow could be like:

1. Create bare cluster (i.e., using the ClusterConfig you described, but without the managedNodeGroups property)
2. Install Cilium helm chart
3. Create node groups

Cilium has a blog post about using eksctl with their CNI that takes this approach.

Does this approach make sense for your use case?

[avoidik]

Yes, it's quite similar to what I wanted to achieve, thanks! While that approach is viable, I believe the change I'm proposing could simplify it by half.

For example, when these conditions are met (i.e., no default addons are set and no AWS VPC CNI addon is in the list of addons), we may start an EKS cluster with the --without-nodegroup flag using one unified eksctl configuration file as it was before the bare-check.

With the warning instead of the hard exit it's doable. The rest of the nodegroups together with additional addons may be deployed after using eksctl scale nodegroup.

[avoidik]

diff --git a/pkg/ctl/cmdutils/configfile.go b/pkg/ctl/cmdutils/configfile.go
index 7394d4ed1..7bf257fc7 100644
--- a/pkg/ctl/cmdutils/configfile.go
+++ b/pkg/ctl/cmdutils/configfile.go
@@ -494,9 +494,10 @@ func validateBareCluster(clusterConfig *api.ClusterConfig) error {
 	}
 	if clusterConfig.HasNodes() || clusterConfig.IsFargateEnabled() || clusterConfig.Karpenter != nil || clusterConfig.HasGitOpsFluxConfigured() ||
 		(clusterConfig.IAM != nil && ((len(clusterConfig.IAM.ServiceAccounts) > 0) || len(clusterConfig.IAM.PodIdentityAssociations) > 0)) {
-		return errors.New("fields nodeGroups, managedNodeGroups, fargateProfiles, karpenter, gitops, iam.serviceAccounts, " +
+		logger.Warning("fields nodeGroups, managedNodeGroups, fargateProfiles, karpenter, gitops, iam.serviceAccounts, " +
 			"and iam.podIdentityAssociations are not supported during cluster creation in a cluster without VPC CNI if Auto Mode is disabled; " +
 			"please remove these fields and add them back after cluster creation is successful")
+		return nil
 	}
 	return nil
 }

[avoidik]

eksctl create cluster -f cluster.yaml --without-nodegroup --write-kubeconfig=false
eksctl create nodegroup -f cluster.yaml
eksctl scale nodegroup -c galaxy --nodes 1 -n workers --wait 

[naclonts]

Taking a look at your updated config.yaml, I see it now has desiredCapacity of zero. It seems like that config bypasses the error, since HasNodes checks that desired capacity is greater than zero:

# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: galaxy
  region: eu-central-1
  version: "1.33"
iam:
  withOIDC: true
addonsConfig:
  disableDefaultAddons: true
addons:
  - name: coredns
  - name: aws-ebs-csi-driver
managedNodeGroups:
  - name: workers
    instanceType: m5.xlarge
    desiredCapacity: 0
    minSize: 0
    maxSize: 2
    amiFamily: AmazonLinux2023
    privateNetworking: true

Creating:

% eksctl create cluster -f cluster.yaml
# ...
2025-10-08 19:50:32 [ℹ]  deploying stack "eksctl-galaxy-desired-zero-cluster"
# ...eventually succeeds

% eksctl get nodegroups --cluster galaxy-desired-zero --region eu-central-1       
CLUSTER			NODEGROUP	STATUS	CREATED			MIN SIZE	MAX SIZE	DESIRED CAPACITY	INSTANCE TYPEIMAGE ID	     	     ASG NAME	     	     	     	     	     	     TYPE
galaxy-desired-zero	workers		ACTIVE	2025-10-08T20:02:09Z	0		2		0			m5.xlarge	23_x86_64_STANDARD	-workers-cccce2b5-56c2-3486-64ec-62788a2dbfc6	     managed

From there, you could install Cilium and then scale up the nodegroup.

Does this config accomplish what you're trying to do?

[NicholasBlaskey]

Hey @avoidik did you get a chance to see if the desired capacity workaround would help in your situation?

[NicholasBlaskey]

Going to close this, feel free to reopen if this doesn't solve your usecase