EKS on Fargate

[outofcoffee]

EKS support for AWS Fargate is now generally available! #32 (comment)

---

This will allow customers to remove undifferentiated heavy lifting of operating worker nodes, whilst also being able to use the Kubernetes API.

Fargate for EKS reduces or removes the following operational concerns for worker nodes:

• patching
• configuration
• deployment
• secure defaults
• compatibility with backplane

@abby-fuller I'd appreciate your thoughts here.

[nikovirtala]

Fargate, as well as Fargate for EKS, was launched on re:Invent 2017, and since then we haven't heard a word about it from AWS. Even with my knowledge about Kubernetes, it relatively easy to say that removing the abstract of a node from Kubernetes is far from being an easy job. Maybe AWS chose a too big but to crack, and promised too much when said that it would be available in 2018? Nevertheless, it would be nice to hear where you are with this today. Many do appreciate your efforts of being more open, and I think it would work well also in this case.

[carlsendk]

Yea it would be great with a update on fargate. As its been a year now :-) or provide some information to handle worker nodes in a good way

[welemon]

It was told that Fargate support for EKS will be available within 2018, now that line was removed from Fargate home page, which is sad to see, instead of a transparent update. Some other reference still mention the schedule, such as https://aws.amazon.com/blogs/aws/aws-fargate/

Now we don't see this even on near term roadmap?

[paulopontesm]

Also waiting for this. Sad to see it tagged as "proposed", given that we read about this a year ago.

Azure apparently made it: https://azure.microsoft.com/en-us/blog/bringing-serverless-to-azure-kubernetes-service/

[jstrachan]

there's a blog on how to DIY your own kubernetes support on fargate but I was really hoping for native integration between EKS control plane and fargate to provide nodeless kubernetes support!

[ejc3]

There was a tiny bit of info provided here:
https://mobile.twitter.com/nathankpeck/status/1068287315917758464

[cdenneen]

Is this on the roadmap? I'm not seeing it.

Being able to deploy to Kubernetes endpoint via kubectl or helm is basically what people are looking for to avoid managing clusters, workers, task definitions, virtual-kublet, etc.

[arminc]

I think there are three levels in "managed":
First one is EKS where only the masters are managed and you do the rest. As a user, you can use all kind of services from AWS or your own because there are not 'many' restrictions.

The second one is a fully managed Kubernetes which means master and worker nodes. You can still do a lot of things because you have access to Kubernetes but there are limitations because you don't own the nodes.

The third and last one is Fargate which in my opinion should be an AWS opinionated stack for deploying containers on Kubernetes. This means for me for Fargate to be useful over EKS, AWS needs to provide a way to get secrets, ship logs, gather metrics, etc... in an opinionated way using AWS services. I shouldn't be bothered with IngressControllers I should be able to provide an Ingress for my service and it should be exposed. I am really interested in how AWS is planning to release Fargate for EKS while there are still features missing for EKS which in my opinion are needed to make Fargate working. I hope AWS can prove me wrong and come up with something fancy :)

Running an operator (for example Prometheus) on Fargate would that even make sense and how would that work?

[rprashad]

Would be nice to have access to docker.socket to do image builds via ci/cd in this managed eco-system.

[NaranKPatel]

I'm seeing increased customer interest on this too, curious if and when it'll launch.