The `integ.eks-cluster-handlers-vpc` test created an `eks.Cluster` with no
capacity override and an unpinned Kubernetes version, so it received the
cluster's default-capacity nodegroup on the AL2 (`AL2_x86_64`) AMI. EKS does
not support the AL2 AMI on Kubernetes 1.33+, so once the shared
`getClusterVersionConfig()` default advanced past 1.32, a real deploy of this
test began failing:
Resource handler returned message: "AMI Type AL2_x86_64 is only supported
for kubernetes versions 1.32 or earlier" (HandlerErrorCode: InvalidRequest)
on AWS::EKS::Nodegroup (the default-capacity nodegroup)
Synth and snapshot checks did not catch this because the failure only occurs
at deploy time against the EKS service. It surfaced during the EKS 1.37 bump
(aws#39501) via a manual real-cluster deploy on us-east-1.
Mirror the existing passing pattern in `integ.eks-cluster-private-endpoint`
and `integ.eks-cluster-imported`: set `defaultCapacity: 0` and add an explicit
nodegroup with the AL2023 (`AL2023_X86_64_STANDARD`) AMI, which is supported on
1.33+. Everything else the test exercises (notably `placeClusterHandlerInVpc`)
is preserved.
This change does not depend on aws#39501; it fixes a latent failure on main.
Issue # (if applicable)
No issue to close. This latent failure was surfaced during the EKS 1.37 bump (#39501) via a manual real-cluster deploy; it does not depend on that PR.
Reason for this change
The
integ.eks-cluster-handlers-vpcintegration test created aneks.Clusterwith no capacity override and an unpinned Kubernetes version (...getClusterVersionConfig(this)), so it received the cluster's default-capacity nodegroup on the AL2 (AL2_x86_64) AMI. EKS does not support the AL2 AMI on Kubernetes 1.33+. Once the sharedgetClusterVersionConfig()default advanced past 1.32, a real deploy of this test began failing:Synth and snapshot checks do not catch this because the failure only occurs at deploy time against the EKS service.
eks-cluster-handlers-vpcis the only unpinned EKS integ test that takes the default-capacity nodegroup; every other unpinned test already setsdefaultCapacity: 0and adds an explicit non-AL2 nodegroup.Description of changes
Mirror the existing passing pattern in
integ.eks-cluster-private-endpointandinteg.eks-cluster-imported:defaultCapacity: 0on the cluster (so no implicit AL2 nodegroup is created).addNodegroupCapacity('DefaultCapacity', { minSize: 2, amiType: AL2023_X86_64_STANDARD }), which is supported on 1.33+.Everything else the test exercises is preserved, notably
placeClusterHandlerInVpc: trueand its VPC/handler setup (the point of the test). The nodegroup keeps the construct idDefaultCapacity, so the logical ID is unchanged and the snapshot diff is limited to the nodegroup'sAmiType(and the now-defaultedInstanceTypes).Destructive change: this replaces the default-capacity nodegroup (
AmiTypechange requires replacement). This is expected and necessary — the previous AL2 nodegroup cannot deploy on k8s 1.33+.Describe any new or updated permissions being added
None.
Description of how you validated changes
Deployed the test to a real EKS cluster on
us-east-1withinteg-runner --update-on-failed. The stack reachedCREATE_COMPLETEand the default-capacity nodegroup came up ACTIVE withamiType: AL2023_x86_64_STANDARDon the latest Kubernetes version — confirming the fix (the previous AL2 nodegroup could not deploy). The stack was then torn down cleanly with no stranded clusters or stacks. The snapshot was updated to reflect the nodegroup change.Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license