[Ideas] End-to-end EKS Terraform module testing with Karpenter - gap analysis and what's needed

[ajaykumarmandapati]

Background

The EKS service (#493) is a great foundation. We've been exploring whether floci can replace AWS for local testing of a production EKS Terraform module (using Terratest). Most supporting services - S3, EFS, SQS, CloudWatch Logs, Route53, Secrets Manager - are already there. Here's where we hit walls:

Gap 1: Karpenter node provisioning (EC2)

Our module uses Karpenter (not managed node groups) for autoscaling. Karpenter provisions nodes via ec2:RunInstances with karpenter.sh/discovery tags, then discovers them via ec2:DescribeInstances. Since floci has real EC2 (Docker-backed), this might already work or be close. Has anyone tried pointing a Karpenter controller at floci's EC2 service?

Gap 2: EKS Access Entries

Tests validate SSO RBAC via eks:CreateAccessEntry, eks:DescribeAccessEntry, and eks:ListAccessEntries. These aren't in the current EKS implementation.

Gap 3: EKS Pod Identity

eks:CreatePodIdentityAssociation is used to map Kubernetes ServiceAccounts to IAM roles without long-lived credentials. Not currently implemented.

Gap 4: FIS (Fault Injection Simulator)

Spot interruption chaos tests use fis:StartExperiment. Minor priority but worth noting.

What would unblock most of the test suite

Gaps 2 and 3 (Access Entries + Pod Identity) are pure EKS API additions with no Docker backing needed - metadata only. Gap 1 (Karpenter + EC2) is the most interesting and potentially already partially working.

Happy to contribute. Would love input on Gap 1 especially - whether floci's EC2 emulation is intended to handle the tag-based discovery pattern Karpenter uses.

[hectorvent]

Hi @ajaykumarmandapati,

Thanks for taking the time and reporting these gaps.
Would you like to report pending fixes or feature as issues?

Thanks!

[ajaykumarmandapati]

I'd believe these are more features IMHO 🙂