Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[aws-eks] Circular dependency exist when deploying EKS FargateCluster #10528

Closed
tmokmss opened this issue Sep 25, 2020 · 2 comments · Fixed by #10536
Closed

[aws-eks] Circular dependency exist when deploying EKS FargateCluster #10528

tmokmss opened this issue Sep 25, 2020 · 2 comments · Fixed by #10536
Assignees
@iliapolo
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 p0
Milestone
[DevPreview] @aws...

Comments

@tmokmss
Copy link
Contributor

tmokmss commented Sep 25, 2020 •
edited
Loading

I cannot deploy EKS FargateCluster because of circular dependency.

Reproduction Steps

CDK code

import * as eks from '@aws-cdk/aws-eks';
import * as cdk from '@aws-cdk/core';

export class EksTestStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const cluster = new eks.FargateCluster(this, 'cluster', {
      version: eks.KubernetesVersion.V1_17,
    })
  }
}

and deploy by the command below:

npm run cdk deploy EksTestStack

What did you expect to happen?

deployment succeeds

What actually happened?

The error below occurs:

 EksTestStack (eks-test) failed: Error [ValidationError]: Circular dependency between resources: 
[clusterRole88D0C969, clusterDefaultVpcVPCGWB52AB94D, clusterMastersRoleEABFBB9C, clusterDefaultVpcPublicSubnet3NATGateway5D6BCE9C, clusterDefaultVpcPrivateSubnet1RouteTableAssociation941EEF5E, clusterDefaultVpcIGWEA83F638, clusterDefaultVpcPublicSubnet3SubnetCF380ECB, clusterfargateprofiledefault40EAF542, clusterDefaultVpcPrivateSubnet3RouteTable68FAA6DE, clusterfargateprofiledefaultPodExecutionRoleB7B70029, awscdkawseksKubectlProviderNestedStackawscdkawseksKubectlProviderNestedStackResourceA7AEBA6B, clusterDefaultVpcPublicSubnet2NATGateway4B5BF1A3, clusterKubectlReadyBarrier17584D5B, clusterDefaultVpcPublicSubnet1RouteTableAssociationF21DD285, clusterControlPlaneSecurityGroup7F1D5AB2, clusterDefaultVpcPrivateSubnet2RouteTable9A709948, clusterDefaultVpcPublicSubnet3RouteTableDF03BEAA, clusterDefaultVpcPrivateSubnet3RouteTableAssociation1051D4E6, clusterCreationRoleDefaultPolicy69503D2C, awscdkawseksClusterResourceProviderNestedStackawscdkawseksClusterResourceProviderNestedStackResource9827C454, clusterDefaultVpcPublicSubnet3DefaultRoute6DFF6152, clusterDefaultVpcPrivateSubnet2DefaultRoute29031EDD, clusterDefaultVpcPrivateSubnet3SubnetB16AB70B, clusterDefaultVpcPublicSubnet1DefaultRoute008A2768, clusterDefaultVpcPrivateSubnet1DefaultRoute1A3591A8, clusterDefaultVpcPublicSubnet2SubnetD89F8A7D, clusterDefaultVpcPrivateSubnet1RouteTable6588FE09, clusterAwsAuthmanifestB57F2A94, clusterDefaultVpc83B86FBD, clusterDefaultVpcPrivateSubnet1Subnet56973734, clusterDefaultVpcPrivateSubnet2Subnet3A49BF39, clusterDefaultVpcPublicSubnet2RouteTable4B281F43, clusterDefaultVpcPublicSubnet1RouteTableFD55F525, clusterCoreDnsComputeTypePatchE0553C88, clusterDefaultVpcPublicSubnet2DefaultRoute3C6354F6, clusterCreationRole2B3B5002, clusterDefaultVpcPrivateSubnet3DefaultRouteFE3587F6, clusterDefaultVpcPublicSubnet2EIP92893124, clusterDefaultVpcPublicSubnet3EIP3576AE12, clusterDefaultVpcPublicSubnet1Subnet6A0D5072, clusterDefaultVpcPublicSubnet1EIP0E34F4D0, clusterDefaultVpcPublicSubnet1NATGateway3F34F14E, clusterDefaultVpcPublicSubnet2RouteTableAssociation8D159B16, clusterDefaultVpcPrivateSubnet2RouteTableAssociation188551CD, clusterDefaultVpcPublicSubnet3RouteTableAssociationEC89C4A6, clusterC5B25D0D]

Environment

  • CLI Version : 1.64.0
  • Framework Version: 1.64.0
  • Node.js Version: v13.11.0
  • OS : macOS
  • Language (Version): TypeScript

Other

This is 🐛 Bug Report
@tmokmss tmokmss added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Sep 25, 2020
@github-actions github-actions bot added the @aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service label Sep 25, 2020
@tmokmss
Copy link
Contributor Author

tmokmss commented Sep 25, 2020 •
edited
Loading

