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
Proposal: Kubernetes tolerations #1125
Feature: Kubernetes tolerations
Tolerations allow a Pod (function) to be scheduled on a node where there is a "taint" preventing Pods from being scheduled there.
We have support for constraints and labelled node-pools for scheduling, but there is a scenario a user came with where a node-pool has a taint and so constraints are not enough - they need to also add a "toleration" to the function Pod.
We could extend the function schema to allow the Kubernetes tolerations spec to be specified.
This is not available in Swarm and possibly not available in the other back-ends, so it's the first hard requirement for orchestrator-specific knowledge in the OpenFaaS API.
Suggestions are welcome.
Steps to Reproduce (for bugs)
This affects advanced scheduling scenarios on Kubernetes.
Using annotations for this purpose sounds pretty reasonable. It's already supported within the OpenFaaS API, and should only require modification to faas-netes to work with kubernetes - ie looking for a
If you use a Mutating Webhook Admission Controller  then you can look for your annotation and act upon it as soon as the Pod is requesting creation. You get all the benefits of automation, extending the API in an open-closed way and don't create any engineering burden on the community. The slok  project can be used to put this together in a very short period of time.
Stefan suggests you'll need the CA from the cluster:
To sign the TLS key needed for the controller.
This may even be possible to deploy as an OpenFaaS function itself.
This could be a great example of how to extend OpenFaaS on Kubernetes for others to follow, too.