feat: add default kms encrypted gp3 StorageClass and PersistentVolume…

[dianibar]

Add a default KMS-encrypted gp3 StorageClass and PersistentVolumeClaim generator

[neoakris]

Left comments on requested changes

[neoakris]

I merged integration into your feature branch and then tested locally.
It doesn't deploy for me.

When I do a fresh install I get

4:26:52 PM | CREATE_FAILED        | Custom::AWSCDK-EKS-KubernetesResource | defaultEBSClassStorage41025CF0
Received response status [FAILED] from custom resource. Message returned: TooManyRequestsException: Rate Exceeded.

I suspect this issue is the result of order of operations.
I think the logic is trying to introduce your change too soon, and it needs to deploy your change at a later time.

A solution I think might work is to implement something like this

nodeLocalDNSCache.node.addDependency(cluster.awsAuth);

But more like this:

StorageClassManifests.node.addDependency(cluster.awsAuth);
//actually the following is probably even better
StorageClassManifests.node.addDependency(ebs_csi_addon);

^-- this should make it, so your logic doesn't start executing until after the cluster.awsAuth/csi addon is fully established/deployed

[neoakris]

I believe ReadWriteMany is an incorrect value for EBS, I think it should be ReadWriteOnce

[neoakris]

storageclass should be indented 4 spaces

[neoakris]

This should be refactored.
./lib/Easy_EKS.ts line 243 runs a kms.Key.fromLookup already

you adding a 2nd lookup is inefficient, I'd recommend the following refactor.

add variable const kmsKey: cdk.aws_kms.IKey
to ./lib/Easy_EKS_Config_Data.ts

then change line 243 to initialize that variable
basically replace
const kms_key = kms.Key.fromLookup(this.stack, 'pre-existing-kms-key', { aliasName: this.config.kmsKeyAlias });
with
this.config.kmsKey = kms.Key.fromLookup(this.stack, 'pre-existing-kms-key', { aliasName: this.config.kmsKeyAlias });

Then your storage class's

"kmsKeyId": `${kms_key.keyArn}`

can be updated to use, variable (this way we do the lookup only once)

"kmsKeyId": `${config.kmsKey.keyArn}`

[neoakris]

request:
can storage_class_gp3's YAML component be moved into config.

(reasoning behind the request)

• I saw you split storage_class_gp3 into a lib
  (my guess is you did that based on guidance I shared about a good rule of thumb is to abstract away complexity into lib)
  I owe you an apology as I think you used this location based on my previous guidance, which was incomplete, so now I'm asking you to move something after you put it where I requested you put it. Which is why I'm asking for forgiveness at giving incomplete guidelines.
• Karpenter.sh (what you used as a reference) was split into lib for 2 reasons.
  1. It's sufficiently complex (250 lines)
  2. I kept the config a user may wish to review in config, and split config a user wouldn't care about into lib.
• 2nd piece of guidance that I forgot to share originally. (this ranks higher than request to abstract away complexity) try to keep config that a user may want to edit or review within config.
  • I doubt an end user would want to edit the config of the storage class, but I do believe they'd want to review it.
  • Because it's not overly complex and is useful for end users to review I think storageclass.yaml belongs in ./config/eks/my_orgs_baseline_eks_config.ts

when it comes to the persistent volume claim, I think it makes more sense to put it in ./config/eks/dev_eks_config.ts's deploy_workload_dependencies(), because it's functioning like a demo manifest, and since it's a demo it wouldn't belong in my_orgs_baseline (as that's intended to get applied to all environments dev, test, stage, prod) and demo apps wouldn't be appropriate to deploy to prod, but storage class would. (which is why storage_class.yaml makes sense here in ./config/eks/my_orgs_baseline_eks_config.ts, but pvc.yaml should be moved to ./config/eks/dev_eks_config.ts)

---

further point of clarification:
It'd be fine to put the pvc.yaml inline in ./config/eks/dev_eks_config.ts
or put the PVC's logic in lib/demo_manifests.ts and call the lib function from ./config/eks/dev_eks_config.ts