succeeded in deploying when using cdk 1.61.0.
It seems there's a problem somewhere between 1.62.0 to 1.64.0.

@iliapolo iliapolo mentioned this issue Sep 25, 2020
Merged
@iliapolo iliapolo added effort/small Small work item – less than a day of effort p0 in-progress This issue is being actively worked on. and removed needs-triage This issue or PR still needs to be triaged. labels Sep 25, 2020
@iliapolo iliapolo added this to the [DevPreview] EKS milestone Sep 25, 2020
@iliapolo
Copy link
Contributor

@tmokmss Thanks for reporting this. We are investigating a fix and we'll update here.

@iliapolo iliapolo mentioned this issue Sep 25, 2020
Closed
@mergify mergify bot closed this as completed in #10536 Sep 25, 2020
mergify bot pushed a commit that referenced this issue Sep 25, 2020
@iliapolo
fix(eks): KubernetesPatch and FargateCluster creates a circular d…
b23ce03 
…ependency and breaks deployment (#10536)

In version [`1.62.0`](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) we introduced the ability to run `kubectl` commands on imported clusters. (See #9802).

Part of this change included some refactoring with regards to how we use and create the `KubectlProvider`.
Looks like we didn't consistently apply the same logic across all constructs that use it.

Case in point:

https://github.com/aws/aws-cdk/blob/e349004a522e2123c1e93bd3402dd7c3f9c5c17c/packages/%40aws-cdk/aws-eks/lib/k8s-manifest.ts#L58

Notice that here we use `this` as the scope to the `getOrCreate` call. Same goes for:

https://github.com/aws/aws-cdk/blob/e349004a522e2123c1e93bd3402dd7c3f9c5c17c/packages/%40aws-cdk/aws-eks/lib/k8s-object-value.ts#L64

However, `KubernetesPatch` use `scope` instead.

https://github.com/aws/aws-cdk/blob/e349004a522e2123c1e93bd3402dd7c3f9c5c17c/packages/%40aws-cdk/aws-eks/lib/k8s-patch.ts#L74

This means that the entire `scope` of the `KubernetesPatch` now depends, among others, on the `kubectlBarrier`. 
The scope will usually be either the cluster itself (when using `FargateCluster`), or the entire stack (when using `new KubernetesPatch`). In any case, the scope will most likely contain the cluster VPC.

This creates the following dependency cycle: `Cluster => ClusterVpc => KubectlBarrier => Cluster`.

The fix aligns the `KubernetesPatch` behavior to all other `kubectl` constructs and uses `this` as the scope, which will only add dependency on the barrier to the custom resource representing the patch.

Fixes #10528
Fixes #10537

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@iliapolo iliapolo removed the in-progress This issue is being actively worked on. label Sep 25, 2020
@iliapolo iliapolo changed the title [eks] Circular dependency exist when deploying EKS FargateCluster [aws-eks] Circular dependency exist when deploying EKS FargateCluster Sep 25, 2020
iliapolo added a commit that referenced this issue Sep 25, 2020
@iliapolo
fix(eks): KubernetesPatch and FargateCluster creates a circular d…
f0f8a63 
…ependency and breaks deployment (#10536)

In version [`1.62.0`](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) we introduced the ability to run `kubectl` commands on imported clusters. (See #9802).

Part of this change included some refactoring with regards to how we use and create the `KubectlProvider`.
Looks like we didn't consistently apply the same logic across all constructs that use it.

Case in point:

https://github.com/aws/aws-cdk/blob/e349004a522e2123c1e93bd3402dd7c3f9c5c17c/packages/%40aws-cdk/aws-eks/lib/k8s-manifest.ts#L58

Notice that here we use `this` as the scope to the `getOrCreate` call. Same goes for:

https://github.com/aws/aws-cdk/blob/e349004a522e2123c1e93bd3402dd7c3f9c5c17c/packages/%40aws-cdk/aws-eks/lib/k8s-object-value.ts#L64

However, `KubernetesPatch` use `scope` instead.

https://github.com/aws/aws-cdk/blob/e349004a522e2123c1e93bd3402dd7c3f9c5c17c/packages/%40aws-cdk/aws-eks/lib/k8s-patch.ts#L74

This means that the entire `scope` of the `KubernetesPatch` now depends, among others, on the `kubectlBarrier`. 
The scope will usually be either the cluster itself (when using `FargateCluster`), or the entire stack (when using `new KubernetesPatch`). In any case, the scope will most likely contain the cluster VPC.

This creates the following dependency cycle: `Cluster => ClusterVpc => KubectlBarrier => Cluster`.

The fix aligns the `KubernetesPatch` behavior to all other `kubectl` constructs and uses `this` as the scope, which will only add dependency on the barrier to the custom resource representing the patch.

Fixes #10528
Fixes #10537

----

*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
Assignees

@iliapolo iliapolo

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 p0
Projects
None yet
Milestone
[DevPreview] @aws-cdk/aws-eks
2 participants
@iliapolo @tmokmss