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.

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] ‼️ NOTICE: FargateCluster and KubernetesPatch breaks deployment #10537

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

[aws-eks] ‼️ NOTICE: FargateCluster and KubernetesPatch breaks deployment #10537

iliapolo opened this issue Sep 25, 2020 · 2 comments · Fixed by #10536
Assignees
Labels
@aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service management/tracking Issues that track a subject or multiple issues

Comments

@iliapolo
Copy link
Contributor

iliapolo commented Sep 25, 2020

Please add your +1 👍 to let us know you have encountered this


Status: RESOLVED

Overview:

Starting from version 1.62.0, the following scenarios are unable to deploy:

Fargate Cluster

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,
    })
  }
}

Kubernetes Patch

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.Cluster(this, 'cluster', {
      version: eks.KubernetesVersion.V1_17,
    })

    new eks.KubernetesPatch(this, 'Patch', {...});
  }
}

Complete Error Message:

Circular dependency between resources: [...]

Workaround:

No workaround at the moment.

Solution:

We've released a patch: 1.64.1

Related Issues:

Originally reported in #10528

@iliapolo iliapolo added management/tracking Issues that track a subject or multiple issues @aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service labels Sep 25, 2020
@iliapolo iliapolo pinned this issue Sep 25, 2020
@mergify mergify bot closed this as completed in #10536 Sep 25, 2020
mergify bot pushed a commit that referenced this issue Sep 25, 2020
…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
Copy link
Contributor Author

Re-opening until we release a version that includes the fix

@iliapolo iliapolo reopened this Sep 25, 2020
iliapolo added a commit that referenced this issue Sep 25, 2020
…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
Copy link
Contributor Author

Issue was resolved and the fix is now part of 1.64.1

@iliapolo iliapolo unpinned this issue Nov 2, 2020
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 management/tracking Issues that track a subject or multiple issues
Projects
None yet
1 participant