[aws-eks] Add EKS Cluster Lookup method

[juanjoDiaz]

Enable EKS cluster lookups simular to VPC lookup (using only the ID or the ARN).
Currently, the closes thing is fromClusterAttributes which requires information about the VPC, the security groups, etc, which seems really unnecessary to me

aws-cdk/packages/@aws-cdk/aws-eks/lib/cluster.ts

Lines 59 to 90 in be6666b

	export interface ClusterAttributes {
	/**
	* The VPC in which this Cluster was created
	*/
	readonly vpc: ec2.IVpc;
	/**
	* The physical name of the Cluster
	*/
	readonly clusterName: string;
	/**
	* The unique ARN assigned to the service by AWS
	* in the form of arn:aws:eks:
	*/
	readonly clusterArn: string;
	/**
	* The API Server endpoint URL
	*/
	readonly clusterEndpoint: string;
	/**
	* The certificate-authority-data for your cluster.
	*/
	readonly clusterCertificateAuthorityData: string;
	/**
	* The security groups associated with this cluster.
	*/
	readonly securityGroups: ec2.ISecurityGroup[];
	}

Use Case

I am creating an EKS cluster using CDK.
In a separate stack, I would like to add a Fargate profile. I have no easy way to get the cluster so I can pass it to the FargateProfile constructor.
There is no easy way to do so.

Proposed Solution

A similar solution as what's used in the VPC module

aws-cdk/packages/@aws-cdk/aws-ec2/lib/vpc.ts

Lines 993 to 1032 in c475783

	public static fromLookup(scope: Construct, id: string, options: VpcLookupOptions): IVpc {
	if (Token.isUnresolved(options.vpcId)
	|| Token.isUnresolved(options.vpcName)
	|| Object.values(options.tags || {}).some(Token.isUnresolved)
	|| Object.keys(options.tags || {}).some(Token.isUnresolved)) {
	throw new Error('All arguments to Vpc.fromLookup() must be concrete (no Tokens)');
	}
	const filter: {[key: string]: string} = makeTagFilter(options.tags);
	// We give special treatment to some tags
	if (options.vpcId) { filter['vpc-id'] = options.vpcId; }
	if (options.vpcName) { filter['tag:Name'] = options.vpcName; }
	if (options.isDefault !== undefined) {
	filter.isDefault = options.isDefault ? 'true' : 'false';
	}
	const attributes: cxapi.VpcContextResponse = ContextProvider.getValue(scope, {
	provider: cxapi.VPC_PROVIDER,
	props: {
	filter,
	returnAsymmetricSubnets: true,
	subnetGroupNameTag: options.subnetGroupNameTag,
	} as cxapi.VpcContextQuery,
	dummyValue: undefined,
	}).value;
	return new LookedUpVpc(scope, id, attributes || DUMMY_VPC_PROPS, attributes === undefined);
	/**
	* Prefixes all keys in the argument with `tag:`.`
	*/
	function makeTagFilter(tags: { [name: string]: string } | undefined): { [name: string]: string } {
	const result: { [name: string]: string } = {};
	for (const [name, value] of Object.entries(tags || {})) {
	result[`tag:${name}`] = value;
	}
	return result;
	}
	}

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[samuelthan]

love to see this feature.
Helps me with trying to get the default security group that was created by AWS EKS.

At the moment i'm using boto3 to pull this information which seems a bit ugly in the cdk world.

Vote +1

[juanjoDiaz]

Any progress on this?

As said, I'd be happy contributing this feature but I'll probably need some guidance on how to implement it so it's consistent with the other lookups in the library.

[eladb]

Related to #8608

[rcollette]

I am having a similar issue trying add a Fargate service in a CDK application that is separate from the CDK application that creates the cluster. I'm using a combination of ssm parameters using a naming convention to store cluster properties, and Cluster.fromClusterAttributes(), but now I'm running into.

Cannot enable service discovery if a CloudMap Namespace has not been created in the cluster.

The defaultCloudMapNamespace is an object that cannot be serialized to JSON due to cyclical references and it cannot be reconstructed (or at least it seems difficult to do so) because it is not a pure interface, having properties for Stack and Node classes.

If a Cluster instance can be obtained with Cluster.fromLookup() and it's properties including the defaultCloudMapNamespace populated, it would enable creating a Fargate service with CloudMap enabled.

[sunshineo]

Our use case need to allow EKS cluster to access an RDS. We tried to have the RDS creation and allow access in a separate repository, but the EKS cluster we get from fromClusterAttributes did not work. And it failed silently

const eksCluster = eks.Cluster.fromClusterAttributes(this, 'cdk-managed-eks-cluster', { clusterName: 'cdk-managed-eks-cluster', })
const rdsCluster = new rds.DatabaseCluster(this, 'Database', {...});
rdsCluster.connections.allowFrom(eksCluster.connections, rdsPort, 'Allow eks cluster to connect to rds')

The code above works if we create the eks cluster in the same stack.

[iliapolo]

This issue has been re-classified as p2. That means a workaround is available or it is deemed a nice-to-have feature. Given the amount of work there is to do and the relative priority of this issue, the CDK team is unlikely to address it. That does not mean the issue will never be fixed! If someone from the community submits a PR to fix this issue, and the PR is small and straightforward enough, and meets the quality bars to be reviewed and merged with little effort we will accept that PR. PRs that do not build or need complex or multiple rounds of reviews are unlikely to be merged and will be closed to keep our backlog manageable.

We use +1s on this issue to help prioritize our work, and are happy to re-evaluate the prioritization of this issue based on community feedback. You can reach out to the cdk.dev community on Slack to solicit support for reprioritization.

[petteriv-nordic]

@iliapolo What is the workaround you mentioned above?

[iliapolo]

@petteriv-nordic

That means a workaround is available or it is deemed a nice-to-have feature.

This currently is classified as a nice-to-have, no workaround available.

[taabrcr]

Vote +1 from my side as well, as this is a very much needed feature

[mauritz-lovgren]

When creating an ECS service in a separate CDK project from the project that deploys the ECS Cluster (typically if the latter sets up 'general aspects' for the environment and the former creates service specific resources), the defaultCloudMapNamespace created in the environment CDK project is only available to the service CDK project by knowing a lot of details of the namespace defined in the latter.

One might expect that the defaultCloudMapNamespace was available after look up of Cluster in the 'service CDK project' when using Cluster.fromClusterAttributes or Cluster.fromClusterArn?

Currently, we need to do the following when looking up the cluster to provide the namespace to an ECS service:

const cluster = ecs.Cluster.fromClusterAttributes(this, 'Cluster', {
  clusterName: clusterName,
  vpc: vpc,
  defaultCloudMapNamespace: cloudmap.PrivateDnsNamespace.fromPrivateDnsNamespaceAttributes(
      this, 'Namespace', {
        namespaceArn: Arn.format({
          service: 'servicediscovery',
          resource: 'namespace',
          resourceName: namespaceId
        }, this),
        namespaceId,
        namespaceName
      }
});

[nikolic-milan]

Hello,

has there been any progress on this? We have a use case where we have a repository that defines and sets up the cluster infrastructure, and then other repositories for different apps we want to deploy in the cluster. Currently, I can't figure out a way to add the app to the cluster from a different repository. Using the from_cluster_attributes to get the cluster, I can't perform the add_manifest operation. I tried defining the kubectl_role_arn property that is required to enable kubectl execution, but there is always an issue with the roles I add, and I tried all the roles that are connected to the cluster, which have an arn.

Am I missing something, do I need to create a specific role for this? Or is it just not currently possible?

What about the add_helm_chart method, will that work on a cluster found from arn?

Kind Regards,
Milan Nikolić

[HumbleBeck]

Hi, this might have been overlooked, but are there any plans to implement this?