-
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): programmatic definition of kubernetes resources #3510
Conversation
This change allows defining arbitrary Kubernetes resources within an EKS cluster.
A general question here, what is thought process behind |
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 you talk about all the YAML parsing work? I didn't really review it, but I'm not sure exactly what drove the creation?
I left a few comments based on a quick pass.
@@ -273,6 +361,7 @@ export class Cluster extends Resource implements ICluster { | |||
|
|||
this.addAutoScalingGroup(asg, { | |||
maxPods: maxPodsForInstanceType(options.instanceType), | |||
mapRole: options.mapRole, | |||
}); | |||
|
|||
return asg; |
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.
If a user wants to add IAM statements to the role for the worker nodes they would use this return right?
const iamEnabledNodes = eksCluster.addCapacity( ... )
iamEnabledNodes.addToRolePolicy( // special IAM permissions for managing IAM to pods // )
I've seen a lot of patterns where teams run sensitive workloads on a specific node group, that they might have previously run on master nodes.
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 think this can be resolved. The ergonomics here are a little awkward for me. Add hands back an entity that you can't access from the class. However, I think the use case is met.
const uniqueId = crypto.createHash('md5').update(this.node.path).digest("hex"); | ||
const version = props.version || '1.13.7'; | ||
|
||
this.stack.templateOptions.transforms = [ 'AWS::Serverless-2016-10-31' ]; // required for AWS::Serverless |
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.
This needs a check for existing transforms and conflicts therein.
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.
Ping. This is still a recipe for disaster if people combine with other transforms, or other versions of the Serverless transform.
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'll add some support in Stack
for this (stack.addTransform()
). Let me open an issue.
packages/@aws-cdk/aws-eks/lib/manifest-resource/yaml/composer.py
Outdated
Show resolved
Hide resolved
This adds the capability of adding a target to an event rule that belongs to a different account than the rule itself. Required for things like cross-account CodePipelines with source actions triggered by events.
…3487) Our logic for trimming the length of the default IAM policy name was not working, as it wasn't updated when logicalId became a Token rather than a literate string, and so it was never actually triggered (it just checked that the display name of the Token was less than 128 characters, which it always is). The fix is to resolve the logical ID Token before applying the trimming logic. Fixes #3402
Add new addContainerDependencies method to allow for container dependencies Fixes #2490
Grants on the `alias/aws/sqs` KMS key alias are not necessary since the key will implicitly allow for it's intended usage to be fulfilled (as opposed to how you have to manage grants yourself when using a user-managed key instead). This removes the statement that was generated using an invalid resource entry. Fixes #2794
Fixes #3264 I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so: aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::{account_id}:role/a_lambda_execution_role But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this: myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN)) With the error: Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal This PR allows ArnPrincipal to be passed to lambda.grantInvoke. There might be some additional validation required on the exact ARN as I believe only some ARNs are supported by lambda add-permission
* rename `KubernetesManifest` to `KubernetesResource` and `addResource` * move AWS Auth APIs to `cluster.awsAuth` and expose `AwsAuth` * remove the yaml library (we can just use a JSON stream) * add support for adding accounts to aws-auth * fix cluster deletion bug * move kubctl app info to constants
@moofish32 @rix0rrr can you please take another look? I think I've addressed most of your comments. |
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.
Provisional approval, do what you will with my previous comments :). How does that work these days?
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
Enable programmatically defining Kubernetes resources and applying them through CloudFormation to the EKS cluster.
This enables the following:
Sadly, in order for this to be possible, we had to use a custom resource (credits @NetaNir) in order to provision the EKS cluster. See the README file for details on why.
Please read the contribution guidelines and follow the pull-request checklist.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license