-
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
[aws-eks] Multiple object reference to Nested Stack causes Circular Dependency. #10020
Labels
@aws-cdk/aws-eks
Related to Amazon Elastic Kubernetes Service
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
p1
Milestone
Comments
Related to #9536 |
This was referenced Sep 13, 2020
mergify bot
pushed a commit
that referenced
this issue
Sep 14, 2020
…s are used (#10339) @eladb While working on this for the `aws-eks-next` module, i've started to second guess whether we really need to force cluster replacement. This little PR fixes all the circular dependency issues as well as corrects the `cluster.connections` to include the EKS managed cluster security group. **It does not require cluster replacement**. Merging this PR will leave two quirks/limitations: - The cluster will have a redundant control plane security group, just like it has now. While redundant, it doesn't hurt, and doesn't really justify a cluster replacement. - One cluster per stack, just like we have now. I think we've already agreed that this limitation also does not justify cluster replacement, and the only reason we wanted to implement it is because we wanted to piggy back on the previous argument, which I now believe is not strong enough. WDYT? -------- This PR resolves a few problem related to circular dependencies when the cluster is configured with security groups from other stacks. ## Problem Currently, the cluster creates a dedicated security group for the `KubectlProvider` and configures the main control plane security group to allow connections from it: https://github.com/aws/aws-cdk/blob/f5c5d060ffee19ac3daa47cbf6df8d3563133433/packages/%40aws-cdk/aws-eks/lib/cluster.ts#L918-L924 This eventually creates ingress rules in the stack of control plane security group. These ingress rules refer to the `KubectlProvider` creates in the cluster stack, hence, a dependency if formed between the control plane security group stack, and the cluster stack. `Control Plane Security Group Stack => Cluster Stack` (Control plane sg needs to allow connections from kubectl sg) On the other hand, the cluster stack naturally depends on the control plane security group stack because the cluster needs the security group when its created. And so: `Cluster Stack => Control Plane Security Group Stack` (Cluster needs the security group) When these two stacks are different, a circular dependency is created. ## Solution Do not create a security group for the `KubectlProvider` at all, and simply re-use the EKS managed security group. This security group is already configured to allow connections to the control plane, so if we simply attach it to the `KubectlProvider`, everything should work. This avoids the creation of the first dependency direction. Fixes #9754 Fixes #10020 Fixes #9536 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/aws-eks
Related to Amazon Elastic Kubernetes Service
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
p1
❓ General Issue
The
Cluster
interface creates circular dependency errors when multiple references to differingNestedStack
child-objects. I'm not sure if this is an implementation error withCluster
or an inherent design flaw withNestedStack
. It seems like a DAG would solve for this issue.Tool Spec
node@12
cdk@1.6
language=js
Error
Code Snippet
The text was updated successfully, but these errors were encountered: