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

Create instructions for faas-netes on OpenShift #349

alexellis opened this Issue Jan 10, 2019 · 1 comment


None yet
2 participants
Copy link

alexellis commented Jan 10, 2019

We should create instructions for deploying OpenFaaS on OpenShift.

Michael Hausenblas once worked on this and wrote up a blog using minishift, but it wasn't signed-off, so couldn't be merged. The project has changed since then and I'd appreciate an experienced OpenShift user taking a look at this and contributing changes back to this repo and openfaas/docs.


This comment has been minimized.

Copy link

annatech commented Jan 11, 2019

Having recently deployed faas-netes on a self-hosted OpenShift OKD 3.11 cluster, I can follow-up with a document describing my work. Overall, I was able to use the instructions from here, mostly as-is:

The actual deployment was performed using a helm chart, executed from one of the OpenShift master nodes. After the kubectl command was run to create the namespaces and helm deployed the containers, I moved to OpenShift for the rest of the configuration. Since I had already setup a fully-functional and ssl-secured cluster, service routes were easy to deploy over HTTPS.

Finally, I did have to create a network bridge between the openfaas and openfaas Projects (a.k.a "namespaces" in k8s). This was primarily due to my having chosen the multi-tenant network plugin which segments Pods between projects by default.

The advantage of deploying on OpenShift is that container management and route configuration is a breeze. Tasks which are a chore in pure k8s are often entirely UI-driven or orchestrated by compact "oc" CLI commands. The RBAC, network segmentation and cluster management tools make it better suited for "enterprise" deployments. The downside is that the minimum requirements are much higher than, say, Docker Swarm... so no Raspberry Pi's for this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment