Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS Fargate provider #127

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
4 participants
@johanneswuerbach
Copy link
Contributor

johanneswuerbach commented Apr 10, 2018

This implements AWS Fargate as a new provider for the virtual-kubelet.

Implemented functionality:

  • Basic pod to ECS task mapping including lifecycle mapping
  • Container name, image, command, args, port mappings, working dir and environment variables
  • Container memory and CPU limits, memory requested
  • Log forwarding
  • Public and ECR image pulling
  • kube2iam like IAM policy declaration for the pod
  • Configurable task resources, see supported configurations

Not yet supported features:

  • Volumes
  • ConfigMaps, Secrets
  • Container CPU requested
  • Restart policies
  • Pull secrets

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/

Fixes #12

johanneswuerbach and others added some commits Mar 22, 2018

AWS Fargate provider
Implementation of an AWS Fargate provider for the virtual-kubelet.

Co-authored-by: Anthony Stanton <anthony@contentful.com>
Vendor aws-sdk
Co-authored-by: Anthony Stanton <anthony@contentful.com>

@johanneswuerbach johanneswuerbach force-pushed the johanneswuerbach:aws branch from 3e4b45c to 3b7aa73 Apr 10, 2018

@robbiezhang robbiezhang self-requested a review Apr 10, 2018

@d-nishi

This comment has been minimized.

Copy link
Collaborator

d-nishi commented Apr 11, 2018

@johanneswuerbach -- this is fantastic! AWS has an official PR in the works. We would to love to have you collaborate with us on the official design.

@johanneswuerbach

This comment has been minimized.

Copy link
Contributor Author

johanneswuerbach commented Apr 11, 2018

@d-nishi sure let me know how I can help. I'm also available under the same handle on the Kubernetes Slack.

@rbitia rbitia requested a review from erikstmartin Apr 11, 2018

@Raffo

This comment has been minimized.

Copy link

Raffo commented Apr 11, 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:

  • how to get networking to work: support of services / ingress
  • how to really do updates
  • how to handle daemonsets given how the virtual node is different from standard ones

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.

@johanneswuerbach

This comment has been minimized.

Copy link
Contributor Author

johanneswuerbach commented Apr 12, 2018

Quick update: I am working with AWS Fargate team to merge my provider with theirs. We will send a new PR soon.

@johanneswuerbach

This comment has been minimized.

Copy link
Contributor Author

johanneswuerbach commented Apr 12, 2018

how to get networking to work: support of services / ingress

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.

how to really do updates

Not sure what you mean, Kubernetes should be rolling the Pods on any update already so only create/delete Pods, but never really updates.

how to handle daemonsets given how the virtual node is different from standard ones

As logging and hopefully metrics can be done via Cloudwatch, our use-case for Daemonsets mostly went away, but yes thats an open question.

any real life use case

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.

@Raffo

This comment has been minimized.

Copy link

Raffo commented Apr 12, 2018

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!

@erikstmartin

This comment has been minimized.

Copy link
Contributor

erikstmartin commented Apr 13, 2018

@johanneswuerbach With you working directly with AWS on this and a new PR incoming, is it safe to close this one?

@johanneswuerbach

This comment has been minimized.

Copy link
Contributor Author

johanneswuerbach commented Apr 13, 2018

Yes, sorry @erikstmartin

Closing here because:

Quick update: I am working with AWS Fargate team to merge my provider with theirs. We will send a new PR soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.