You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for vpc.controlPlaneOnPrivateSubnets (#8793)
* Add support for vpc.controlPlaneOnPrivateSubnets
When eksctl creates a VPC, it passes both the public and the private subnets
to the EKS API, so the control plane's cross-account ENIs are placed in public
subnets as well. Restricting them to private subnets afterwards requires
`eksctl utils update-cluster-vpc-config`, which calls the EKS API directly and
leaves the cluster's CloudFormation stack out of sync.
Add a `vpc.controlPlaneOnPrivateSubnets` field so that only the private subnets
are passed to the EKS API at creation time. Public subnets are still created and
used for NAT gateways and internet-facing load balancers, so this does not make
the cluster fully private.
The field is honoured for eksctl-created VPCs (IPv4 and IPv6, including
fully-private clusters) and for pre-existing VPCs. It is rejected when combined
with `vpc.controlPlaneSubnetIDs`, and when the configured private subnets do not
cover at least two availability zones, which EKS requires. That last check is
best-effort: subnets given only by ID have their zone resolved from EC2 after
validation runs, so they are allowed through and rejected by the EKS API instead.
Outposts are exempt, since the control plane there is already private-only.
`eksctl utils update-cluster-vpc-config` rejects the field rather than silently
ignoring it, and points at `vpc.controlPlaneSubnetIDs` instead.
Control plane subnet selection is now built through a single helper. autoMode is
passed into it rather than derived, so that it keeps applying only to VPCs that
eksctl creates: the pre-existing VPC path has never restricted the control plane
for Auto Mode clusters, and deriving it would have changed that behaviour for
configurations that do not use the new field.
Issue #8792
Signed-off-by: guessi <guessi@gmail.com>
* Address review feedback on controlPlaneOnPrivateSubnets
- Count distinct availability zones in c.AvailabilityZones when
validating controlPlaneOnPrivateSubnets for eksctl-created VPCs,
instead of assuming SetSubnets guarantees per-zone coverage.
Duplicate zones collapse into a single private subnet in
vpc.SetSubnets, and validateAvailabilityZones permits duplicates,
so this was previously unchecked.
- Rework the update-cluster-vpc-config tests for
controlPlaneOnPrivateSubnets to assert against
cmdutils.NewUpdateClusterVPCLoader(...).Load() directly instead of
executing the full command, which reached AWS via
NewProviderForExistingCluster.
- Change eksctl utils update-cluster-vpc-config to warn and ignore
vpc.controlPlaneOnPrivateSubnets instead of returning a hard error,
consistent with how eksctl update nodegroup handles other
unsupported fields in a config file.
- Update the userdocs claim that eksctl validates AZ coverage before
creating anything to note the pre-existing-subnets-by-ID exception,
where AZs are resolved from EC2 after validation runs.
* Don't reject controlPlaneOnPrivateSubnets when AZs are auto-selected
validateControlPlaneOnPrivateSubnets ran before eks.SetAvailabilityZones, so
when availabilityZones was left unset it saw an empty c.AvailabilityZones and
rejected the config with 'got 0 ([])', even though eksctl always selects
distinct zones itself on that path. Only enforce the distinct-zone count when
availabilityZones is explicitly set, and flip the test that had locked in the
rejection to expect success instead.
Document the auto-selection exception in the userdocs alongside the existing
pre-existing-subnets-by-ID one, as a nested list since the two exceptions no
longer read clearly as a single sentence.
Signed-off-by: guessi <guessi@gmail.com>
* Assert the update-cluster-vpc-config warning and document it
The loader test only asserted that no error was returned, which passes just as
well if the warn-and-ignore behaviour is dropped entirely. Capture logger output
and assert the warning text, and assert the field is not translated into
controlPlaneSubnetIDs. Verified the assertion fails when the warning is changed.
Document that the field only takes effect at cluster creation time and is warned
about and ignored by eksctl utils update-cluster-vpc-config, which the code did
but the docs did not mention.
Signed-off-by: guessi <guessi@gmail.com>
---------
Signed-off-by: guessi <guessi@gmail.com>
Copy file name to clipboardExpand all lines: pkg/apis/eksctl.io/v1alpha5/assets/schema.json
+6Lines changed: 6 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1181,6 +1181,11 @@
1181
1181
"description": "controls how the control plane routes egress traffic. Valid values: \"AWS_MANAGED\" (default), \"CUSTOMER_ROUTED\"",
1182
1182
"x-intellij-html-description": "controls how the control plane routes egress traffic. Valid values: "AWS<em>MANAGED" (default), "CUSTOMER</em>ROUTED""
1183
1183
},
1184
+
"controlPlaneOnPrivateSubnets": {
1185
+
"type": "boolean",
1186
+
"description": "restricts the control plane (the cross-account ENIs that EKS places in the cluster subnets) to private subnets only, excluding public subnets. It applies both when eksctl creates the VPC and when a pre-existing VPC is used. Cannot be combined with ControlPlaneSubnetIDs. Requires at least two private subnets spanning at least two availability zones, which must have NAT or the relevant VPC endpoints for nodes to reach the API server.",
1187
+
"x-intellij-html-description": "restricts the control plane (the cross-account ENIs that EKS places in the cluster subnets) to private subnets only, excluding public subnets. It applies both when eksctl creates the VPC and when a pre-existing VPC is used. Cannot be combined with ControlPlaneSubnetIDs. Requires at least two private subnets spanning at least two availability zones, which must have NAT or the relevant VPC endpoints for nodes to reach the API server."
0 commit comments