Adding support for upgrading eks hybrid nodes on EKS clusters

[pokearu]

Description

Adds support for updating remoteNetworkConfig on existing EKS clusters through eksctl upgrade cluster. Previously, remote network config could only be set during cluster creation — this change allows users to enable hybrid nodes, update CIDRs, or remove remote networks on existing clusters.

What this does:

• Adds updateRemoteNetworkConfig to the Upgrade flow in owned.go, called between version upgrade and CFN stack update
• Maps the config file's remoteNetworkConfig directly to the EKS UpdateClusterConfig API.
• Nil fields are omitted by the SDK (no-op), empty [] sends an empty array (removes)
• Catches the API's "No changes detected" 400 response and treats it as success
• Updates the validation to allow both remoteNodeNetworks: [] and remotePodNetworks: [] simultaneously (the "remove all" case), matching the EKS API's validateRemoteNetworkConfigUpdateRequest behavior

Usage:

# Enable / update hybrid nodes
remoteNetworkConfig:
  remoteNodeNetworks:
    - cidrs: ["10.80.146.0/24"]
  remotePodNetworks:
    - cidrs: ["10.90.0.0/16"]

# Remove all remote networks (disable hybrid)
remoteNetworkConfig:
  remoteNodeNetworks: []
  remotePodNetworks: []

eksctl upgrade cluster -f cluster-config.yaml --approve

Design decisions:

• Lives in upgrade cluster (not a utils command) because enabling hybrid nodes also requires CFN resources (VPC routes, IAM roles) which AppendNewClusterStackResource handles
• No client-side re-implementation of API validations — bad input gets clear API errors
• No defaulting — omitting remotePodNetworks sends nil (no change), setting it to [] sends empty (remove)

Testing

ramaliar@7cf34dd2c821 eksctl % ./eksctl upgrade cluster -f ./cluster-config.yaml --approve
2026-04-27 17:00:38 [!]  remoteNetworkConfig.iam.roleARN is set; eksctl will add a corresponding entry in aws-auth configmap; but won't setup an additional SSM or IAMRolesAnywhere required config
2026-04-27 17:00:38 [!]  NOTE: cluster VPC (subnets, routing & NAT Gateway) configuration changes are not yet implemented
2026-04-27 17:00:39 [ℹ]  no cluster version update required
2026-04-27 17:00:39 [ℹ]  will update remote network config for cluster "test-eksctl"
2026-04-27 17:07:28 [✔]  remote network config updated successfully for cluster "test-eksctl"
2026-04-27 17:07:28 [ℹ]  re-building cluster stack "eksctl-test-eksctl-cluster"
2026-04-27 17:07:28 [!]  a TGW or VGW was not provided for hybrid nodes connectivity, hence eksctl won't configure any related routes and gateway attachments for your VPC
2026-04-27 17:07:28 [ℹ]  updating stack to add new resources [IngressControlPlaneRemoteNetworks2] and outputs []
2026-04-27 17:07:29 [ℹ]  waiting for CloudFormation changeset "eksctl-update-cluster-1777334848" for stack "eksctl-test-eksctl-cluster"
2026-04-27 17:07:59 [ℹ]  waiting for CloudFormation changeset "eksctl-update-cluster-1777334848" for stack "eksctl-test-eksctl-cluster"
2026-04-27 17:08:00 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:08:30 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:09:22 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:11:02 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:11:48 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:12:19 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:13:13 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:15:08 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:15:50 [ℹ]  waiting for CloudFormation stack "eksctl-test-eksctl-cluster"
2026-04-27 17:15:50 [ℹ]  checking security group configuration for all nodegroups
2026-04-27 17:15:50 [ℹ]  all nodegroups have up-to-date cloudformation templates

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the userdocs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes
• (Core team) Added labels for change area (e.g. area/nodegroup) and kind (e.g. kind/improvement)

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[github-actions]

Hello pokearu 👋 Thank you for opening a Pull Request in eksctl project. The team will review the Pull Request and aim to respond within 1-10 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

[michaelhtm]

should we validate this for create vs update?

[pokearu]

Good question! This check is needed for the upgrade cluster path — the "remove all remote networks" case requires both-empty lists, and upgrade does go through ValidateClusterConfig via NewProviderForExistingCluster → InitializeClusterConfig.

For creates, this is a no-op — the CFN builder gates on HasRemoteNetworkingConfigured() which returns false when both lists are empty, so remoteNetworkConfig never makes it into the template. The EKS API would also reject it anyway.

We considered adding create/update context to the validation path but it felt like unnecessary complexity for a harmless no-op. I'll add a warning log when both-empty is detected so users aren't silently confused.