(eks): support latest EKS engine version v1.22 #20263
Comments
mburket
added
bug
github-actions
bot
added
the
@aws-cdk/aws-eks
|
Echoing what @robertd mentioned above. We're working on reducing the module size to allow multiple versions of kubectl lambda layers, but at this time, we can't support |
|
|
Hi @robertd and @kaizencc. Now that The question came up on my team because one of the apps we use dropped support for We completely get the reasons for reverting support, and appreciate yall's transparency and consideration for users. Thank you for all you do. |
|
@sdenardi We are actively working on this via the Reduce Module Size RFC. In particular, @madeline-k is working on the lambda layer aspect of the RFC that will unlock the ability to create new layers (without massively increasing package size). I don't want to commit to a timeline atm, but this is in development and hopefully we can share further updates with y'all as they arise. |
kaizencc
added
blocked
kaizencc
changed the title
|
@kaizencc Are we doing the same thing in #20596, that @madeline-k is currently investigating? |
|
@kaizencc that RFC you mentioned seems abandoned, the last comment on it was over 3 weeks ago. I would absolutely love to put EKS forward as the IaC tool for our EKS setup (we currently using terraform for most things..), but the fact that CDK only supports the end-of-time V1.21 makes it impossible. Reading the comment on the roll-back, it seems like your issue is to support <= V.1.20 whilst supporting the new version. V1.18 && V1.19 are now officially deprecated and V.20 is due to be deprecated in November. |
|
@kaizencc AWS EKS 1.23 is available, but we can not upgrade even 1.21 using CDK :( |
|
starting migration to terraform next monday |
|
I'm not quite ready to abandon CDK, as it fits nicely with our other tooling and have served our needs well up to this point. It is a bit frustrating to not get any updates, while at the same time getting emails from AWS with the subject line:
|
|
I have a problem that I can't version up eks for cdk, but here is my understanding
Therefore, we believe we can adopt at least v1.22 by taking the following actions.
Frankly, I don't think it is appropriate to prevent the deployment of eks clusters for the sake of downward compatibility with lambda-layer-kubectl, so either add the ability to specify the version of lambda-layer-kubectl or truncate support for the oldest version. EKS is a version or two behind k8s, and we believe that there are many users who would like to increase their EKS version as much as possible. |
|
I agree with @watany-dev's #20263 (comment) . If we make this change, there will be a grace period before the next support expires. If RFC is merged in the meantime, it would be possible to support multiple versions of lambda-layer. |
|
Any ETA on this? AWS is already pushing v1.23 and we can't upgrade |
|
@cgarvis Do you know if you are able to release this next week? |
|
We were just affected by an issue with cluster autoscaler that doesn't appear to be backported to old |
|
@cgarvis how many |
|
I have advocated for the adoption of CDK over Terraform for new projects in my company and our new EKS stacks were our trial run. I am finally ready to admit defeat and swallow the sunk cost and begin the work importing the stack into Terraform. We are ~4 months away from end of support for EKS 1.21 and unable to update. This unacceptable level of support for EKS from the CDK is a risk I can't recommend my company continue to accept. |
|
Even if the development of EKS Blueprints is substantial, it is difficult to recommend to other engineers an IaC tool that cannot update the EKS cluster satisfactorily. |
|
We had put substantial effort on building the IaC using cdk and I would not like to ditch everything for a stupid issue. I started to feel that this issue will not be solved in anytime soon. Probably we have to build our own lambda layers ourselves |
|
we don't want to go through this again.please skip 1.22 and support v1.23 directly. |
If (I know, I know - this is a big if though) they solve it correctly, any version will be supported immediately, because they'll have automation to create separate lambda layers for each k8s version and the CDK constructs will automatically use the correct layer depending on which k8s version is passed. We adopted this approach several months ago and had no problems to update to 1.22 and later 1.23 with the CDK. |
|
Hi all, we have hit some snags in our implementation that would require breaking changes for non JS users. We met internal yesterday to discuss our options. We have decided to backing out of our current implementation and have come up with fix that we think we can get done this week. We will know on Friday if this will get in for next week's release. The approach should solve this issue once and for all so we won't have to go through this again. We did discuss with the EKS team, and it seems that you should be able to upgrade your EKS cluster while still using the 1.20 kubectl lambda layer. If you are worried about timelines, I would suggestion trying to upgrade. |
|
We instead ended up using the L1 CDK Construct We then handled AWS auth mapping and other bootstrapping processes later in the process via Helm or Kubectl once logged into the cluster. The only snag we encountered was EKS cluster bootstrap assigning Workaround there was to use the |
|
@johnnyhuy do you have slack ID on cdk.dev? Would love to discuss more details with you offline. Thanks. |
|
Have been struggling with this error for the last two days! Just today noticed this issue log. I would appreciate if AWS can provide solution. for mean time i will destroy my 1.23 stack and deploy with 1.21. I hope that works ! |
|
@cgarvis is it going to make it in this week's release? |
|
@cgarvis I tried upgrading the eks version with the current kubectl lambda layer. I succeeded upgrading the cluster from 1.21 to 1.22 and then to 1.23. But once I try adding a new Fargate profile I encounter the same issue as in here. So its still not a full solution. I ended up building our own lambda layer following the instruction provided by @Obirah and that works. I hope you guys land the proper fix soon. |
Of course not |
Add support for Kubernetes Version 1.22. In order to use this version, customers must pass in a `KubectlLayer` object from `@aws-cdk/lambda-layer-kubectl-v22` to the `kubectlLayer` construct prop of `Cluster`. Notes: - Updating integration tests are still in progress Closes #20263 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
|
So we got 1.22 merged into main. We are holding the release this week until we can get 1.23 (#22638). If things go well, you should see a new version out tomorrow. |
|
Thank you for the hard work and quick pivot after the blocker came up @cgarvis @madeline-k @kaizencc ! Really appreciate it 🙏 |
|
Thank you @cgarvis @madeline-k @kaizencc for this! It is a much needed feature. |
|
So Kubernetes 1.22 support is released in 2.48.0, which is out now. Cheers! |
|
@kaizencc do you know what the plan will be for 1.24 and 1.25? will it be supported with similar patches or is there a different solution in progress? |
|
1.24 isn't scheduled to be released until November 2022: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar At that time, we'll create a new lambda layer, We'll also add a static method in the eks module for ease-of-use, and run the integ tests to update the snapshots. This isn't a blocker however; you can always specify your kubectl version with All this is to say, this is our permanent solution, and there isn't anything to block you on the CDK side. The blocker here is that Amazon EKS support isn't expected until November. |
|
Great! Thanks for clarifying. |
and others
Describe the bug
We just updated the CDK version from 2.20 to 2.23 and we are using the latest EKS 1.22 version. Looks like the EKS 1.22 is removed from 2.22+.
Error from npm build: "error TS2551: Property 'V1_22' does not exist on type 'typeof KubernetesVersion'. Did you mean 'V1_20'?"
Expected Behavior
EKS v1.22 should not be removed.
Current Behavior
EKS v1.22 is not supported.
Reproduction Steps
Specify Kubernete version of V1_22 when create an EKS cluster using CDK 2.22+.
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.23
Framework Version
No response
Node.js Version
14
OS
Mac
Language
Typescript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: