[aws-eks] Remove support for non-kubectlEnabled clusters

Currently when instantiating an EKS cluster, a user can configure kubectlEnabled: false:

new eks.Cluster(this, 'Cluster', {
  kubectlEnabled: false
});

This will cause the resource to fallback to its pure CfnCluster implementation, which is more limited than the implementation with the custom resource.

Lets remove this code path and simply have all clusters be implemented with a custom resource, and thus all with kubectlEnabled: true by default.

Use Case

Supporting both scenarios creates a big maintenance burden and some strange quirks. For example, private cluster endpoint access is not supported by CfnCluster, but its not strictly related to the ability to run kubectl commands, so forcing the user to enable kubectl in order to configure private endpoint access is un natural.

On the other hand, supporting this feature for the pure CfnCluster use-case requires a big investment without good cause. I believe this code deviation is just a consequence of development cycles, and not necessarily intentional. There really is no reason why customers would opt to only use the pure CfnCluster.

Proposed Solution

Simply drop the kubectlEnabled flag, and use the custom resource implementation for all resources.

Other

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

---

This is a 🚀 Feature Request

[iliapolo]

I see. So this means that in regions where this layer isn’t published, one would now use eks.LegacyCluster instead of using eks.Cluster with kubectlEnabled: false.

I agree that since we plan on removing eks.LegacyCluster eventually, this issue needs to be resolved. Taking this into consideration - Thanks!

[kaylanm]

@kaylanm Could you explain why? What in this change affects the layer?

This change makes the layer mandatory. The layer isn’t published in SAR for all partitions, and there is no way to specify the ARN of your own SAR publication, so it’s not possible to use this construct in that case.