[EKS] [request]: Project Bophades - Run EKS containers on AWS Lambda

[QuinnyPig]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request I want the option to run containers on AWS Lambda for a variety of reasons--quick capacity surges, easy cross-region container placement, and enforced ephemerality among them.

Which service(s) is this request for? EKS, with a sprinkling of Lambda

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? I would like, in addition to the current option of running containers on Fargate (which still requires a bit of setup work per AWS account / region) to also have the option to instantiate workloads (either temporarily or steady-state) on AWS Lambda via its ability to support Docker containers as runtime images.

Are you currently working around this issue? I am currently not using EKS and hoping to change that.

Additional context I understand that this request may sound deranged, but it's not. I already do CI/CD deployments this way via Lambda + self-hosted GitHub Actions runners; the model works, and is orchestrated via Step Functions.

Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[rothgar]

Can you help me understand what you'd want? Which would be preferred?

1. The lambda service to be a kubernetes node (like fargate) that you schedule pods to but are backed by functions (would require using lambda base containers)
2. A lambda function to be a pod (long running) which are scheduled to regular nodes but backed by lambda functions
3. A lambda function to be a short lived pod (like knative and openfaas) but more like an async job in Kubernetes
4. Lambda functions as native resource types (via CRDs) you manage via Kubernetes API

Each of those options would have different implications for other parts of the cluster (eg how they get exposed in the cluster and how services/routing works). The 4th option is available today via ACK (example here https://aws.amazon.com/blogs/compute/deploying-aws-lambda-functions-using-aws-controllers-for-kubernetes-ack/ )

[joebowbeer]

I also have questions about what features of the Lambda experience are missing from EKS. Usually when this question comes up, it as framed as a request for scale-to-zero, which is possible already with KEDA.

@rothgar another option you missed is virtual kubelet + KEDA + Azure Functions, which as far as I know can also run on AWS. I'm hoping that Lambda v2 will look something like that.

[alanraison]

Unfortunately, although Lambdas can be packaged as container images, there’s an API that must be called to fetch the triggering event and report status when it finishes. Therefore you couldn’t really run arbitrary containers in lambda; they would have to be modified to work with the lambda runtime.

[RichiCoder1]

they would have to be modified to work with the lambda runtime.

This is my point of confusion too. Lambda isn't (at the moment) a generic container runtime, it has very specific opinions about the things it runs and how it interfaces with that. I sort of get the underlying ask, but it sounds like the real requirement/desire here is to make Fargate pods more flexible and simple ala Lambda. (IIRC, they're both functionally firecracker-based emphemeral compute, fargate is just more restrictive)