Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
AWS Fargate provider #127
This implements AWS Fargate as a new provider for the virtual-kubelet.
Not yet supported features:
Shameless plug @elblivion and I also wrote a blog post around using the virtual-kubelet with fargate https://www.contentful.com/blog/2018/04/10/sailing-into-infinity-seamlessly-managed-serverless-containers-using-kubernetes-and-aws-fargate/
referenced this pull request
Apr 10, 2018
From a quick look, the code looks good to me. I implemented something last December on a similar fashion here https://github.com/Raffo/virtual-kubelet/tree/master/providers/ecs and as commented in #12 but I stopped cause I had a lot of questions unanswered, namely:
All of this made me desist to go on with my implementation, but I'd be really looking forward to understand if you are really going to plan to use this and if it is satisfying any real life use case.
This is currently still to be done, but routing Pod ~> Pod already works as the IP of the Pod running in Fargate is your VPC.
Not sure what you mean, Kubernetes should be rolling the Pods on any update already so only create/delete Pods, but never really updates.
As logging and hopefully metrics can be done via Cloudwatch, our use-case for Daemonsets mostly went away, but yes thats an open question.
We were are exploring this currently as a target for Jenkins, which spawns Pods on-demand on Fargate and doesn't need any service or anything else. ETL jobs or something similar might be also interesting to look at.
Thanks for your answers! I think it is very valuable to have your real use cases to understand when to use something like that. For Jenkins, using spot instances on EC2 seems much more cost effective, but I understand that not having any infrastructure is very appealing.
I'm looking forward to the new PR then!