-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(eks): support for Kubernetes version 1.22 #22604
Conversation
The EKS Cluster construct has a property called `kubectlLayer`. When this property was not given, it would add a two default layers to the custom resource: - One with kubectl - One with the AWS CLI However, if the property was given, the one layer must contain both kubectl as well as the AWS CLI. This makes the `kubectl` layer unnecessarily large -- it must also contain the AWS CLI which the CDK already has and can bundle itself. Add a separate `awscliLayer` parameter to control the AWS CLI layer, if the user so wants. If not, the default AWS CLI layer will be added. If some user is already using a `kubectlLayer` which includes the AWS CLI, we now add both the default AWS CLI layer as well as the user's kubectl layer with the AWS CLI in it. There is no conflict: multiple layers can contain the same files. Last layer wins (which is the kubectl layer with the user's preferred AWS CLI).
Co-authored-by: Eli Polonsky <[email protected]>
…ws-cdk into huijbers/eks-separate-awscli-layer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a section to the readme here about providing custom kubectl CLI versions. I think important things to call out are.
- The version of kubectl provided must be compatible with the Kubernetes version that the cluster is using.
- A basic code example of importing the kubectl asset package and passing to the appropriate prop.
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
can we include 1.23 also in this pr? I think #22544 tried something like that but your PR is more "complete". |
@henrysachs , we are planning to do 1.23 and 1.24 in the same manner as this. But, those will come in subsequent PRs. |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
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 thekubectlLayer
construct prop ofCluster
.Closes #20263
All Submissions:
Adding new Unconventional Dependencies:
New Features
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